All, > Am 05.04.2021 um 14:38 schrieb Christopher Schultz > <ch...@christopherschultz.net>: > > André, > >> On 4/4/21 06:23, 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 ?". > > On the other hand, in English, coffee which is not hot is called "cold > coffee" but in e.g. Spanish, it's "coffee cold". > >> So why do (some) people write it the other way ? > > I personally put the null first because of my background in C. C compilers > (especially older ones) would happily compile this code without batting an > eyelash: > > char *s; > > s = call_some_function(); > > if(s = null) { > // do some stuff > } > > Guess what? "Do some stuff" is always executed, and s is always null. > > If you switch the operands, the compiler will fail because you can't assign a > value to null: > > if(null = s ) { > // Compiler will refuse to compile > } >
Isn‘t it true that only one bit difference would result in false - so result would not have to be completely tested? Peter > So it's a defensive programming technique for me. > >> Is it purely a question of individual programming style ? > > Perhaps at this stage in history, it is only "style". But it does have a > practical > >> 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) ? >> (*) excepting Yoda of course > > -chris > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org