Parentheses preference

[jeffcobb]

Style two. Things getting complicated?

bool maybe = condition;
if (maybe) ...

Though it's not always easy to pare down to bool, which is fine by me.

Some folks I work with would argue that the 'maybe' is superfluous and adds nothing to the code; I know this b/c I am always doing that (boiling down large, complex (IMHO needlessly so) if() conditionals. A twist on the above is like this (warning, off-the-top of my head code coming to illustrate a point):

// old conditional
if( (someVal > 6) && (someOtherVal <= 2) || (someState == STATE_FOO))
{
     // do something
}

// often becomes:
bool shouldActionBeTaken(int someVal, int somOtherVal, machineState someState);

if( shouldActionBeTaken(6, 2, someState))
{
    // take action
}

In any event I find in complex logic, boiling your conditionals down to a single state ( in your case, 'maybe') helps convey the intent of the code better than almost anything else.

One thing in this thread that cracked me up is someone going on about the virtues of using little whitespace and single-char variables to save disk space...if your drive space is so limited that you have little room for clean-reading source you have larger issues than just drive space...

By that estimation, you should never backup source, keep a VCS going, etc. I am (literally as I write this) in the middle of a 6 TB data backup...well "middle" might be a little generous but you get the idea...anyhow the bottom line in that while I have a LOT of source code on my various dev machines, all of it combined (as well as multiple copies that the VCS keeps) is less than any single data file I am backing up. Having single-character variables, minimal whitespace, etc would save me ~ 0.00000000001% of my drive

[Mario F.]

bool shouldActionBeTaken(int someVal, int somOtherVal, machineState someState);

if( shouldActionBeTaken(6, 2, someState))
{
    // take action
}

I do have a problem with naming conventions that reflect the processing logic instead of the business logic. I could probably never name anything shouldActionBeTaken. If I find myself in a spot where naming something after the processing logic is easier than business logic, that's IMO a clear sign that I overcomplicated my design. I'll probably go back and check what am I doing wrong.

Naturally, if I'm being particular sloppy or it just doesn't matter for that particular piece of code, I don't bother. But generally speaking, shouldActionBeTaken may reveal a design flaw, if the naming was achieved because of clarity.

One thing in this thread that cracked me up is someone going on about the virtues of using little whitespace and single-char variables to save disk space...if your drive space is so limited that you have little room for clean-reading source you have larger issues than just drive space...

Sly was obviously making a joke. I thought it was evident.