Hi. Notices are useful because they point out *potential* problems -- we shouldn't just disable them globally, because they do catch errors. So is the solution to leave them on and always code around the issues they point out? In some cases, yes. Certainly when the issue is an error!
But should we use this construct: $something = (isset($_GET['something'])) ? $_GET['something'] : null; to get around PHP's notice message? The fact is, is that cyclomatic complexity is increased by using a ternary operator (or any other conditional). And increasing cyclomatic complexity is associated with a higher number of software defects. Do we as programmers, now embrace greater complexity and greater size of code as indicators of good programming? Or do we give up on notices that help us catch errors? Neither. We simply suppress the errant notices with @. Suppressing individual warnings is nothing new, lint (from which PHP's -l option takes it name) allowed individual warnings to be suppressed 30 years ago. When you start issuing warnings that only indicate the possibility of undesired behaviour, message suppression is both necessary and good. -Craig As for performance, it takes less than one millionth of a second to use @ on a 2.4GHz processor. On Sep 16, 8:21 pm, Simon Holywell <[email protected]> wrote: > Being that isset is a language construct and array_key_exists is a function > the former is supposed to be a faster way of determining existence. > Please don't suppress errors or notices with the @ operator. It is much > better to drop the error reporting level down that way you only need to > change one thing to show the errors again if you need to debug. Hunting > through reams of legacy code to find an error is so much more difficult if > people have used the @. --~--~---------~--~----~------------~-------~--~----~ NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [email protected] -~----------~----~----~----~------~----~------~--~---
