XF 2.0 Turn off E_NOTICE logging

[Lukas W.]

Is it possible to raise the error reporting level in XF to prevent notices from being logged? I don't really care about them in my production environment.

 

[Mike]

Frankly you should care about them because they represent likely bugs. They are logged but non-blocking in production. (They are blocking in debug mode.)

(So the short answer is that there isn't anyway built in to not log notices.)

 

[Lukas W.]

because they represent likely bugs.

There's a lot of stuff that can be done in PHP that triggers a notice, but is purely intentional. Depending on ones coding style, it's not that likely that a notice will represent a bug. It's definitely not the cleanest way, but oftentimes can save a lot of extra effort that would need to be spent to work around the notice being triggered. It comes down to preference in my opinion.

(They are blocking in debug mode.)

Agreeably a good way. That's where I want to get informed about them after all.

(So the short answer is that there isn't anyway built in to not log notices.)

Unfortunate.

 

[Chris D]

There's a lot of stuff that can be done in PHP that triggers a notice, but is purely intentional. Depending on ones coding style, it's not that likely that a notice will represent a bug. It's definitely not the cleanest way, but oftentimes can save a lot of extra effort that would need to be spent to work around the notice being triggered. It comes down to preference in my opinion.

I think that kind of coding style and ignoring such notices will make a developer complacent. Such notices are going to be caused by undefined variables (which could be a misspelling of a variable name, therefore a bug), caused by an undefined index (which could be a misspelling, or data not being where you expect it to be therefore a bug). What kind of E_NOTICE warnings would you be proposing aren't bugs and are safe to ignore?

 

[Lukas W.]

I think that kind of coding style and ignoring such notices will make a developer complacent. Such notices are going to be caused by undefined variables (which could be a misspelling of a variable name, therefore a bug), caused by an undefined index (which could be a misspelling, or data not being where you expect it to be therefore a bug).

Valid points.

What kind of E_NOTICE warnings would you be proposing aren't bugs and are safe to ignore?

It's mostly undefined index notices. I am used to shorten if-statements, as that's how I've been taught to program PHP.

As an example:

if($entity && $entity->Relation && $entity->Relation->offsetExists($offset) && $entity->Relation[$offset]->Relation2 && $entity->Relation[$offset]->Relation2->property)

Is utterly "complex" and really hard to read.

if($entity->Relation[$offset]->Relation2->property)

Will provide the same result, and is more readable. It's (from my perspective) clear, that a failure in one of the steps will cause the if-statement to evaluate to false, just as the above statement will.

It is agreeable an extreme case, and most of the time it will be about saving one or two statements in if-queries, but for me it is much more readable to leave them away.

 

[Chris D]

I agree that's difficult to read. But you can simplify it:

if (!empty($entity->Relation[$offset]->Relation2->property))
{
    // $entity->Relation[$offset]->Relation2->property has a non empty value
}

That would appropriately test that all of those indexes/properties are available without emitting any notices. It would be less forgiving if $offset is undefined, though I definitely can't think of a valid excuse for undefined variables

 

[Sim]

I am used to shorten if-statements, as that's how I've been taught to program PHP.

In most cases, the failure of such a statement actually represents a bug - something you will be completely unaware of and find difficult to trace if you have no logging in place to alert you to such failures.

It may not be that critical for user facing code (other that potentially causing frustration for the user when something doesn't work), but for highly automated back-end code (eg payment processing, email sending, integration with other backend systems), it's kind of critical to have your code fail gracefully and identify bug-conditions for you because you have no other indicators that things aren't working.

In my opinion - it is exactly this approach to coding you describe which has given PHP such a bad name amongst professional software developers.

Your goal isn't to write shorter code - your goal is to write correct code.

 

[Lukas W.]

But you can simplify it

That's a lot better. Thanks!

It may not be that critical for user facing code (other that potentially causing frustration for the user when something doesn't work), but for highly automated back-end code (eg payment processing, email sending, integration with other backend systems), it's kind of critical to have your code fail gracefully and identify bug-conditions for you because you have no other indicators that things aren't working.

I wasn't questioning that. However it comes down to the application. I do not have any payment processing in place, no other backend systems, etc. Nothing "important" to fail. If something is not working as it should, I turn on notice reporting again and then I can debug appropriately. For as long as that, I don't need it. It is a choice, and being able to make that choice is one of the possibilities that PHP offers and one of the choices that I put a lot of thoughts in.

In my opinion - it is exactly this approach to coding you describe which has given PHP such a bad name amongst professional software developers.

I honestly never heard about that reputation. All I normally hear is how "great Java is". Something I have to politely object every time I hear it, lol.

Your goal isn't to write shorter code - your goal is to write correct code.

My goal is to write code that is easily understandable, so that I can come back to it after a few months or possibly longer and still be able to understand what's happening there. Unnecessary bloat will make this harder. It's not about having the shortest code possible, but about keeping it readable. A 5-line-if-statement is anything but understandable compared to a single-liner that does absolutely the same.

 

[DragonByte Tech]

I wasn't questioning that. However it comes down to the application. I do not have any payment processing in place, no other backend systems, etc. Nothing "important" to fail. If something is not working as it should, I turn on notice reporting again and then I can debug appropriately. For as long as that, I don't need it. It is a choice, and being able to make that choice is one of the possibilities that PHP offers and one of the choices that I put a lot of thoughts in.

That way of thinking is exactly why PHP has such a bad rep.

It should never have been a choice to ignore notices, that's one of the greatest failings of the PHP dev team. You would do well to forget that the idea of hiding notices exists. Pretend it doesn't exist.

My goal is to write code that is easily understandable, so that I can come back to it after a few months or possibly longer and still be able to understand what's happening there. Unnecessary bloat will make this harder. It's not about having the shortest code possible, but about keeping it readable. A 5-line-if-statement is anything but understandable compared to a single-liner that does absolutely the same.

Ironically, ignoring notices about undefined variables etc makes your code way less understandable.

You have to bear in mind that almost no-one uses a "dumb text editor" any more, meaning a text editor that doesn't have IntelliSense. The ability to right click any given variable and hit "go to definition" to see what it is and what it does is incredibly valuable for readability.

Calling proper syntax "unnecessary bloat" is something I could not disagree with more. You could be telling me drinking baby blood is okay and I would still object to the notion of proper syntax as "unnecessary bloat" more than I would that statement

Even if you swear by Notepad as your code editor and you don't think anyone else is ever going to read your code, you can't ever know that. Maybe you sell your site, maybe you end up hiring another developer, etc. Someone somewhere is one day going to have to deal with your code, and the fact that the only thing keeping your code running is error suppression will bite you

For the sake of everyone who has to read and work with your code, please please please pretend that the "choice" of hiding errors in your code doesn't exist.


Fillip

 

[Lukas W.]

Ironically, ignoring notices about undefined variables etc makes your code way less understandable.

I'm not ignoring it, I'm handling it properly, as seen above. The undefined index is thrown, when the relation does not exist, which is a perfectly acceptable scenario, as the relation is not mandatory.

The ability to right click any given variable and hit "go to definition" to see what it is and what it does is incredibly valuable for readability.

See above. As the origin is clearly defined in the entity, there's always a correct definition for that. It seems to me, that you didn't take the time to actually study my example even the slightest.

Calling proper syntax "unnecessary bloat" is something I could not disagree with more.

I don't know where you get the impression from that I call proper syntax unnecessary bloat. I call a five-liner unnecessary bloat, that can be narrowed down to a one-liner as shown by @Chris_D.

For the sake of my nerves, I'd appreciate if you would take yourself the time to actually read a topic before replying with something that can be narrowed down to the essence of "you're dumb for even considering". It's considering choices that brings new ideas. Making errors is a part of that, from making errors comes experience, from experience comes progress. I've understood the message after @Mike's reply, and value what @Chris_D has added afterwards, but having it pointed out for the fourth time in what appears to be nothing more than a nicely wrapped insult is pretty unnecessary.

 

[Sim]

My goal is to write code that is easily understandable, so that I can come back to it after a few months or possibly longer and still be able to understand what's happening there.

That's what comments are for.

Get in to the habit of commenting everything you do when you write it - will make debugging so much easier.

Think of it as if you are writing code that someone else will have to debug - it's exactly the same as coming back to code you yourself wrote many months later having completely forgotten what those instructions were supposed to do.

Unnecessary bloat will make this harder. It's not about having the shortest code possible, but about keeping it readable. A 5-line-if-statement is anything but understandable compared to a single-liner that does absolutely the same.

Actually, I find completely the opposite to be true - if you make strong use of PHP's coding quirks (shortcuts) to make your code more "brief", it can have the opposite effect of making the exact behaviour of the code unintuitive and give unexpected results in some circumstances.

I find being explicit (rather than relying on implicit rules) makes it much easier to work out exactly what is going to happen with the code - makes code more understandable and less likely to introduce bugs.

I know many developers who prefer your approach of brevity - but I have also found that in many professional development houses, they tend to introduce coding standards which explicitly disallow many of the shortcut conventions for exactly this reason - brevity for the sake of it can introduce unexpected bugs.

I get that you're not trying to write "professional" level code - and at the end of the day - whatever works for you is fine. I'm just trying to offer some advice based on many many years of development experience (and many hours of wasted time trying to work out why someone else's arcane code didn't work!).

 

[Lukas W.]

That's what comments are for.
Get in to the habit of commenting everything you do when you write it - will make debugging so much easier.

I did that for quite a long time but eventually stopped as my knowledge increased and code became more easily understandable just from reading it instead of the comments. I'll try to train myself to do that more again.

Actually, I find completely the opposite to be true - if you make strong use of PHP's coding quirks (shortcuts) to make your code more "brief", it can have the opposite effect of making the exact behaviour of the code unintuitive and give unexpected results in some circumstances.

I find being explicit (rather than relying on implicit rules) makes it much easier to work out exactly what is going to happen with the code - makes code more understandable and less likely to introduce bugs.

I agree with that. I only have had three places in about 7.600 lines of code in that (personal) add-on so far that threw such notices, as I explicitly check for all possibilities whenever necessary and generalize only if I find the current position not necessary to investigate deeper into why a specific relation does not exist (as it does not necessarily has to exist at that point) and I only want to not execute that specific part now, if the relation chain does not fully resolve.

I know many developers who prefer your approach of brevity - but I have also found that in many professional development houses, they tend to introduce coding standards which explicitly disallow many of the shortcut conventions for exactly this reason - brevity for the sake of it can introduce unexpected bugs.

Thanks for sharing this insight. My personal work experience so far in that field can be summarized with "coding guidelines are there, because someone said they have to be". Guess that's the price for working with people that specialize in research rather than coding.

 

[Xon]

A small note; but most decent php IDE's can parse phpdocs declarations for type information and then do type validation on variable handling.

This is very useful to target say php 5.6 but still have type hinting and type validation done by your IDE. With XenForo 2.x Entity system, it can automatically generate phpdocs for Entity classes to ensure ensure columns & relationships accessed via __get magic method are correctly type hinted.

I know I've identified a number of bugs and errors due to poor type handling since I converted over to fully using an IDE.