On 4/4/21 12:23 PM, André Warnier (tomcat/perl) wrote:
Hi.
I have a question which may be totally off-topic for this list, but this has been puzzling me for a while and I figure that someone here may be able to provide some clue as to the answer, or at least some interesting ponts of view.

In various places (including on this list), I have seen multiple occurrences of a certain way to write a test, namely :

 if (null == request.getCharacterEncoding()) {

as opposed to

 if (request.getCharacterEncoding() == null) {

Granted, the two are equivalent in the end.
But it would seem to me, maybe naively, that the second form better corresponds to some "semantic logic", by which one wants to know if a certain a-priori unknown piece of data (here the value obtained by retrieving the character encoding of the current request) is defined (not null) or not (null).

Said another way : we don't want to know if "null" is equal to anything; we want to know if request.getCharacterEncoding() is null or not.

Or in yet another way : the focus (or the "subject" of the test) here is on "request.getCharacterEncoding()" (which we don't know), and not on "null" (which we know already).

Or, more literarily, given that the syntax of most (all?) programming languages is based on English (if, then, else, new, for, while, until, exit, continue, etc.), we (*) do normally ask "is your coffee cold ?" and not "is cold your coffee ?".


So why do (some) people write it the other way ?
Is it purely a question of individual programming style ?
Is there some (temporary ?) fashion aspect involved ?
Do the people who write this either way really think in a different way ?
Or is there really something "technical" behind this, which makes one or the other way be slightly more efficient (whether to compile, or optimise, or run) ?


Cannot find it back right now.

But I seem to remember that it came from Scott Meyers in C++ programming.

Maybe there it forces the compiler to use the right method when there is overloading.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to