Anyway I found this post (and discussion) insightful, the key points I take away are:

- Expressive semantic code is preferable complex code with descriptive comments
- Not all comments are evil! (RegEX/DocBlock/Modified-by-someone-on-date)
- Comments could be used as ‘refactoring indicators’..

E.g. you could have a plug-in for your editor/IDE that scans your code and highlights all non-regex/Docblock comments and flags them as ‘refactoring candidates’. It might generate a ToDo list of line-numbers which you could then review and refactor as necessary.

Maybe that would be useful? I don’t know.. interesting post though, keep it up.

That’s just starting from the top. Then there are opportunities for refactoring the code that, as you point out, I’ve moved into the new methods. The first thing I would do is to reverse the sense of the if statement, changing

if (!empty($depTables)) {…

into

return if(empty($depTables));

That eliminates a level of nesting.

what did you exactly do in your example? If I understand correctly, you have only created two new methods and moved “uncleaned” code into these methods.

It reminds me of “fantastic” Wordpress’ index.php:

define(‘WP_USE_THEMES’, true);
require(‘./wp-blog-header.php’);

Nice!! All garbage is gone …

No, comments are there to comment. Period.
That has nothing to do with how good is your code.
You can write perfectcly clean code and add good comments to it. Nothing wrong with that.

You can’t generalize on these things.

In certain cases a rough quick routine that maybe doesn’t follow the golden sacred rules of good programming can be faster and more efficient than one that is maybe easier to read and perfect by any standard of programming.
Sometimes you need efficiency over pretty code. And good commented efficient ugly code is good in that case.
Sometimes you have a gigantic project and you need clean code if you want to maintain it. Still, also in that case good comments are good to have.

The presentation had some believable examples describing apparently innocent changes way down in the code witch in turn made comments higher up very wrong.

The only thing worse than (bad?) code without comments is code with comments that’s wrong!

In this case though, there seems to be no debate in progress in the first place. I am trying to make my point strongly enough that people will at least notice it.

If the rest of the blog post had been over the top, then I would probably have been shooting myself in the foot.
I don’t think it is, though.

On the other hand, the amount of interest that’s being focused on the title rather than the actual content of the blog post could indicate that it wasn’t a wise choice.

I think I’m going to start using variables that are more readable like you suggest. Often times I name my variables using the context of where they are. So an array of news posts would be $posts instead of $news_posts. Going over 15 characters is overkill though and I’ll aim to not do that.

For those disagreeing with the concept outlined by the author, try to see it for what it is and apply as much as you can. Be open to new ideas!

In my case, I would never completely remove comments from my code but I will focus on making the code readable enough so that comments aren’t always necessary. Even if it makes 10% of my code more readable since I’m thinking about the concept while writing the code — awesome!

For the people who want to improve their knowledge and who do not understand why commenting is a sign of weakness, I can recommand the following articles:

- http://www.objectmentor.com/resources/publishedArticles.html
(especially under “design principles”, “Object Oriented Design”, “Refactoring”, etc.)

- Misko Hevery’s blog (A google evangelist) http://misko.hevery.com/

Comment is usefull when:
- it is used by programm to autogenerate documentation
- it is used by your IDE
- You write ugly code for external constraint (performance reason, etc.)
- …?