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
