|
OriginalGriff wrote: Would have gone down really nicely with a beer
No beer to buy in the entire airport?
|
|
|
|
|
Nor on the planes...
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
|
|
Pakistan, when it was feeling particularly Islamic.
Pakistan Air was fine - good, new planes; good food; good staff. And no beer.
But...the alternative was communist era Aeroflot.
Easy choice.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Life over vodka. Good choice.
|
|
|
|
|
Very Exciting game!!!
|
|
|
|
|
I was thinking about the things that bug me and came up with a short list
- No comments. I know - let's have a religious war etc, but I find no comments dangerous.
- using o as a variable name. In fact using anything that's not sensible.
ctx , dr_rfp_ptr , i2
- Bad formatting. It's like walking into a house and being unable to sit down because of empty pizza boxes on the couch
- Mystery side-effects in code.
- Magic numbers
I'm guilty of 2 of these on occasion. What's your list?
cheers
Chris Maunder
modified 24-Jun-14 15:03pm.
|
|
|
|
|
6. Leaving commented-out code hanging around too long
I'm guilty of that one quite often.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Sonuffah!!! Beat me by 3 mins
|
|
|
|
|
same goes for me!
.:>GSN<:.
|
|
|
|
|
Too long? I want to kill you if you don't delete old code. That's why we have (I have, but it's hard to convince people to use) version control.
There should be 0 old code commented. One time I just deleted all comments that where not proper "human" language, except for code examples, because they're the only exception to having code in comments.
|
|
|
|
|
Luiz Felipe Stangarlin wrote: I want to kill you if you don't delete old code.
Maybe you should cut down on the caffeine?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
My pet-peeves are all of those, especially comments where it is not immediately obvious what the intention of the code is.
and
7: People that tell you their code is 'self-commenting'.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
Those who seek perfection will only find imperfection
nils illegitimus carborundum
me, me, me
me, in pictures
|
|
|
|
|
mark merrens wrote: People that tell you their code is 'self-commenting'.
Sometimes, it is though.
if(IsUserValid(user))
{
UpdateUser(user);
}
else
{
MessageBox(error);
}
In that snippet, the comments are sorta annoying.
|
|
|
|
|
But mostly, when they feel the need to tell you it is, it isn't.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
Those who seek perfection will only find imperfection
nils illegitimus carborundum
me, me, me
me, in pictures
|
|
|
|
|
That isn't self-commenting code, it's badly commented code.
Those comments are worthless - but that's not to say that some comments wouldn't be helpful
PooperPig - Coming Soon
|
|
|
|
|
Agreed.
I felt that the comment for UpdateUser();
Should have indicated what information was being updated in which direction...
// Grab DB Information and load into object
or
// update DB with current user information
Because I have NO IDEA which direction that update is operating, although I guess I could look
But those comments in his example are USELESS comments, which are worse than no comments, because they give
you false security.
|
|
|
|
|
That's got nothing to do with self-commenting code, it's just that the comments are pointless - which is yet another bad programming habit:
n+1. comments that state the obvious
In your example, comments could still be useful if they pointed out e. g. what is expected of the user object to be considered valid, what is expected of the user to fix the problem, or if the user not being valid may be an indication of an internal error, because the user object is expected to be in a valid state upon calling this function.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Nish Sivakumar wrote: Sometimes, it is though.
not really - the comments that are there are irrelevant but the ones that are needed are missing.
The user is valid so why does it need updating?
|
|
|
|
|
// check if user is valid
if(IsUserValid(user))
{
// update the user
UpdateUser(user);
}
else
{
// show a messagebox with an error
MessageBox(error);
}
Worthless comments, agreed...but doesn't mean comments aren't expected.
I'd much rather have a comment at the beginning of the code segment saying what this chunk of work means, rather than what each step does...for example:
</twocentsworth>
I used to call it "Super Happy No-Pants Wonder Day"! It turns out that the police just call it "Tuesday". Go figure...
|
|
|
|
|
This is how I try to comment. If the code section is complex I'll put comments that refer to the overall comment just to help the reader track where in the logic we're running. For instance
/*
* There are several constraints that need to verified.
*
* Constraint 1:
* Constratin 2:
*
***
*/
In the code I'll put a comment to provide a quick reference to each constraint right before I start checking that constrain.
|
|
|
|
|
There is a saying that goes something like "you can tell how smart someone is by how much they agree with you". Kudos to every one of these bad coding habit comments! I can tell every one of you has not only developed, but MAINTAINED real life code!!!
I would like to make one more statement in favor of good comments. In the classical book by Fred Brooks (The Mythical Man Month), he stated "always throw the first version away". When I am about to code something non-trivial, I almost always write the comments first, as I consider that my "first version". I figure that if I cannot describe in words what I need to do, then I probably can't describe it in code either.
|
|
|
|
|
Normally happens if you write the comments before you write the code. It is just forgetting to remove the obvious comments after the code has been written.
|
|
|
|
|
I'd add :
6) Leaving commented out code in source control.
|
|
|
|