Re: Re: PEAR Coding Standards

"Alan Knowles" <alan@akbkhome.com> wrote in message news:4096ED1D.9010405@akbkhome.com... > Thorsten Suckow-Homberg wrote: > >>------ GENERAL USAGE ------ > >>there are times when checking variables where although it is minutely > >>slower, it does aid readibility. > >> > >>if (@$options['dosomething'] == true) { > >>is significantly clearer than > >>if (isset($options['dosomething']) && > >>($options['dosomething'] == true)) > >>{ ..... > >>---------------------------------- > >>@ is part of the language, and in some respects is just a short form of > >>catch/try/throw. > > > > > > I may be wrong here, but @ doesn't help you to get rid of Notices when you > > set error_reporting to E_ALL, am I right? > Nope - it works perfectly.. > > If that is so, I think it is a bad > > idea to spare your issets and instead using @'s... > > Actually, there was considerable discussion on internals about this, and > the idea of introducing a setor() method. > > @ is slower than "isset() && test" - significantly, when the majority of > the the tests raise an error. (however, it is about the same when most > of the time, the variable is set.) > > generally: > ** if the variable is normally set: > if (@$somevar==....) { > is probably going to be marginally faster. (and is slightly more readable) Ahhh! So write a wrapper function! using @ is terrible, terrible terrible! I use the below code, because it's more readable - probably slower, but it's better than error supression http://ircphp.com/users/imho/?file=Vars.php > > ** if the variable is normally not set: > if (isset($somevar) && $somevar == .... > is probably going to be faster > > (this is based on the priniciple that someone is likely to have > implemented a error_handler...) > > Regards > Alan > > > > > > > > -- > Can you help out? > Need Consulting Services or Know of a Job? > http://www.akbkhome.com