Comments On Code Comments? 472
theodp writes "It seems like comments are on programmers' minds these days. The problem with comments, as Zachary Voase sees it, is that our editors display comments in such a way as to be ignored by the programmer. And over at Scripting News, Dave Winer shares some comments on comments, noting how outlining features allow programmers to see and hide comments as desired. 'The important thing is that with elision (expand/collapse),' explains Winer, 'comments don't take up visual space so there's no penalty for fully explaining the work. Without this ability there's an impossible tradeoff between comments and the clarity of comment-free code.' Winer also makes the case for providing links in his code to external 'worknotes.' So, what are your thoughts on useful commenting practices or features, either implemented or on your wishlist?"
Doesn't matter in the end (Score:5, Funny)
Changing the color of the comments, or making them collapsible/non-collapsible isn't going to have any meaningful impact. A rushed or sloppy coder is going to ignore them either way. And a conscientious coder is going to read them regardless.
The real problem with comments isn't their color, it's when they AREN'T THERE AT ALL. You could have the damn things flashing in rainbow colors and it still wouldn't change the fact that the legacy code I'm going over was done by a sloppy piece of shit who never wrote any comments in the first place, or who wrote cryptic/indecipherable comments that would take a linguist 10 years to translate into meaningful English.
Now, if you'll excuse me, I've got to go play Sherlock Holmes with some strange method written by an Indian contractor whose only comment on it was "This move thing around."
Re: (Score:3, Informative)
Going even further - good code generally doesn't need a whole lot of commenting. If you are struggling with this problem of how to display comments, then that says a LOT more about your code than your comments.
(That said, trying to deal with a legacy system, comments can be helpful.)
Re:Doesn't matter in the end (Score:5, Insightful)
if you can't fit the documentation into your method (and variable names), that method is likely too long and complicated.
Re:Doesn't matter in the end (Score:5, Insightful)
Re:Doesn't matter in the end (Score:5, Insightful)
That brought a smile to my face. More than a few times I've put in comments like "yes it's doing it this way for a reason. don't try to optimize it by doing xyz, it doesn't correctly handle exceptional cases x and y. leave it alone."
I don't have a good memory, and my comments are for me as well as for others, even in projects that will never be seen by another living soul. Many times I've looked over some code and thought "that would work better / be so much cleaner if I changed that..." only to see one of my warnings that it had already been attempted and lead to unexpected complications.
But I would like to see more of an option to "collapse" comments. I usually place a comment block above every functional block of code. Most of the time I just need to see a quick one-liner reminding me what all that block does. Other times I need specifics like "this stuff is set on entry, and these things are set on exit" etc. But the detailed comments eat up a lot of screen space and make it take longer to scroll through code looking for things. I'd like to be able to have expandable/collapsable comment details. On a global basis.
Re:Doesn't matter in the end (Score:4, Informative)
Re: (Score:3, Informative)
Yeah, that sounds much more efficient. Nothing like letting the developer work through the (bad) optimization design, code it... get the test failure and then waste more time debugging it instead of just warning them off up front.
Belts and suspenders -- test your corner cases, but document the pitfalls.
Re: (Score:3, Informative)
Re: (Score:3)
Re: (Score:3)
Re: (Score:3)
What I do is put my comments in the same line as the code. When I need to read the comment I just scroll right, but otherwise it doesn't distract me or eats up screen space. If it's too long, I split it up between different parts of the code. For example, I explain what a function does in the line before it, but I detail how it does that (if explanation is necessary) in the body after the lines.
One of my colleagues puts all the comments in his code in a certain column at the right side, typically on the same line as the code itself (following the GNU coding-style). While the comments are useful, they are completely useless in that location; it would be far better to have them on the preceeding line, or in a larger block so that it can actually be seen without scrolling the screen left/right.
Re:Doesn't matter in the end (Score:5, Insightful)
Code, by definition, tells the computer how to do something, but not why. The computer doesn't care why it's adding two numbers together, it just obeys.
Likewise, self-documenting code will only ever tell the programmer how the computer does something, but will never tell the programmer why. That's the job of the comments.
The problem is that most people focus on "how comments," instead of "why comments." They spend their time on the function comment block, describing even the most mundane function in detail (but never actually saying when to use the function or how the algorithm works). Or they spend their time on the comment block at the start of the file (doing the job of your version control software). (The occasional "signpost" comment is a good idea, of course, as is documenting the API. Some "how comments" are still very useful.)
Re:Doesn't matter in the end (Score:5, Insightful)
Likewise, self-documenting code will only ever tell the programmer how the computer does something, but will never tell the programmer why. That's the job of the comments.
Yes.
Hands up who has seen a piece of code like this:
Bonus points if it's pre/proceeded by a complex block of uncommented, impeneterable code.
Re: (Score:3)
Re:Doesn't matter in the end (Score:5, Insightful)
And then the how changes....
// Add 1 to i
i+=2;
I have seen worse. I worked on a project that had a lot of "magic numbers" in the code, so our manager told us to make symbolic definitions for them. One guy put this in a header file:
#define FOUR 4
and then used FOUR everytime he needed that number. Then, you guessed it, someone decided that 4 was too few, so they changed the defintion to this:
#define FOUR 5
Re: (Score:3)
Re: (Score:3)
Those shortcuts are not obvious at the time of coding. I always go back to my code weeks later, when I forgot what I wrote. Then refactor and comment where appropriate.
Re: (Score:3)
Great example of the implications of Godel incompleteness! Unit Tests are awesome, as are other kinds of automated tests, but they are not without their own problems. Say I fall for your argument of adding levels of indirection to the documentation and go to the test for the answer. Will I then find the why of the implementation? Will I find important information about the code, like that it does something different th
Re:Doesn't matter in the end (Score:5, Insightful)
if you can't fit the documentation into your method (and variable names), that method is likely too long and complicated.
This is foolish arrogance. In my thirty years in this profession I have worked with many people who thought their code was 'self documenting'; all of them were wrong, and faced with their own code two years later I doubt any of them could immediately follow it. I've only ever worked with one software engineer who, in my opinion, documented enough; I strive to match his standards in my own code but I know I don't always succeed.
There are, in effect, three reasons for not documenting:
These days I see poor documentation practice as a reason to negatively appraise an engineer; if it doesn't improve I'd seek to move them off my team. There's no excuse. Documentation - like source code - isn't, fundamentally, for you: it's to communicate with your colleagues and to the poor grunt who has to try to maintain your code, long after you've moved on to more interesting projects. And that poor grunt may not be as intellectually gifted as you are.
Re: (Score:3)
I couldn't agree more. No matter how well you code there are always reasons for comments...especially when the nature of what the code is trying to accomplish is complex. Even if your code is perfectly structured and understandable by any good programmer, making someone else reverse engineer that is inexcusable. Another example is when your code needs to do something in what may appear to be round about or unusual manner for some specific reason...because, for example, a more obvious approach causes some
Re:Doesn't matter in the end (Score:4, Insightful)
If your comments are not getting updated, then I suspect you have very poor revision control. I recommend that you take a step back and consider why you are revising the code in the first place. Once you understand why, you need to document it for the next poor sap (recognizing that YOU might be the sap). Only then should you consider how the code should be changed.
Re:Doesn't matter in the end (Score:5, Insightful)
Re: (Score:3)
So basically you are stupid and cannot explain design choices. What other reasons are there to not document it?
Re:Doesn't matter in the end (Score:5, Insightful)
So basically you are stupid and cannot understand code. What other reasons are there to write cute little comments?
Ah yes, the arrogance category. Thank you for your example.
Re: (Score:3)
It seems every single anti-commenting post in this thread is posted AC. There's a reason for this.
Re: (Score:3)
Otherwise, the comments end up being a ton of useless bloat that just makes things harder to understand, not easier.
This right here is more of the reason I completely skip comments when reading code. I haven't read much code where the comments put any valuable content that the code didn't explain better.
Re: (Score:2)
I'd agree only if you're using a language or pre-processor which does design by contract.
Re:Doesn't matter in the end (Score:5, Insightful)
Not at all:
1. Sometimes you're using a confusing and complex feature of some library or server. Providing a comment with a link to the documentation on that feature makes things a lot easier for the next person to come along.
2. Sometimes you're working around a bug in a library. You should leave a comment explaining what the mis-behavior was.
3. Sometimes you're implementing an algorithm that's relatively new academic work. Adding a comment explaining exactly what this is, where you can find it, and why you're using it here will help somebody learn more about it.
4. While expressive code can explain what you are doing, it can't explain why you're doing it. If your method is called "zoich_the_fleemoid", your comments about this should probably provide some kind of indication of what a fleemoid is and why you'd want to zoich it.
5. Anything residing on a major code boundary (e.g. a library method relied on by other developers) should get the full round of documentation - what it does, what it accepts as parameters, what it does with those parameters, what it returns, and what side effects are expected. Yes, your code should be clear enough that the other devs could learn this stuff by reading your code, but they shouldn't have to dive into it to figure out what your APIs do.
It's a very rare case where I think a programmer wrote too many comments.
Re:Doesn't matter in the end (Score:5, Interesting)
I was very amused when Donald Knuth announced Literate Programming, since I'd been doing something quite similar for years, although there weren't any automated tools back then.
First I wrote WHAT the function was supposed to do. This was the comments.
Then, I wrote the code to DO it.
If I did the job right - and kept the comments up to date (people really manage to do that?), then when I came back to make fixes or improvements, I'd know what the code was doing and what the likely consequences of changing it could be. Including the less obvious ones, such as things that depended on subsidiary routines.
I have extra incentive to write good comments these days. Back then, major systems often had program logic manuals. These days, the apps are more complex, but the time to sit down and write a PLM is rarely there. However, if the comments were well-done, tools like Oxygen and Javadoc can generate a fairly decent substitute.
Removing comments from code (Score:5, Insightful)
I also think that comments describing interfaces are better than comments describing processes. This is the old thing of "describe what the module does and leave the description of how the module does what it does to reading the actual code." So preambles describing the parameters a function takes and valid ranges on those parameters are most useful.
The other thing about comments is not so much the writing of them but the keeping them up to date. The compiler doesn't check that the comment is still relevant to a function you have changed.
Re:Removing comments from code (Score:5, Funny)
in the case of some inglorius hacks documenting WHAT YOU WERE DRINKING at the time may be the most useful (or what you were on or the fact that you were on hour 47 of your shift...)
Re: (Score:2)
Re: (Score:2)
Re:Doesn't matter in the end (Score:5, Insightful)
int GetNumberOfUsers(int category_id, int country_id, int company_id)
{
int num_users=0;
DBConnection db=new DatabaseConnection('central_database');
if(db==null){explode();}
db->Close();
return num_users;
}//GetNumberOfUsers(int category_id, int country_id, int company_id, int some_param_that_used_to_be_here)
The key information should be put into the naming of the variables, functions, and classes. Comments should be reserved for almost a conversation with another programmer. Magically perfect code should in theory have zero comments.
x=x+1;
x=sqrt(sin(log(y)/pi)*e);// this is the lambert/highlander formula
x=lookup_table[y];
x=sin(tan(cos(x)));// If I knew my trig better there must be a better way to condense and speed this up.
Re: (Score:3)
When writing computer code, and either using or reusing previous sections of code, the key question is how much mental energy and attention units will it take for the next programmer (who may be you in a months time), to gain a workable understanding of the function.
As humans, we only have attention units enough to keep a limited subset of items (maybe 5-7) in our heads at any one time.
If code is badly written and/or documented, then its going to take more mental energy (and time) to relearn the code than i
Re:Doesn't matter in the end (Score:5, Funny)
THIS. I deal with sloppy coding convention all the time but at least when the code is commented I can get a mile-high view of what each section is doing w/o having to spend time carefully piecing the work apart to figure out what happened.
The lack of comments for others is annoying but I really want to know how people go back into their own code several weeks (or even days) later and know what the hell they did when there are no comments.
Many times I have run across a commented section of code that reads something like:
I can only shake my head at myself ;-)
Re: (Score:2)
THIS. I deal with sloppy coding convention all the time but at least when the code is commented I can get a mile-high view of what each section is doing w/o having to spend time carefully piecing the work apart to figure out what happened.
Not all comments give you a mile high view. Some are just pointless wastes of disk space...
Re: (Score:3)
The "TODO" flag isn't what's wrong there, the "this" part is. It's obvious that the TODO relates to the nearby code (this, not that). It's still not obvious what needs to be fixed. It could be a lack of performance, error handling, input validation. Some use-cases/states/values might not be covered/tested/identified or implemented. But the answer is always: why. Ask yourself "why am I adding a comment here" and the answer is the perfect comment.
Re: (Score:3)
Preach! If anyone needs an argument for readable code and appropriate comments, it's this above, perhaps paraphrased: "The poor slob maintaining your work may be you."
Re:Doesn't matter in the end (Score:5, Funny)
/* Attention future Bill: this section of code sucks and it looks horrendous and awful but I wrote it under a tight deadline. Just hit F3 and let the bitch run; it works, I promise. */
Makes you want to kill Bill, doesn't it?
Re: (Score:2)
A rushed or sloppy coder is going to ignore them either way. And a conscientious coder is going to read them regardless.
A rushed or sloppy coder is going to read them and rely on them regardless of what the code says.
A conscientious coder is going to know they're wrong. Either the code is clean and self documenting in which case it doesn't need comments and even if they're factually correct they're wrong because they're not needed and might not be maintained with the code and if the code isn't clean and sel
Re: (Score:2)
I don't know what code you're reading, but the legacy code I get is anything BUT "self-documenting." Hell, I don't think Ken Burns could document most of the garbage I seem to always get stuck with.
Re:Doesn't matter in the end (Score:5, Insightful)
The problem with that is there seem to be a lot of people who say, and possibly even believe, that their code is clean and self documenting, when in fact it is anything but. I would say that such people outnumber those who actually do write clean and self-documenting code by a significant margin. In those cases, where you find yourself looking at this code and realise you have no idea whatsoever what it's trying to achieve, much less whether it's doing it right or not, and you're thinking "just give me a f*@king clue, goddammit", any sort of comment, even a cryptic, half-assed effort, can be a lot better than nothing.
Re:Doesn't matter in the end (Score:4, Insightful)
Exactly my point.
The people who write code like this don't know what it is doing when they write it. Therefore, by definition, at best their comments will tell you what they *meant* to write.
Given that this code is now 10, 15, 20 years old, other programmers along the way will now be relying on what this code *actually* does.
It's one of my pet peeves that people want to rewrite code when they *can't* understand it. But in order to rewrite code like this you *have* to understand it. I've seen so much rewritten code that is even worse than the code it replaced because it's full of hacks reproducing all the accidental behaviour in the original code and introducing its own accidental behaviour along the way.
It is a wonderful thing to be given the chance to rewrite a piece of obnoxious code. But it's an expensive process with a lot of up front research and, is always harder than fixing that obscure bug in the obscure code *except* when you've already proved that the obscure bug *cannot* be fixed in the old code. But in that case you're already admitting that the rewrite will change some behaviours.
Tim.
Re: (Score:3)
code usually will not tell you why something is done this or that way. at most it will tell you how it is done (and even then, not always).
also, even when you think you know what exactly code does, you usually do not see the "big picture". in any software that's more complex than a few operations there will be algorithms that can not be understood from a couple of functions. this is where comments can help enormously, as the overall logic can help to avoid silly mistakes.
the problem with "code does not matc
Re: (Score:2)
Changing the color of the comments, or making them collapsible/non-collapsible isn't going to have any meaningful impact. A rushed or sloppy coder is going to ignore them either way. And a conscientious coder is going to read them regardless.
The real problem with comments isn't their color, it's when they AREN'T THERE AT ALL. You could have the damn things flashing in rainbow colors and it still wouldn't change the fact that the legacy code I'm going over was done by a sloppy piece of shit who never wrote any comments in the first place, or who wrote cryptic/indecipherable comments that would take a linguist 10 years to translate into meaningful English.
Now, if you'll excuse me, I've got to go play Sherlock Holmes with some strange method written by an Indian contractor whose only comment on it was "This move thing around."
The Zen was it not moving around.
Re: (Score:2)
On the other hand though I did like the ideas about having hyper-links in your comments just from the perspective of I can link in the original requirements from whatever ALM system they make me use and then anyone coming along could see the whole change history and hopefully identify & castrate the fucknugget who
Re: (Score:2)
Now, if you'll excuse me, I've got to go play Sherlock Holmes with some strange method written by an Indian contractor whose only comment on it was "This move thing around."
Oh, that comment? I know that guy. It must have been written by Lakshmanan Sivaramakrishnan Sethuraman Aiyer. He had the policy, "no comment I write would be longer than my name".
Re: (Score:2)
Bitrot (Score:3, Insightful)
Re: (Score:3)
Comments suffer from incurable bitrot.
It's curable -- all it takes is making sure that any time the code is changed, the associated comments are updated to match.
Of course, making sure that programmers actually do that is easier said than done, but the way to maximize the likelihood of that happening is to make sure the comments are as close to the code as possible -- preferably on the same line, or right above/below it. Comments that are off-screen (or worse, in a different file) when the code is modified are very unlikely to be updated in a
Re: (Score:3)
It also relies on the coder trusting that the comment is accurate. Are you writing a program to do a specific task or writing comments to do that task? I put more faith in the code (because that's what the compiler runs) over the comment. If the comment says one thing and the code does something else, I'm willing to bet the code is more accurate. If I rewrite the code to match the comment, I may have just re-introduced an old bug. Now I have to go back through the file history to figure out if this was
Re: (Score:3)
The real problem with comments isn't their color, it's when they AREN'T THERE AT ALL
Bad comments are worse than no comments. And good comments become bad when they are not being maintained along with the code.
I think it is a question of attitude; people in general do not think of documentation and comments as being as important as the code, and it starts at management level. But there is another side to this problem: people have not been taught how to comment well, so actually, the problem to some extent starts even before project leaders get their grubby hands on things.
And writing good c
Contrast (Score:3)
If your aim is to make something more visible, don't pick a yellow-on-white colour scheme.
Re:Contrast (Score:4, Funny)
Could be worse. They could use white on white.
In My Opinion This Is a Non-Story (Score:5, Interesting)
The reason editors let you collapse comments is that you sometimes have to make really ugly code -- whether it's for performance or time constraints. And the only way to really describe it actually larger inline blocks that can obfuscate the code. So they make them collapsible for those who have read them already.
Winer also makes the case for providing links in his code to external 'worknotes.'
Yeah, we use an internal wiki.
So, what are your thoughts on useful commenting practices or features, either implemented or on your wishlist?
The biggest complaint I have is people who use comments to explain bad object/procedure/function/method/script/class/whatever naming. For example, a guy I worked with calls everything a "driver." Main method? That's a driver. Class holding the main method? Of course DriverClass. Package? Of course YYY.ZZZ.NNN.Driver. On it goes. Another guy likes to use the verb "interrogate" where as I like to use the verb "inspect" and I think that's just more about your origins (I think he's Spring background while I'm a little more on the Ruby/Groovy side of things). A common and well defined vocabulary inside your team and embedded in your actual code will take you much further than trying to explain it all out in the comments.
Re: (Score:3)
Lets not forget (probably misguided) policy. A lot of places have policies that say you MUST have multi-line comments for each class/function/whatever. Being able to collapse those down makes
Use vi (Score:3, Insightful)
Use vi. Always works for me.
There's No Impetus for Comments (Score:3, Interesting)
...because most organizations are total failures that make you write and maintain thousands of pages of "design" documents that are actually just the code-base itself converted line-by-line to English sentences. Thus, no comments are ever written, because the developers are already maintaining two instances of the entire code-base.
Getting developers to comment (Score:5, Interesting)
At my current job, most of the developers think commenting is weak. I've dealt with this problem before, but it's awkward when I'm the only one that wants to comment. Funny thing is, every time we hit a program that a former developer wrote that my boss can't understand, he makes us rewrite it. Having comments in the code might save a lot of development time.
When I managed a team, I required commented code. It saved our butts more times than I can count. I also use it to look for bugs. It's amazing what code review can do a few weeks after you wrote something or having another developer look at. When code doesn't match comments, there's a bug.
Re: (Score:2)
When code doesn't match comments, there's a bug..... When I managed a team, I required commented code. It saved our butts more times than I can count.
What if the code is correct, and the comments are wrong? Sure, that may be a bug in your eyes, but why spend the time writing incorrect comments?
.
If the "required comments" saved your butt more times than you can count, that shows that your coding team members can write sentences better than they can write code. Perhaps your team members are in the wrong profession, or maybe you need to improve the ability of your team members to write high quality code.
Re: (Score:3)
Not at all. Extremely complex systems can be hard to trace the codepath through. Someone putting comments into a function to explain how it interacts in the greater scheme of things can be extremely helpful.
Comments aren't meant to explain code. You should be able to read a for loop. But if I'm in the middle of a function that's crashing and there's a comment telling me how this function interacts with the SYSTEM, then I can understand the CONTEXT of the code and more easily find the error. Otherwise, it's
Other Things on Programmers Minds (Score:2)
>> It seems like comments are on programmers' minds these days
Really? I'll bet the new round of browsers, iOS, Windows 8 (have you seen how many APIs and visual paradigms are broken?) and any number of other major platform changes are much, much more on the minds of programmers these days.
>> Winer also makes the case for providing links in his code to external 'worknotes.'
Oh God - one of those people.
Good comments are good. (Score:5, Insightful)
I don't really understand why we're going over this for the 50 thousandth time on slashdot, but as always, good comments are good, bad comments are bad. Comments that describe the interface of the function you created and how its supposed to be used are good. Comments that say "increment the variable" are worthless and perhaps worse than worthless as they add maintenance problems when the underlying code is later changed and nobody bothers to change the comments as well.
Save time (Score:4, Informative)
Comment first, fill in the code later.
Re:Save time (Score:5, Insightful)
Comment first, fill in the code later.
Yes. And as you write the code, make it clear enough that you can then eliminate the comments. If your comments are this:
Then your code should look something like this:
void
main(int argc, char *argv[])
{
processCommandLineArguments(&argc, &argv);
readInputFiles();
processData();
outputResults();
}
and now the comments are no longer needed. So you should write comments first, then write the code, then look at each comment and try to eliminate it by making the code clear enough that the comment is superfluous.
Re: (Score:3)
Clarity (Score:2)
Without this ability there's an impossible tradeoff between comments and the clarity of comment-free code
As far as I'm concerned, there's no such thing as comment-free code that is clear.
Re: (Score:2)
Really?
So even a simple method that just load some stuff into a hash and then returns the value that matches the key it was given should be commented?
At some point the code is so simple it comments itself.
Re: (Score:3)
Really? So even a simple method that just load some stuff into a hash and then returns the value that matches the key it was given should be commented?
At some point the code is so simple it comments itself.
Sure, because then the next coder, instead of saying
can say:
Re: (Score:2)
i++
Those sweeping generalizations will get you every time.
Re: (Score:2)
Really, if you want to see code that clearly specifies what it does, you need to look at higher level languages. Prolog comes to mind here, as
The problem with comments ... (Score:3)
There's also nothing worse than a comment that states the bloody obvious. If I'm clearing a register to zero I don't need a comment next to the SR 6,6 or XR 6,6 that is performing that action. I can read the code to see what the bloody code is doing.
The time that code needs a comment is when you're shifting bits or multiplying something by a funky/obscure value for a sensible reason but the reason isn't obvious by simply reading the code.
Also remember you don't get the comments in the post mortem storage dumps when you're trying to fix someone's programming error at 2:30am with a few managers breathing down your neck panicing that it won't be fixed and running by 8:00am.
Keep them short but pertinent (Score:2)
What other engineering disciplines do. (Score:5, Informative)
I'm a mechanical engineer. Our "code" is models and drawings. These are what represent the real world objects in our designs. But you don't just deliver a set of drawings as a product. You have Analysis Reports, Design Manuals, Operation Manuals, Maintenance Manuals, Parts Lists, Concept of Operations, and about 20 other documents that describe the system you built. Sometimes a good engineer can pick up the drawing package and figure out how the thing works. But if you really want to understand the design you have to read the other products. If those products don't exist you end up reverse engineering from the design.
Write clear code, remove comments (Score:4, Informative)
I used to put a lot of comments in my code. Then I read the book Clean Code [amazon.com], and it changed the way I look at comments. Basically, every comment you leave in your code is an admission of defeat: you were unable to write your code clear enough to eliminate the need for the comment. Today, I write my code with comments, and then I go back and try to eliminate each comment by making the code clearer instead. So instead of
do_args(&argc, &argv); // process command line arguments
I do this:
processCommandLineArguments(&argc, &argv);
and the comment is no longer needed.
Today, my code has far fewer comments, but is easier to read and understand. The few comments that are left are usually block comments that explain why something is done, or outlining how the code could be improved or expanded in the future.
Re: (Score:2)
Something that's often said in combination to what you said is to keep your functions short (like 7 code lines).
Most people will whine at that, but the fact is you can't hold more than 7 lines in your head anyway. And, like you said, your code should just be a sequence of very explicit functions:
adjustColor();
scalePicture();
cropPicture();
addWatermark();
and the same in each of those functions.
(These guys [infor.uva.es] say 62, YMMV)
Re:Write clear code, remove comments (Score:5, Informative)
Comments aren't just there to explain the code. Of course you should write clear code. But I work in the games industry; there are times where clear code is thrown under the bus for the sake of efficiency. There are annoying convoluted constructs that are optimisations but they read like someone just showing off.
But this speaks to a fundamental misunderstanding of what comments are for. You're not explaining the code, you're explaining the algorithm and the basic thing that your code is meant to accomplish. You don't write comments to let people know that you're looping over an array, you write comments to let people know WHY you're looping over an array and why they should care. I'm all for verbose variable names, but if you're going over 132 columns I'm already irritated. Go on for 80 more and it's tremendously annoying to read the 'clear' code.
There are a lot of different ways to solve problems. Ideally, your comments should lay out what your thought process was when you were solving this particular problem. If you leave, someone will understand the problem you were trying to solve, and that context makes reading the code easier.
And even if you don't leave, it's a good shortcut for yourself if you have to come back to that code several years later. I've saved myself a lot of time by commenting things well. Five years is long enough for my thought process and problem solving methods to change, so when I look at the code and wonder why in the hell I did something in such a dumb way, the comments tell me what was going through my inexperienced head.
Lastly, and perhaps most importantly, humans don't agree on the meanings of words. There is some research (that I've read in passing; no citations at the moment) that says that we all have our own meaning of words, and we all speak completely unique languages that just happen to overlap with other people's unique languages. To write code that is universally understandable, you need to write code that has a completely unambiguous context to all people at all times (well, more or less). As someone that works in a heavily bilingual office (in Montreal), you can't guarantee that the programmer before you had the same interpretation of things that you do.
Re:Write clear code, remove comments (Score:5, Insightful)
And if I'm off the street, new to the company and see your line:
processCommandLineArguments(&argc, &argv);
Sure, I know what the function -likely- does, based on the name.
Now how about the other questions.
1. why does it need to process the command line arguments.
2. what are the command line arguments that you are passing in.
3. what is the error control of that function if given improper values.
4. what is the error control of that function if given too many values.
5. how many arguments total can it handle.
6. what is the syntax it expects for the arguments
7. are there any global variables being defined or redefined in that function.
You take a lot of things for granted that a lot of other developers will be looking for.
This, is why documentation is needed. I don't believe at all it's an admission of defeat. I believe it's an earmark of a beautiful programmer. Just because your code is insanely clean and documented, in itself, does not mean you should omit the block of description for variable calls, error return calls, exceptions, limits, and any global declarations. And while including this into a centralized wiki is good, I'm sure coders will not be inspired to cross-reference a program with a wiki and keep doing searches for function names. It breaks down their train of thought and frankly slows down productivity.
Assuming others can just understand it without the documents would be arrogance.
Re:Write clear code, remove comments (Score:4, Interesting)
You missed the most important one:
8 - Why the hell are you passing in *pointers*? Is your broken-ass processCommandLineArguments() actually going to screw with them?
It depends on the comments (Score:5, Interesting)
"What the f*** is this doing?"
"TODO: fix"
All of the above are useless comments, yet they seem to sneak into everything. Worse still are comments that are meaningless to anyone who did not write them, or comments that make reference to undocumented conversations (e.g. "This is the implementation we spoke about on Tuesday").
Don't waste time writing useless comments. If you do not have time to fix a function, the comment should explain what needs fixing so that someone else can do it without first spending half a day debugging.
Don't mind me (Score:5, Funny)
Collapse the code, not the comments (Score:3)
Then you can read what the code is supposed to do and understand how it is supposed to work.
Next, you uncollapse the comments, see what the code actually does, and fix it.
Re: (Score:2)
Uncollapse the *code*, I meant, of course.
Wishlist (Score:2)
Ok, it's not a list per se, but what I would like to see is an editor that automagically makes the comments on any given lines a tooltip when you mouse over that line. To me, it seems the most intuitive and unobtrusive way to deal with comments, but maybe I'm wrong.
Comments are usually as good as the code (Score:3)
Anyway I remember discussing comments vs self-explaining code with a coworker. Eventually we ended discussing magic numbers (usually they warrant SOME explanation), he just told me he used #defines which made thing a lot more clearer. After the coffee, I checked some of his code:
#define ONCE 11
#define DOCE 12
(In Spain bank accounts have a simple check embedded so you can easily verify is a bank account number is incorrect, and the algorithm requires to validate the results of the calculation with the values in positions 11 and 12).
Ignoring the comments is the wise thing to do. (Score:3)
When I was in grad school my thesis guru believed in a tool called fweave and ftangle. You write code in a c like syntax, along with comments that are regular TeX or LaTeX files. Then send the code through fweave and you get a regular TeX formatted document that can be viewed in ghostscript or printed postscript. Send the code through ftangle, you get a valid FORTRAN code that can be compiled and run.
It worked for him because he keeps getting a stream of grad students and the code project has to be perfectly documented for the next student to continue the work. But in companies where technical specialists can occupy a position for many many years along with constant pressure to add features, the first thing that get dropped is code documentation.
For example I have been shipping my product for 16 years now. So many of the functions I write are fleeting and have low half-life. They often start out as a debug function to help me understand some issue, which might not even get checked in. But a few get checked in, first invoked in debug builds alone, then in release builds under env flags, then slowly they morph into sanity check function or an audit method, then a verification procedure, then eventually a special case detector for some feature. When it was first written it does not appear to be worth commenting well. By the time it is part of the feature, it is considered too late to spend resources to comment it.
My comments... (Score:2)
I have a tendency to be terse with comments, but say enough to make it clear, if I don't feel the code does. Sometimes though, I add in a joke or pun (like, in AIRC, I have a comment "play the server game of ping-pong").
-uso.
No comments == Job security (Score:2)
It's Another Way To Tell What They Were Thinking (Score:3)
Subtle clues tell me how much code I'm probably going to have to fix in the maintenance of an application. Comments could tell me if the programmer considered a section of code to be temporary with replacement needed, or if the function I'm looking at is a crucial part of the application. One of the best projects I've ever worked on had the requirements that had driven each function at the front of the function. That made it very easy to focus design and refactoring efforts where they were really needed.
I recently inherited a ten-year-old heap of perl code, on top of which someone had piled a ruby wrapper. There's a lot of functionality that's duplicated between the modules of both languages, and refactoring it all is going to be a nightmare. The code could be in a transitional state where the design is not where I want it for easily a couple of years. I've liberally sprinkled it with todos and comments where I'm putting new code, so the next poor sucker who gets this thing maybe doesn't have to start completely from scratch.
Comment lightly and relevantly (Score:2)
For example, Eclipse gives a nice preview of methods and pulls in the javadoc into the tooltip when hovering over the comment. Therefore, I try to keep these up to date.
On the other hand, comments that just say the method name, or cannot be expected to be maintained, should not be created.
On the point of good code, yes you can write good code and reduce the need for comments, but there are just times when a comment is necessary.
Incorrect comments (Score:2)
Seeing the forest for the trees (Score:2)
To ensure that important information springs to the foreground, comments should exist primarily to document something which is not obvious from the code itself: requirements justifying the code, rationale for a particular approach, explanation of complex logic, and the occasional TODOs and FIXMEs.
For example, a method on Person called setName() does not need a comment "This sets the name of the person."
Additionally, there is no need to pepper "// end if" and "// end while" and "// end method" comments all o
Comments are useless, learn to read code (Score:2)
The problem with comments is that the code is Dynamic, the comments are Static.
Someone can write code and write beautiful, fully descriptive comments, which are valid for about one iteration of the project. Then the same or other developers will come along and change code to match new expectation and functional requirements, and NOBODY ever updates the comments after the fact.
Also, comments can be pretty useless. I tire of seeing comments and summaries on classes which basically paraphrase the name of the
TFA sucks (Score:4, Funny)
As soon as I saw that the guy wrote "UX" I knew I was probably dealing with an exceptional moron (how that one acronym has turned into such a reliable red flag, I don't know, but look around and try to tell me it isn't true), but I still had no idea just how badly the article would go. It's not even stupid. It's just .. nothing.
The guy's argument is really that his text editor's preferences are/were set to something he doesn't like.
I shit you not. His editor's preferences were something he considers to be not-quite-right, and he noticed that it wasn't working well for him, and then somehow that turned into a programming article.
I can't even follow through on my "UX" prejudice and say "Aha! See? The guy knows nothing!" because he's taking it to the next level, so that from now on when I see "UX" it'll be "Aha, See? The guy says nothing." Although now that I think of it, maybe that's what the "UX" red flag has really always meant, all along. Hmm. Ok, you did give me something to think about.
All comments are lies. (Score:5, Interesting)
That sounds harsh, and of course it doesn't fit 100% of the time, but if you look closely enough it is true a frightening part of it.
The only thing you can trust is the code.
When I write comments it is usually to say "this code might look like an opportunity for this or that refactoring/optimisation. Don't do it becauase..."
Yes, ideally the code should express this directly, and commetns are an admission of defeat, but sometimes we are defeated.
Re:All comments are lies. (Score:4, Funny)
You mean something like this:
?
My views (Score:4, Interesting)
From my blog:
http://madsoftware.blogspot.com/2007/06/my-confession.html [blogspot.com]
I have a confession to make. Forgive me. Wait, don't forgive me. I'm completely unapologetic. I am a programmer, and I don't write comments. I just needed to get that off my chest.
I don't believe in comments.
I have been writing a lot of fairly complex code lately. And all the while, the voices of dead Computer Science professors have been speaking to me. They repeat the mantra of good code commenting. I feel guilt, like when I go to church. Or when I don't make my bed in the morning. Of course, not one of them is able to give me any good suggestion of what a good set of comments is. They just tell me what isn't a good comment. So does that mean that anything else is a good comment? Like lots of swear words in the code. That's probably more useful than real comments, because they make me laugh and keep me from falling asleep at the keyboard.
Good comments, I'm told, are not just a rehash of what is already in the code. Well, if it isn't already in the code, then it isn't much use to the program is it? I don't believe in comments. I think they are mostly a waste of time. Maybe not for you, but for me they just make my life difficult. I have to make a context switch to English in order to write them. That takes time and just serves to confuse me.
Whenever I write English, I take the audience of my writing into account. Who is the audience for my comments? Some moron with a basic C++ book on his desk? Or the great man himself, Bjarne Stroustrup? Bjarne is pretty smart and will probably be able to figure out my code just fine without me, or my comments. Because he speaks C++. I speak C++ too, so that's how I like to communicate with computers and other people who speak the same language.
So I don't write comments. I'm one of those people who likes to use good variable names, good function names, and good file names. When I look at others' comments, I don't usually trust them, because they often don't make any sense. Or they are just plain wrong. That's just awesome. Like the time I first starting programming and I spent two days wondering why the second member of a pair of ints (pair) was always zero, even though the comments said it should contain some valuable piece of information. Actually, it was the first member, not the second one, which I finally figured out by actually looking at the damn code. Wonder of wonders, the code actually told me what the code did. Amazing.
I think that instead of comments we should put quotes of great authors at the top of all our code. That way, when people read our code, they will think that our code is profound, because we quote the greats of our time like, Dostoevsky, Helen Keller, or Dave Barry. And the best thing would be to just randomly pick those quotes so that when people try to make some connection between the code and the quote, they'll spend lots of time trying to figure out. Then they'll feel stupid, but won't want to admit it and we can fun of them when they can't explain the connection. And we won't have had to be smart at all, because all those people that we referred to are smart.
Have I even written comments? Of course, I slap all my comments in the headers, when I don't feel like writing documentation. Or when the function name is getting too long. Or when some fellow programmer makes me feel guilty for not following the religion of comments. What is the point of writing commments if the function name tells the whole story? Take vector for example, the size() function returns, guess what, the size of the vector. I know what you're thinking, that is completely non-intuitive. It's got to be commented. Look, if the function name can't tell you what the function does, then maybe you should change the function name. And if your function name gets too long, then maybe your function is doing too much.
Good, maintainable programs are easy to understand not because they hav
Re:My views (Score:4, Funny)
Transfer this guy to maintenance programing for a year.
Re: (Score:3)
no thanks,. he will just put in a bunch of code he believes is obvious without taking into consideration any outside system the piece of code might be using.
Transfer him to McDonald's trainee.