I have tricremented your reputation, thanks for sharing. This has caused me to do some ninjawork.
Your one stop shop for the cause of all coding horrors
This is somewhat related. A collection of humorous comments.
http://stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered
http://stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered
I enjoyed this - thanks for sharing.
Also:
Also:
// somedev1 - 6/7/02 Adding temporary tracking of Login screen
// somedev2 - 5/22/07 Temporary my assI enjoyed this - thanks for sharing.
Also:The history of software development in a nutshell.// somedev1 - 6/7/02 Adding temporary tracking of Login screen // somedev2 - 5/22/07 Temporary my ass
When I was just programming for fun, i saw that thread and laughed. Oh how i laughed. Now that i'm getting paid to maintain someone else's code... :(
Yoda
Not forget you must, that in different form, use this construct you do. Yes, yes.
This not like you do:
if(5 == function())
//if five it is, this function
but this accept you do:
if(!function())// if not true it is, this function
(Though I can't help myself stopping completely puzzled for an instant every time I see Yoda code, too)
Then again...
if(!(5== func()) && !other_func())
// If not five is func, and only execute not other func
Maybe, but as the article says, it like saying "if blue is the sky" or "if tall is the man", it's just harder to read this way imo. Forgetting a '=' is not an excuse for writing harder to read code imo, since that doesn't happen very often.It happens an awful lot more than you might expect. Defensive coding is important, and it often comes at a perceived cost to readability.
I'd honestly be rather alarmed to meet a senior engineer who didn't write their conditions that way, when coding in C++.
And, as with a lot of coding practices, it probably varies depending on the kind of company you keep. I predominantly come across this particular convention from engineers who like to follow simple rules but cannot think about the implications of their design decisions or create a decent interface to save their lives. Do I think this is true of all engineers who follow this rule, no. But I do find it hard to shake the weight of evidence I have come across :)
-Josh
Nice article, i personally hate with passion the "Yoda Conditions".
ex: if(5 == count)
I understand why they are done though. If someone mistypes or is just used to a language with only a single '=', and does
if(count = 5)
They will only get a warning (and they didn't always get a warning back in the olden days). While
if(5 = count)
Will error.
And honestly, there should never be a plain number in an if statement anyway, it should be a constant or #define somewhere, like so:
if(kMaxSize == count)
which tends to make it look less nonsensical and yoda like.
Nice article, i personally hate with passion the "Yoda Conditions".
ex: if(5 == count)
I understand why they are done though. If someone mistypes or is just used to a language with only a single '=', and does
if(count = 5)
They will only get a warning (and they didn't always get a warning back in the olden days). While
if(5 = count)
Will error.
And honestly, there should never be a plain number in an if statement anyway, it should be a constant or #define somewhere, like so:
if(kMaxSize == count)
which tends to make it look less nonsensical and yoda like.
Honestly, after so long this stops being a problem, maybe the occasional mistype occurs, but really this is something that's only prevalent in new/inexperienced programmers.
I understand why they are done though. If someone mistypes or is just used to a language with only a single '=', and does
if(count = 5)
They will only get a warning (and they didn't always get a warning back in the olden days). While
if(5 = count)
Will error.
I agree with slicer4ever, thats kind of like saying one should always return a pointer instead of a reference because someone might forget to type the "&" at the receiving variable declaration and create an accidential copy. To sparse of an event to adjust your coding routine to that kind of stuff.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
