Why aren't you commenting your code?

Comments - like documentation - are a liability. Most projects tend to treat them as supporting artifacts, but they are actually unidentified risks. Did you account for the time spent either rewriting documentation/doxygen/comments as you go (frequent chunks of small work) or an after the fact round of document backfilling (single chunk of large work) in your schedule?<p>No one even reads those documents. The client claims they are to assist future developers - internally or another vendor - but would you trust a Word document or a .cpp file when everything is on fire and you need to figure out a system's behavior? Same thing applies for code comments.<p>There is one source of truth in software, the code. You can pile on the design documents, wikis, and architecture diagrams but at the end of the day, what is coded is what gets executed. Make the code easy to understand and reason about. And then, if you really want to be nice to future developers, throw in a single page overview of the codebase (README) that gives someone an entry point.<p>Edit: I will just add the caveat to preempt the inevitable - this does not apply to public facing documentation of an API/framework/library etc.

The thing about comments is that they don't get maintained. So the comments end up diverging from the implementation. The tests all pass even if the comments are wrong, so nobody cares unless you are particularly diligent about code reviews of EVERY commit.<p>Also this should go without saying but I still see comments like this:<p><pre><code> // loop over the collection for (var foo in bar) { ... } </code></pre> which are not helpful and just clutter the code.

Yeah, but what about<p><pre><code> // $set $foo to $bar $foo == $bar; // print out value of $foo echo $foo; // is $bar the same as $foo? if so, return true, otherwise return false if ( $bar === $foo ) { // check if the same return true; // great, it's true! } else { // here we check if it isn't true return false; // nope, not true, let's return false } </code></pre> I have nothing against comments where something needs to be documented, but not everything needs comments as most code is essentially self-documenting.<p>Edited for clarity.

As mentioned in Clean Code, beautifully and concisely code doesn't need much of commenting. It's pretty much self-explained.

99% of the time when you are writing a single line comment you should instead be either renaming a variable or using the extract method refactoring using some abbreviated form of the comment in the new name.<p>For the remaining cases it's more important to make sure that you're documenting the "why" of something in the code. If you find yourself often in the situation where making changes to the code requires modifying the comments to keep them up to date that's a big sign that you aren't writing comments appropriately.

<p><pre><code> // It was hard coding it // so it should be hard reading it</code></pre>

I find comments useful in two main cases:<p>1) When I'm not all that familiar with the language. This allows me to grok the purpose and actions of code quicker.<p>2) When the action being performed contains more lines than fit in the screen. Knowing a bit more context going in can make what follows more clear.<p>For 1, it's a matter of who you intend to read/modify the code after you. For 2, that's probably more a case for splitting that code into multiple functions.<p>From that, I think comments are best used by poor and great programmers, but the middle of the road may not get much benefit out of them. If you don't know how to split your complex bits of code into multiple chunks, or if you expect most people coming after you to now be as experienced as you, comment.

I started writing code in a more literate style recently (where the code is a document with markdown interspersed with the code segments) and found that writing what I want to do first makes the development process much easier than just delving into code. Feels like writing a paper in many ways (you write the outline, flesh with your thoughts on how it should work, and then start writing code)<p>I put this tool together on a whim (although the github rendering is somewhat strange because I took liberties with the fenced code blocks): <a href="https://github.com/niggler/voc" rel="nofollow">https://github.com/niggler/voc</a>

I feel like I'm seeing a lot of discussion about what should be commented. Just like with tests, this can be hard to put your finger on. Even more so, the level of detail a comment needs to have for it to be useful/useless will vary for each developer reading/working on the code. In my opinion it's better to be overly helpful than it is to leave it all difficult to understand.<p>Also, it's obvious that outdated comments are terrible. It is my expectation that if comments are going to be in the code at all, they should be maintained just like the rest of the code.

Commenting methods can often be redundant. But I find it is almost always a good idea to comment classes that contains any degree of complexity. Too often when digging into a new project I see a class like "ItemHelper", and have to read a few dozens of lines to realize something that could be summarized like: "Converts X-data to a format that Item can parse".<p>It makes it so much easier to get introduced to a code base, and comments like that seldomly needs to be updated.

You shoudl read Robert C Martin's, "A clean coder". <a href="http://www.amazon.co.uk/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073" rel="nofollow">http://www.amazon.co.uk/Clean-Coder-Conduct-Professional-Pro...</a>

Sometimes documentation is just a way to (try to) make up for poor code.<p>I usually pretend I can't document my code while developing. I'll sure add some anyway.<p>This doesn't apply to public APIs. There, you of course need to be more explicit.

Anyone have an example of well commented source code?