Can such style be justified?

[Francesco S. Carta]

Another possibility is to put this into a function with a meaningful name:

inline bool should_do_it()
{
return someBool1 || someBool2 && !someBool3;
}

Yes, as an helper function within a class that would be fine, while as a
standalone function it would imply that those bools are globals ;-)

As I said in my previous message, all of this depends on the actual case
- anyway I wouldn't use the style reported by the OP, for sure ;-)

 

[Goran]

Call me a hard ass, but I think the understanding of precedence is a
basic skill that every programmer should know. Just like we should know
that && and || will short circuit their evaluations.

I am all for knowledge, but... The issue is not only knowing stuff
(e.g. precedence), the issue is also making it easier on the brain.
Complicated conditional logic must be "parsed" by the brain. That
sucks brain resources to understand overall code structure. As a smart
guy said elsewhere, "Don't make me think" ;-)

Goran.

 

[gwowen]

I am all for knowledge, but... The issue is not only knowing stuff
(e.g. precedence), the issue is also making it easier on the brain.
Complicated conditional logic must be "parsed" by the brain. That
sucks brain resources to understand overall code structure. As a smart
guy said elsewhere, "Don't make me think" ;-)

Goran.

That summarised my thinking far better than I managed to do.

 

[Armen Tsirunyan]

No, it's not a matter of style.

It would ordinarily mean that your colleague is not just currently incompetent,
but too stupid to learn.

Alternatively he or she might be doing it for unsavory motives such as job
security through code obscurity, or just to provoke you and/or others.

Such a style cannot be justified.

THANK YOU! )))

 

[Armen Tsirunyan]

Awful.

I assume to be consistent your colleague also writes

if(true == (42 == n))

for integer comparisons?

if it is true that some bool is true...
Or, or, ... if((true == somebool) == true) xDDDDDD

 

[Puppet_Sock]

THANK YOU! )))

Not so fast there. You got an answer you like, yes.
Now before you go waving this under your cow-orker's
face saying "See? See!" you should just have a quick
look at the company's workplace behaviour policies.
Calling somebody "too stupid to learn" would probably
be a violation. It would certainly be such in my
workplace and would get, at a minimum, a visit to
HR to have the policies explained once more. And maybe
a formal reprimand in my file.

In Ontario such things were recently placed under the
workplace safety rules. And a zero tolerance policy
was attached. If it's similar where you live you
could wind up stirring a powerful angry hornet's
nest by waving such things around.
Socks

 

[Seungbeom Kim]

I understand precedence. I just don't rely I on language rules when
its just as easy to code unambiguously. I can't be bothered to
memorise the precise precedence rules of every language in which I
program -- and no, they are not all the same. Writing code that
expresses intent with brackets rather than relying on my (flawed)
memory means I make fewer mistakes, and makes it easier for beginner
programmers to grok the code as the read it. Making life easier for
maintainers makes my life easier.

While I see some value in being explicit, I should also consider that my
eyes will easily get distracted by more than a few levels of parentheses.
Therefore I prefer to leave the precedence of common and "obvious" things
implicit: arithmetic > relational/equality > logical, for example.

The bitwise operators are not one of them, because they can easily be
mistaken as having similar precedence as arithmetic operators.
I prefer to take more caution and be more explicit around them.

if ((flags & mask) == another_mask) { ... }

Another exception is the conditional operator: I prefer to group the
first (boolean) expression.

r = (x >= 0 && y >= 0) ? true_expr : false_expr;

 

[Öö Tiib]

THANK YOU! )))

You need to enforce what is acceptable style and what is not within
your team. Write style policy down and agree with your team. Quality
means describing how you do it and then following the descriptions
when you do it. If it can not be followed then correct it until it can
be followed. No usenet group can produce universal rules how you (and
your team members) should do your work.

 

[Öö Tiib]

I remember reading a study once, unfortunately I can't source it, that
showed that doing the above does help those in the lowest quartile in
skill, it actually hurts those in the highest quartile. Don't force your
best people to follow the rules, even if they wrote them.

Few points:
* Is it possible that it is one from that highest quartile who writes
things like "if ( true == someBool )"?
* Can be rules and limits disadvantageous or advantageous to
creativity in context of such loose language like C++?
* What is more frequent work: maintenance of existing code and modules
or writing completely new code and modules?

 

[Alf P. Steinbach /Usenet]

* Daniel T., on 25.09.2010 20:36:

I realize your questions were ment to be rhetorical, but I think the
correct answers are a little less obvious that you seem to think.

1. There are a whole host of ways to write programs that an expert would
not even consider worthy of mention (this may very well be one of them,
I can find no style guide that forbids such constructs as the OP
mentioned.) If we were to try to write *all* of them down, not only
would the tome be voluminous, but the debates among the highest quartile
about the finer points would be un-constructive.

