On 04.04.2021 12:57, Olaf Kock wrote:
Hi André
On 04.04.21 12:23, André Warnier (tomcat/perl) wrote:
if (null == request.getCharacterEncoding()) {
as opposed to
if (request.getCharacterEncoding() == null) {
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) ?
(*) excepting Yoda of course
I can't say I'm always writing Yoda style, but if I stretch my memory,
then the rationale behind this style of comparisons is to have a
constant on the left side, so that you get a compiler error in case
you're using = instead of ==.
I like that explanation, in the sense that it provides a programming rationale for using
the first form (and not only in Java), even if it feels intuitively un-natural.
So it's apparently not only fashion or Yoda fandom.
Thanks.
In your case, with a function call, this wouldn't make a difference
"if(request.getCharacterEncoding() = null)" would be illegal syntax as
well, but "if(someObject = null)" is perfectly legal, but doesn't
express the author's intent clearly: Is it a smart person who's taking a
shortcut, or a newbie using the wrong operator?
Let the seasoned programmer who's never made that same mistake throw the first
stone.
Of course, the style doesn't really help people new to the language, as
they first need to understand that this is something that they might
want to apply to their code. And today, with so many IDE warnings being
flagged while typing, it might be outdated, though it still clearly
expresses the intent to have a real comparison and not an assignment here.
And I agree with the other answer posted already: It makes a lot more
sense in C++ with all the implicit boolean conversions and habits of
outsmarting the code's maintainers with clever expressions.
+1 to that too.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
