13 Jul 2010

Please stop commenting your code

Code is the easy part to understand. Instead, spend your time giving me the broad clues as to how the code base hangs together: the concepts, the intentions, the analogies, your thinking, how you see it being used.  And then tell me the gotchas.  

How about only writing code comments when there's something newsworthy to say?  Or giving me an example, or pointing me at a test if tests are rare?  What if we accept that our project and team has conventions, and we kind of get them, so you don't need to cover them off in comments? There would be fewer comments, and those that survive would be more likely to be useful.  

The alternative is a nice formatted file with standard or bland comments that will just fade out as background noise---noise which is often (a) pointless and (b) out of date.  And possibly the worst of all this, comments that are just taking up space on my screen, and masking actual useful information that might possibly be buried under some "returns a list of users from the database"-style worthless comment. 

I'm not saying no to comment.  What do you think of this: 
For instance, would you rather use a one-liner that requires a 3-line comment, or a 10-liner that requires no comments? In most cases, code's readability suffers more when it's overly verbose than when it has a high comment to code ratio. Thus, I would choose to write the comment in most cases.

Only a year ago I had the opposite opinion, but now I'm in total agreement. Plus, if you find a funky or idiomatic one-liner the comment would pass that technique on to the team. But please only do that once: don't copy and paste the comment with the code.

Yes, I've joined the anti-comment bandwaggon.  

Yes, I know it's a bit more complicated than that.  

17 Aug 2007

A Comment on Static Typing

There's a line of thought put forward by Neal Ford to help Java developers get over any hang-ups they may have with dynamic typing. If you like compile-type checking of your types, maybe you're worried "that utter chaos would reign if we discard typing". Neil's argument is that: (a) unit testing is good; (b) 100% code coverage is good; therefore static typing buys you nothing:

"If you have pervasive testing, static typing == more typing. The static typing is nothing but a requirement to type extraneous code to satisfy a compiler that isn't telling you anything interesting anymore."

It's a compelling argument ("[a]fter all, it's the tests that tell you if your code [is] correct or not"), but I think it hides more that it reveals. My main concern is that the argument assumes there's the same amount of testing in both the dynamic and static cases. That doesn't seem to be true: if the compiler is catching cases that you need to test for in a dynamic language, then that's more unit tests that need to be written.

Let me phrase this another way:


If you have static typing, dynamic typing == more testing. The dynamic typing is a requirement to type extraneous code to satisfy a code coverage tool that would otherwise have been caught by the compiler.

That's not to knock dynamic languages (I know first-hand how damn productive Perl is): I'll use dynamic languages some times, and static languages other times and admire them for what each can do for me in different situations. And it's not to support the idea that 100% code coverage is an achievable goal in practice. It's just that Neal Ford's in principle argument doesn't work for me.

Richard Dallaway's Posterous

Director at Spiral Arm Ltd. We build stuff using Scala+Lift, offer consulting & create new projects. I live in Brighton, UK.