This one is simple, I think. Aim for /clarity/. If the people that one works
with don't understand clarity, e.g. if they think that it can be reduced to
mechanistic robot-enforced rules, then mostly all is lost anyway.

2. Rules and limits do indeed breed creativity, but we must be careful
that the creativity isn't directed toward getting around those very
rules and limits.
Yeah.


3. Given a specification for a function or class and code that does not
meet that specification, what should a "maintenance" programmer do? Try
to tweak the broken code, or erase and re-write the function or class so
that it works correctly? Unlike in building construction, destroying old
code isn't a costly procedure. Unlike in surgery, it is rarely the case
that we have to keep the program alive while working on it. These facts
afford us much more latitude in "starting from scratch."

Uhm, the cost of replacing old code can be /very/ high. For example, I once had
to structure a piece of code in a base class so that part of it could be
overridden. This could conceivably have been done in a fifth or tenth of the
time if the thing could just be replaced, but it wasn't documented, and it was
absolutely not clear what the heck it did, relying on umpteen (effectively)
globals and sideways initialization at unpredictable times and returning at
various points in apparently different states, with this spaghetti in turn
embedded in a system-wide spaghetti of interactions. Replacing it would mean
replacing also large parts of the connected spaghetti. It's at times like those
that you wish your boss was someone you could explain things to and ask for a
decision. It's sort of hard to justify the work otherwise: anyone looking at the
code, not knowing the complicated rationale, will most naturally see it as
further obfuscation of already spaghetti (I am sure of that, since Someone(TM)
anonymous asked in this group, later, about that code, it couldn't be anything
else because I used a very special technique to transform it while keeping its
functionality as-is, and the question was about the point of that technique).


Cheers,

- Alf

 

[Öö Tiib]

I realize your questions were ment to be rhetorical, but I think the
correct answers are a little less obvious that you seem to think.

More like questions with "more yes than no" style answers, nothing
absolute there.

1. There are a whole host of ways to write programs that an expert would
not even consider worthy of mention (this may very well be one of them,
I can find no style guide that forbids such constructs as the OP
mentioned.) If we were to try to write *all* of them down, not only
would the tome be voluminous, but the debates among the highest quartile
about the finer points would be un-constructive.

Yes. However i have two static code analyze tools on hard drive (from
different origins) that report the issue of redundant usage of bool
literals for comparisons as bad style warning. So if people have
written code to detect it then it is certainly worth to write a line
of prose into style policy if it annoys you.

2. Rules and limits do indeed breed creativity, but we must be careful
that the creativity isn't directed toward getting around those very
rules and limits.

Sure. No rule should be absolute. First rule should be that when
someone breaks a rule then he should comment why he did break it.

3. Given a specification for a function or class and code that does not
meet that specification, what should a "maintenance" programmer do? Try
to tweak the broken code, or erase and re-write the function or class so
that it works correctly? Unlike in building construction, destroying old
code isn't a costly procedure. Unlike in surgery, it is rarely the case
that we have to keep the program alive while working on it. These facts
afford us much more latitude in "starting from scratch."

Rewriting something does fix some issues and raise others. Code must
stay readable. You forget that maintenance often means hours of
reading code to possibly fix few lines in it. Or to propose it to be
refactored. Or to propose it to be rewritten.

 

[Juha Nieminen]

if(true == someBool)
{
}

if(false == someBool)
{
}

Some lesser programmers have learned to put literals at the left side
of the equal comparison operator because else they keep writing things
like "if(variable = 5)" and ignoring the compiler warnings about it.
Naturally this is just a partial solution to their problem because it
won't help when comparing two variables, like "if(variable1 = variable2)".
Hence they are fighting the symptoms (and poorly at that) rather than the
root cause.

Comparing boolean variables to boolean literals is doubly bad, because
the whole idea of booleans is that they act as, well, booleans, like their
name implies. Hence you write "if(someBool)" and "if(!someBool)", which is
the most natural way. Even if those variables were not of the actual type
'bool' and instead they were eg. ints (like in C), that would still work.
(In fact, "if(true == someBool)" would actually *fail* if 'someBool' was
actually an int and its value something else than 0 or 1. Hence comparing
it to a boolean literal as some kind of odd safeguard is a complete
failure.)

bool someBool = (true == someBool1 || true == someBool2 && false ==
someBool3) ? false : true

That makes no sense. Comparing boolean variables to boolean literals
is just nonsensical overhead. Booleans are booleans, and thus should be
used like booleans, in other words:

bool someBool = !(someBool1 || (someBool2 && someBool3));

It immediately becomes more readable and easier to understand. (The line
becoming shorter is a bonus.)