For me, the use of the '@' is a conscious choice, not sloppiness.  

Programming languages have to walk a fine line regarding the number and level 
of error messages that are generated.  Many programming languages let things 
pass without warning or notice, which means that potential errors go 
undetected.  But turn up the level of checking too high, and the programmer has 
to jump through hoops or write lots of extra code even when the supposed 
"error" isn't significant or is otherwise being handled.

No matter where a language draws this line, there are instances where it falls 
on the wrong side of what the programmer wants/intends.  PHP's "@" operator is 
a convenient way to say "I know what I'm doing, please don't bother me about 
it."

My response to a comment like "@ is never a good practice" would be to ask how 
the person feels about "type conversion" operators in other languages such as 
C, C++, C#, etc.  In these languages, a compiler will often complain if 
operands of the wrong type are being used; a programmer will use a "cast" or 
"type conversion" to tell the compiler "I really do intend to do this here" so 
that it won't complain.  I view PHP's "@" operator as being in this same 
category of constructs; used properly, it lets the programmer inform the 
language translator that the standard error checking (whatever it happens to 
be) doesn't apply in the operation that follows.

Pm


On Sun, Mar 01, 2015 at 09:49:53PM +0100, Petko Yotov wrote:
> "Challanged pretty strongly" with what arguments and sources,
> citations or references?
> 
> Someone once challanged our use of apostrophes to wrap HTML
> attributes - which was extremely wrong, and we were amateurs, and we
> had to use double quotes instead. When I pointed to the W3C HTML and
> to the XHTML Transitional standards which allow the use of
> apostrophes, the person kept insisting that it was wrong. What can
> you reply to someone like this.
> 
>   http://php.net/manual/en/language.operators.errorcontrol.php
> 
> Using this @ operator is very consise and the code stays short,
> readable and maintainable. Consider:
> 
>   if ( @$foo ) { }
>   @$bar++;
> 
> versus:
> 
>   if ( isset($foo) && $foo>'' ) { }
>   if ( ! isset($bar) ) $bar = 1;
>   else $bar++;
> 
> (for global variables you can also use the function IsEnabled().)
> 
> The use of the @ operator is somewhat slower than isset(), in my
> testings about 0.0000037 seconds per call (without bytecode
> compilation or memcache which would be much less). This is less than
> 4 microseconds. I'd trade these any day for more readable and
> maintainable code.
> 
> Petko
> 
> On 2015-03-01 20:47, Peter Bowers wrote:
> >I see often in PmWiki core & recipes where errors are suppressed via @:
> >
> >if (@$foo['bar'])...
> >
> >Recently I was challenged pretty strongly that this was never a good
> >practice.
> >
> >So... is it just preference & this guy was opinionated? Or is this
> >an older
> >way to do things & best practice is to not use this operator?
> 
> 
> _______________________________________________
> pmwiki-devel mailing list
> pmwiki-devel@pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-devel

_______________________________________________
pmwiki-devel mailing list
pmwiki-devel@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-devel

Reply via email to