Hacker News Reader

Comment by munk-a | Hacker News Reader

As a company you can decide where to fall on this scale, I applaud you for -Wall'ing but for most it's too much, the important thing is to make sure that everyone has agreed which warnings are acceptable and you refuse code that violates that.

We're using PHP (so runtime warnings, instead of compiler issues) but we have a zero-error policy, if anything raises a warning or error we refuse to merge (or ticketize fixing since a bunch of stuff is legacy and we're still paying it down).

View on HN

The standard in PHP-frameworks like Laravel is to automatically throw Exceptions when a Notice happens, which at first I thought was overly aggressive but I would never go back to writing PHP where a Notice is thrown and ignored.

It depends on the era of PHP to be honest, pre-PHP 5.2 (IMO) notices were mostly for pretty small stuff that was accepted as being necessary for sanity, i.e. trying to read a value out of $arr[$dem1][$dem2][$dem3] would require three separate isset checks to do safely, I always leaned toward building a user-space recursive isset function but it came with a penalty to performance.

Starting in 5.4 and getting far more prominent in 5.6, PHP started breaking bad backwards compatibility and failing to respect notices could easily lead to errors on version bumping up to 7.

As I mentioned in the sister comment, by ignoring notices you're setting yourself up for garbage values being passed through your code and into user-facing functionality, including handling of money. That doesn't depend on the PHP version.

There's an extra point with notices: they are likely to lead to logical errors instead of technical ones. The algorithm works, but it receives a garbage value (null aka zero, usually). So it gives some garbage as a result. In nine cases, resulting garbage goes further into various barely meaningful code, but in one it will go into some user-facing functionality, including handling of money.

Reply on news.ycombinator.com