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.
Printable View
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.
Style two but often see style one. I normally continue with the style that has already been used in the code to keep it consistent regardless of my personal pref.
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):
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.Code:// 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
}
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 :)
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.
Sly was obviously making a joke. I thought it was evident.Quote:
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...
I'd use Style 2 as well.
Although at work I code in MUMPS, and in that language, there ARE no whitespace choices -- you either do it the way the language expects or you do it wrong. :D
(OK, there is the occasional whitespace choice. If you have a block statement for an IF or FOR construct, you can optionally use exactly one space to indent.)
I think you are concentrating on a name chosen just because a name is needed for an example when you should be concentrating on the idea. If you will, change the name to something like isMarioFied, or perhaps isOld or hasWhiteHair :)Quote:
Originally Posted by Mario F.
Yeah, I revisited this thread sometime later and I agree I missed the point. isMarioIdiot evaluates to true sometimes. :)
Style 2 all the way! Easier to read imo...