Forgot your password?
typodupeerror
Programming

Comments On Code Comments? 472

Posted by Soulskill
from the ehhh-i'll-add-comments-later dept.
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?"
This discussion has been archived. No new comments can be posted.

Comments On Code Comments?

Comments Filter:
  • by crazyjj (2598719) * on Friday September 07, 2012 @08:30AM (#41259253)

    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)

      by Anonymous Coward

      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.)

      • by Anonymous Coward on Friday September 07, 2012 @08:42AM (#41259377)

        if you can't fit the documentation into your method (and variable names), that method is likely too long and complicated.

        • by Dan Dankleton (1898312) on Friday September 07, 2012 @08:48AM (#41259445)
          Not necessarily. Good code can show what is being done, but it can't show different approaches which were rejected. Comments can explain why certain shortcuts are valid or not valid in a way which won't be obvious from the code.
          • by v1 (525388) on Friday September 07, 2012 @09:32AM (#41259989) Homepage Journal

            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.

            • by Jake Griffin (1153451) on Friday September 07, 2012 @10:44AM (#41260769)
              That's why you have TEST CASES for cases x and y; so that if someone ignores the comment, tests will break alerting of an issue!
              • Re: (Score:3, Informative)

                by SDF-7 (556604)

                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)

                  by Jake Griffin (1153451)
                  I'm not saying that you shouldn't document it too. Sorry for misleading you. I'm all for documentation of these things too. But people frequently ignore documentation, so having the test case there too helps to prevent broken code from getting into production.
                  • what i see the most is there's no separate set of eyes looking at a bit of code about to be released to production. the developer is left to test his own work (usually without test suites, because if you have those then you are probably not the only one looking at the code either), and there are so many ways he can get it to work on his own machine while it breaks for everyone else. bigger companies/bigger projects will have a qa/qc/uat/whatever process before release, but it seems like the majority of prog
            • My comments tend to be more along the lines of 'Don't quite know how I wrote this, but it seems to function.' I'm just a hobbyist, but I suspect that more than a few mega-corp software engineering projects are the same. At least I don't use 0xB00B135
          • by c++0xFF (1758032) on Friday September 07, 2012 @09:47AM (#41260105)

            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.)

            • by serviscope_minor (664417) on Friday September 07, 2012 @10:14AM (#41260401) Journal

              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:

              //Add 1 to i
              i++;

              Bonus points if it's pre/proceeded by a complex block of uncommented, impeneterable code.

          • by Bigby (659157)

            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.

        • by Simon Brooke (45012) <stillyet@googlemail.com> on Friday September 07, 2012 @09:06AM (#41259653) Homepage Journal

          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:

          Arrogance
          'My code is so clear and elegant it needs no documentation'
          Procrastination
          'I'm too busy just now, I'll do it later'
          Obscurantism
          'If I don't document my code, no-one else will be able to understand it so they can't sack me'

          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.

          • 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

        • by afidel (530433)

          I'd agree only if you're using a language or pre-processor which does design by contract.

        • by dkleinsc (563838) on Friday September 07, 2012 @09:24AM (#41259899) Homepage

          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.

        • by RabidReindeer (2625839) on Friday September 07, 2012 @09:39AM (#41260049)

          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.

      • by Latent Heat (558884) on Friday September 07, 2012 @08:44AM (#41259397)
        I think it is a good design rule that if you have a comment describing some inglorious hack, maybe you could rewrite the code to remove the comment along with the hack?

        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.

      • by Valor958 (2724297)
        For the legacy coding point, I'd like to make one suggestion on commenting. At the time that code was written, it wasn't 'legacy' code... but they still chose to comment (however poorly). I would suggest commenting where ever possible to clarify intent as you never know who will be fixing your code, and when people will be complaining that IT is legacy code. For the relatively minor amount of coding I have directly done, I commented a reasonable amount so as to locate code segments quickly and for others re
      • by Verdatum (1257828)
        The thing that really bugs me is when one has worked very hard to write the sort of code that doesn't need comments, but company policy or contractual agreements force their existence anyhow. For this reason, I think collapsable comments are wonderful. I expand them only when I hit someone's (possibly my own) WTF type code, and more often than not, I'm happy to say on my current project, I find a friendly plain-english explanation and apology for the confusion and misery. I likewise don't follow the argu
      • by EmperorOfCanada (1332175) on Friday September 07, 2012 @10:43AM (#41260757)
        Agreed. I find commenting is a good diagnoses for either OCD or micromanagement by a quasi non programmer. It drives me bonkers to see a function like this:

        //*********
        //GetNumberOfUsers is a function that will return an integer
        //describing the number of users that match the parameters entered
        //category_id is an integer containing the category of user
        //country_id is an integer containing the country code
        //company_id is an integer containing the company identifier.
        //Created:BOB_MILLER:2008-08-09:14:24:34
        //Edited:BOB_MILLER:2008-08-09:14:24:39
        //Edited:BOB_MILLER:2008-08-29:10:24:39
        //Edited:BOB_MILLER:2008-09-09:16:24:39
        int GetNumberOfUsers(int category_id, int country_id, int company_id)
        {
        //this will hold the number of users
        int num_users=0;
        //Get a connection to the database
        DBConnection db=new DatabaseConnection('central_database');
        //check to see if connection is good
        if(db==null){explode();}
        //good didn't explode so do next statement
        ...
        //Close database connection
        db->Close();
        //Now return the number of users
        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; //This compiler acting is screwy so I didn't use the more efficient x++ here
        x=sqrt(sin(log(y)/pi)*e);// this is the lambert/highlander formula
        x=lookup_table[y]; //This look-up table speeds things up by 100x.
        x=sin(tan(cos(x)));// If I knew my trig better there must be a better way to condense and speed this up.
        • 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

    • by garcia (6573) on Friday September 07, 2012 @08:40AM (#41259361) Homepage

      The real problem with comments isn't their color, it's when they AREN'T THERE AT ALL.

      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:

      /* 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. */

      I can only shake my head at myself ;-)

      • 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.

        // TODO: fix this

        Not all comments give you a mile high view. Some are just pointless wastes of disk space...

      • Many times I have run across a commented section of code that reads something like:

        /* 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. */

        I can only shake my head at myself ;-)

        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."

      • by crazyjj (2598719) * on Friday September 07, 2012 @08:57AM (#41259537)

        /* 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?

    • 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

      • by crazyjj (2598719) *

        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.

      • by Tx (96709) on Friday September 07, 2012 @09:08AM (#41259679) Journal

        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.

        • by locofungus (179280) on Friday September 07, 2012 @09:59AM (#41260201)

          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.

    • by Sulphur (1548251)

      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.

    • Or there's the sloppy git who comes to update your code but doesn't change the comments to reflect his changes so you end with code doing one thing and comments describing something different!

      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

    • 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".

    • As far as I'm aware (and I'm sure I'll be corrected if I'm wrong) but your average code file is simply plain text, the colour formatting is applied by the program you're using to view/edit it. So it doesn't matter how you decide to colour it, when I load it into gedit the comments are blue. Or is this a discussion of the formatting preference button for text editors?
    • Bitrot (Score:3, Insightful)

      by flyingfsck (986395)
      Comments suffer from incurable bitrot. So when I need to understand code, I never bother reading the comments, since it is usually more confusing than the code.
      • by Jeremi (14640)

        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

        • by nschubach (922175)

          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

    • by jandersen (462034)

      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

  • by Bogtha (906264) on Friday September 07, 2012 @08:34AM (#41259285)

    If your aim is to make something more visible, don't pick a yellow-on-white colour scheme.

  • by eldavojohn (898314) * <eldavojohn AT gmail DOT com> on Friday September 07, 2012 @08:35AM (#41259297) Journal
    There's not much material to those links -- at least nothing even close to addressing the full problem. The "adjusted" code in the first link is trivial. Furthermore, that is how we comment code where I work. I'm surprised there isn't an annotation driven doc-generating friendly comment block at the top of that signature in their example (along with the inline comments)!

    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.

    • 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.

      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)

    by Anonymous Coward on Friday September 07, 2012 @08:35AM (#41259301)

    Use vi. Always works for me.

  • by Anonymous Coward on Friday September 07, 2012 @08:36AM (#41259309)

    ...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.

  • by laffer1 (701823) <luke AT foolishgames DOT com> on Friday September 07, 2012 @08:36AM (#41259313) Homepage Journal

    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.

    • 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.

      • 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

  • >> 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.

  • by darkwing_bmf (178021) on Friday September 07, 2012 @08:38AM (#41259337)

    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)

    by bill_mcgonigle (4333) * on Friday September 07, 2012 @08:38AM (#41259341) Homepage Journal

    Comment first, fill in the code later.

    • Re:Save time (Score:5, Insightful)

      by ShanghaiBill (739463) on Friday September 07, 2012 @08:59AM (#41259567)

      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:

      // process command line arguments
      // read input files
      // process the data
      // output the results


      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.

    • by medcalf (68293)
      Yes, exactly. When I write code anything more than a bog-standard getter/setter method, the first thing I do is write a comment describing everything coming in and everything going out, and how "in" and "out" differ. Then I write a series of comments going through the entire set of steps that have to happen (at 50000' level) to get the in, do the transformation to produce the out, and actually send off the out. For those parts where the 50000' view isn't obvious ("read in the file from the passed filehandle
  • 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.

    • by h4rr4r (612664)

      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.

      • by jsmyth (517568)

        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

        "Huh? Why is he filling a hash only to return a single value?"

        can say:

        "Oh, that's what he was trying to do. What a kludge. I'll fix it."

        ...and write it properly.

    • i++

      Those sweeping generalizations will get you every time.

      • Really, that's the example you chose? That is not at all clear. That might increment i (so that the new value of i is one greater than the old value) -- but that might also cause an integer overflow. If this is C++, you might have a type that overloads the ++ operator: maybe that is a type for saturation arithmetic, so i++ might not even change the value of i.

        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
  • by Dark$ide (732508) on Friday September 07, 2012 @08:39AM (#41259351) Journal
    Isn't whether they are displayed, isn't wether they exist or not it's whether they add any value, whether they describe why the code has been written in such an obscure way.

    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.

  • I think all code needs comments, unless it's something incredibly basic. However, keep the comments short and to the point. Don't write a paragraph when all you need is a sentence. Also, don't use slang unless it's extremely well known.
  • by trout007 (975317) on Friday September 07, 2012 @08:45AM (#41259409)

    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.

  • by ShanghaiBill (739463) on Friday September 07, 2012 @08:47AM (#41259435)

    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.

    • by Compaqt (1758360)

      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)

    • by Dixie_Flatline (5077) <vincent...jan...goh@@@gmail...com> on Friday September 07, 2012 @09:16AM (#41259803) Homepage

      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.

    • by MrSenile (759314) on Friday September 07, 2012 @09:35AM (#41260019)
      Ok.

      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.
  • by betterunixthanunix (980855) on Friday September 07, 2012 @08:53AM (#41259485)
    "This does not work"

    "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.
  • by Sez Zero (586611) on Friday September 07, 2012 @08:56AM (#41259519) Journal
    I'm just here for the Comments on Comments on Code Comments.
  • by Tim Ward (514198) on Friday September 07, 2012 @08:56AM (#41259527) Homepage

    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.

  • 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.

  • by ccguy (1116865) on Friday September 07, 2012 @08:57AM (#41259541) Homepage
    In my experience, comments are usually as clever as the writer, and as good as his code. When it's my code and my comments by the way the quality of the comments seems to diminishes as the code ages, even with the file timestamp not changing.

    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:

    // Validación de cuenta bancaria
    #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).
  • Djikstra said, "Always debug the code, not the comments". No one updates the comments. Including me. The number of hours I have wasted in debugging code because I trusted the comment written in the function or the algorithm is countless.

    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.

  • 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.

  • Some people like to ensure that operations would be hindered should they be fired.
  • Programming languages are as much about communication with other programmers as they are about communication with the machine. At some point someone else is going to have to do something with your code, no matter how well written it is. Over the course of my career I've run across countless pieces of code where I've wondered "What the hell was this guy thinking?!" A well placed comment might tell me, if they'd bothered to put one in. Sometimes that construct actually has to be awkward due to the previous design of the code, and changing it will cause breakage or a side effect somewhere else. Most of the time they just weren't putting a lot of thought into the design of that section of code (Or more often, their entire application.) In a handful of cases they had just discovered some feature and had become enamored of it (Like pointers to functions, or ? : branching.)

    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.

  • I guess that when I code, I just make sure that my comments are necessary.

    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.

  • I have never worked on a program where I did not find comments that were flat out wrong, causing me to (1) waste time discovering the comments were wrong, and then (2) trying to figure out what the program was really doing. As a result, I have become a fan of minimalist comments and better quality coding.
  • 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

  • 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)

    by Sloppy (14984) on Friday September 07, 2012 @09:20AM (#41259847) Homepage Journal

    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.

  • by famebait (450028) on Friday September 07, 2012 @09:22AM (#41259871)

    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.

    • by rastos1 (601318) on Saturday September 08, 2012 @01:30PM (#41274897) Homepage

      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..."

      You mean something like this:

      //
      // Dear maintainer:
      //
      // Once you are done trying to 'optimize' this routine,
      // and have realized what a terrible mistake that was,
      // please increment the following counter as a warning
      // to the next guy:
      //
      // total_hours_wasted_here = 42
      //

      ?

  • My views (Score:4, Interesting)

    by Mr. McGibby (41471) on Friday September 07, 2012 @10:14AM (#41260399) Homepage Journal

    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

3500 Calories = 1 Food Pound

Working...