He suggests that inline comments are unnecessary when method/function/procedure names are specific and they have one specific purpose.
Ford may be onto something here but he obsesses over the latest and supposedly greatest software methdologies. Some of the obsessions are dynamic languages, "agile" methodology, and "test/behaviour-driven" development. What I found worse was the re-labeling and mis-crediting of an old software development idea. Ford credits Kent Beck and calls it the "compose method" pattern but everyone else (at least those who know their history) will recognize it as a central idea in structured programming. This apparent pattern, really an old idea given a new name, describes the writing of smaller functions/methods with a clear, specific purpose. The beauty of structured programming is that it gives us a way to convert blocks of code into smaller functions.
The whole article is about the code, rather than the complete program (documentation and all). We can see this mistake repeated over and over. Ford tries to support his argument by saying that comments are redundant in those cases where code is "self-documenting" (I think this means the method/function names are very descriptive), and he calls comments a "violation of the DRY (Don't Repeat Yourself) principle."
Besides misundestanding the intention of Literate Programming, Ford continues with this non-sense about violating principles by somehow setting up "self-documenting" code as ideal,
As [programming] languages have matured, you can get much closer to the ideal of self-documenting code (which was explicitly attempted in Literate Programming).
Self-documenting code assumes that we want to write everything inside of the programming language. This is not always the case and it hurts us because we now have an interest in keeping that language "alive". Documentation that code is based on can be made language-neutral or have language-specific details added to it and explains why the code should be written in a particular way, but when we are only examining code, its intent may become lost through the noise of language or implementation-specific quirks. As an example, you can look at programmers who try to translate C/Java/etc. code to some functional programming language where the iteration statements appear in a different manner, in a different abstraction.
Ford likes dynamically typed languages because one of their side effect is that
The method name is the only vector of information about what the method does (you can't crutch on return or parameter types), so methods tend to be named much better...
My only comment is that a lack of discipline is a flimsy justification for something.
In the company of assumptions and statements made without evidence, the oft-heard complaint about documentation and comments being out-dated is made,
JavaDoc style comments ... are generated from code and have a fighting chance of staying in sync with the actual code. However, tests make much better documentation than comments. Comments always lie (maybe not now, but on a long enough timeline, all comments will become outdated).
This is an easy problem to fix: write the code based on the comments and documentation! If we give into the temptation of instantly changing code without documenting our better understanding of the problem we are solving with that code, then the documentation becomes outdated. The stereotype of programmers despising documentation is only enforced by Ford's statements. Again, a lack of discipline is hardly a good justification for abandoning a useful tool.
Throughout the article, there is an unwillingness to examine assumptions,
The new wave of Behavior Driven Development tools (like JBehave, RSpec, and easyb make this "executable specification" style of comment + test feasible. I expect to see the usage of these tools skyrocket because they give you documentation that has a fighting chance of staying up to date.
The assumption is that an "executable specification" is desireable. No reasons for why we would want this are given, it is just assumed that we have such a great addiction to automation that we will want our specification to be run on a computer. The limits of some programming languages and their syntax makes them undesireable to use for specifications.
The final assumptions,
Inline comments are almost always a smell. The only legitimate use of inline comments is when you have some very complex algorithm that you need to have some thoughts about beside code. Otherwise, the presence of inline comments indicates that you've written code that needs explantion, meaning that it cries out for refactoring.
Aren't most programs complex algorithms? The worst assumption is that, somehow, explanation of code is bad and should be pushed into descriptive method names.
The article prompted me to pick up the book The Pragmatic Programmer which isn't a very good book but I will get into that later...
