Coding Without Comments

July 24, 2008

If peppering your code with lots of comments is good, then having zillions of comments in your code must be great, right? Not quite. Excess is one way good comments go bad:

'*************************************************
' Name: CopyString
'
' Purpose: This routine copies a string from the source
' string (source) to the target string (target).
'
' Algorithm: It gets the length of "source" and then copies each
' character, one at a time, into "target". It uses
' the loop index as an array index into both "source"
' and "target" and increments the loop/array index
' after each character is copied.
'
' Inputs: input The string to be copied
'
' Outputs: output The string to receive the copy of "input"
'
' Interface Assumptions: None
'
' Modification History: None
'
' Author: Dwight K. Coder
' Date Created: 10/1/04
' Phone: (555) 222-2255
' SSN: 111-22-3333
' Eye Color: Green
' Maiden Name: None
' Blood Type: AB-
' Mother's Maiden Name: None
' Favorite Car: Pontiac Aztek
' Personalized License Plate: "Tek-ie"
'*************************************************

I'm constantly running across comments from developers who don't seem to understand that the code already tells us how it works; we need the comments to tell us why it works. Code comments are so widely misunderstood and abused that you might find yourself wondering if they're worth using at all. Be careful what you wish for. Here's some code with no comments whatsoever:

r = n / 2;
while ( abs( r - (n/r) ) > t ) {
  r = 0.5 * ( r + (n/r) );
}
System.out.println( "r = " + r );

Any idea what that bit of code does? It's perfectly readable, but what the heck does it do?

Let's add a comment.

// square root of n with Newton-Raphson approximation
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
  r = 0.5 * ( r + (n/r) );
}
System.out.println( "r = " + r );

That must be what I was getting at, right? Some sort of pleasant, middle-of-the-road compromise between the two polar extremes of no comments whatsoever and carefully formatted epic poems every second line of code?

Not exactly. Rather than add a comment, I'd refactor to this:

private double SquareRootApproximation(n) {
  r = n / 2;
  while ( abs( r - (n/r) ) > t ) {
    r = 0.5 * ( r + (n/r) );
  }
  return r;
}
System.out.println( "r = " + SquareRootApproximation(r) );

I haven't added a single comment, and yet this mysterious bit of code is now perfectly understandable.

While comments are neither inherently good or bad, they are frequently used as a crutch. You should always write your code as if comments didn't exist. This forces you to write your code in the simplest, plainest, most self-documenting way you can humanly come up with.

When you've rewritten, refactored, and rearchitected your code a dozen times to make it easy for your fellow developers to read and understand -- when you can't possibly imagine any conceivable way your code could be changed to become more straightforward and obvious -- then, and only then, should you feel compelled to add a comment explaining what your code does.

As Steve points out, this is one key difference between junior and senior developers:

In the old days, seeing too much code at once quite frankly exceeded my complexity threshold, and when I had to work with it I'd typically try to rewrite it or at least comment it heavily. Today, however, I just slog through it without complaining (much). When I have a specific goal in mind and a complicated piece of code to write, I spend my time making it happen rather than telling myself stories about it [in comments].

Junior developers rely on comments to tell the story when they should be relying on the code to tell the story. Comments are narrative asides; important in their own way, but in no way meant to replace plot, characterization, and setting.

Perhaps that's the dirty little secret of code comments: to write good comments you have to be a good writer. Comments aren't code meant for the compiler, they're words meant to communicate ideas to other human beings. While I do (mostly) love my fellow programmers, I can't say that effective communication with other human beings is exactly our strong suit. I've seen three-paragraph emails from developers on my teams that practically melted my brain. These are the people we're trusting to write clear, understandable comments in our code? I think maybe some of us might be better off sticking to our strengths -- that is, writing for the compiler, in as clear a way as we possibly can, and reaching for the comments only as a method of last resort.

Writing good, meaningful comments is hard. It's as much an art as writing the code itself; maybe even more so. As Sammy Larbi said in Common Excuses Used To Comment Code, if your feel your code is too complex to understand without comments, your code is probably just bad. Rewrite it until it doesn't need comments any more. If, at the end of that effort, you still feel comments are necessary, then by all means, add comments. Carefully.

Posted by Jeff Atwood
267 Comments

Jeff:

Comments are for the next guy who has to modify the code at 3 am when production is down and the original programmer has moved on. As a maintenance programmer for several decades, I can tell you that novel like comments do not help. But single letter variables that you used in your example do not help either. You are making the assumption that the next guy in line will know what you know the instant you are writing that line of code. (That next guy could be you 6 months later and at 3am all math is fuzzy logic.) There are coders and there are programmers. Programmers don't ASS-U-ME!!!

private double SquareRootApproximation(square) {
rootApproximation = square / 2;
while ( abs( rootApproximation - (square / rootApproximation) ) tolerance ) {
rootApproximation = 0.5 * ( rootApproximation + (square / rootApproximation) );
}
return rootApproximation;
}
System.out.println( r = + SquareRootApproximation(r) );

Will on July 25, 2008 6:28 AM

Jeff, I have lost the last little bit of respect I had for you with this post. :P

Seriously, though, I do find short what are we trying to accomplish here header comments helpful. Note that your refactored example no longer conveys the fact that it's doing a Newton-Raphson approximation. Maybe that's not a big deal there, but there are other situations where a fact like that would be good to know.

I like the goal of code blocks to be commented, so what in the sense of what are we trying to accomplish instead of what are we doing (which you correctly say should usually be understandable from the code itself).

Bob on July 25, 2008 6:31 AM

Reminds me of one of our junior developers here. Her manager told her to comment a lot, so she does things like:

//Get the http session.
HttpSession session = request.getSession();

Which is utterly useless and just clutters the source files.

a on July 25, 2008 6:34 AM

@Will:

You just beat me to it.

Good method naming is great for people calling your code. For people actually maintaining your code, all naming is important. Method, variable, class, etc names should all be descriptive.

If there isn't a clear name for an entity, there's a very good chance that it shouldn't exist in the first place.

One good example is loop counters. How many times have you seen for(int i = 0; i some_number; i++), when there is actually a meaning to the loop counter, such as an array index, or something_count?

By all means, keep code terse, but not to the point of obfuscation. FFS, a couple bytes of extra code for clarity is great value.

Chris on July 25, 2008 6:41 AM

try writing some readable assembler code without comments... good luck with that. :)

good post. i am often guilty of explaining in too much detail how something works in comments, whilst leaving other things uncommented altogether when they really need a good comment...

jheriko on July 25, 2008 6:46 AM

I still put some comments in my code, but I do make my code descriptive. The comments are typically for me, as more of a reminder of what I was wanting to do when I start to stud out a new class or method. I'm starting to do that with the TODO comments, but learning how to code w/out having that option available, I just got in the habit of one line comments as a quick reminder to myself of what else I needed to to do.

mjmcinto on July 25, 2008 6:52 AM

I agree with Will. I have personally been in the situation where I was asked to add a feature to a program that I had written three years earlier. I *thought* I had a good idea in my head as to how the original source code ran, and foolishly answered that it would be easy. I had a pretty good idea how to do it. But then when I looked at the actual code (with no comments, and with variables named 'x' and 'y' etc.) it took much longer than I had predicted just to find the right place to modify the code. FWIW, once I figured out *where* to modify the code, the actual modification was as easy as I thought. If only I hadn't used up more than my allotted time for making the modification just figuring out my own code. BTW, this wasn't even at 3 AM.

Pete S on July 25, 2008 6:53 AM

I have worked on teams where EVERY new line you write needs to have a comment (and the version control nazi/supervisor would nag you to death if you didn't). That certainly doesn't help anyone. If I write a function called ClientAuthNumber(client_id) I don't think I should need to add // returns client authorization number based on client id or a = b + c; // a equals the sum of b c ...but I guess there are those who disagree.

On the other hand (and just as important), my team is now working on a huge application written by another company which we have to manage and there is hardly a line of code on anything. It seems for about a 2 year period from 2005-2007, they usually added just who updated it and when...not why it was added or if it affects anything else.

IMO, there is nothing harder to read than code that has 2 lines of comments before every line of code. If it is that hard to understand without EXCESS commenting, maybe it wasn't well-written to begin with...

bob on July 25, 2008 6:59 AM

Wow, Jeff is really on a roll here. Code and comments are bad!

I guess I never realized that Coding Horror was actually about coding badly. Comments are not bad, *BAD* comments are bad. Just like code isn't bad, but bad code is bad.

I'm honestly having a hard time believing someone as supposedly intelligent as Jeff actually believes this crap. It looks to me as though Jeff has discovered if you post controversial stuff you'll get more ad hits. Whatever, thats his prerogative but I'm not reading it anymore.

Matt Newman on July 25, 2008 7:08 AM

Comments are my friend. Sure I could write a big block of code and walk through it to see what is done, but isn't it quicker to just read a sentence or two before it so that I know what it does?

In addition, if you code something wrong (not that I would do that, but maybe some other developer would), wouldn't it be nice to have a comment that says what the code SHOULD do?

My favorite comment is when someone does this...
x = 2 // set variable x to 2.

Not that I'd ever use that, but it makes me laugh when I see it. And then die a little inside.

Kris on July 25, 2008 7:09 AM

I totally agree with the article.

Luigi R. Viggiano on July 25, 2008 7:16 AM

Alex: I think you're correct for the first time through the loop, but after that it changes and converges on the result.

mike on July 25, 2008 7:32 AM

One of the most important things I use comments for is to explain what is not available from looking at the code. For example a requirement of a called procedure:

if (x 0) then AbortProgram(X is negative);
y := PerformSomeMagic(x);

May deserve the comment:

//PerformSomeMagic will give incorrect results if passed a negative parameter.

Al on July 25, 2008 7:38 AM

I think Jeff has made his point by using an over-the-top comment example. I also comment methods before writing them. But I'm a bit more succinct about it (VERA code in a HW verification test bench):

// After (possibly a series of) call(s) to
// set_field, this task is called to write
// the shadow_value to the physical DUT CSR.
virtual task commit_fields_t(integer access_method = CSR_DEFAULT_ACCESS);

In my last post, http://mjbiren.blogspot.com/2008/07/check-in-your-changes.html, I note that one of the things you need to do when checking in changes is to make sure the comments are still relevant. This becomes easier if the comment's content is short and only about code intent. Code details always change, if you comment like you're writing code - then changes always become twice as much work.

So in the end, I think I half agree with Jeff.


mike on July 25, 2008 7:42 AM

No use of regions in you code, no comments, what's next? Shall we say no to line breaks. Visual Basic you need them, but C#? It's just a waste of space not to be using every pixel of your screen for conveying information. Why should I have to use my mouse wheel to scroll up and down someone else's code when they could have fitted it into one small area. This would allow me to have many classes open on my screen without having to alt-tab between them. So efficient is this way of code that before reading any code I run a script to remove all white space from it and check it back in. Another advantage to this style of coding; I can use a USB photo frame for displaying some of favorite classes of code. Code Analysis can now include looking for secret Da Vinci Code messages. The fate of the world is in your hands if only you would advocate proper coding standards. Come on Scott the world needs just one more controversial coding practice to save it.

Dave on July 25, 2008 7:45 AM

In a perfect world our comments would write the code.

Practicality on July 25, 2008 7:45 AM

And then your subroutine fails because t is undefined.

dnm on July 25, 2008 7:55 AM

I dunno, I would still appreciate a one-liner about which approximation algorithm was being used. Numerical methods isn't my strong point.

(@Will: The use of short variable names in the refactored function is fine; it's a math algorithm and you need to be familiar with the algorithm to get it anyway; the long variable names doesn't help there.)

Adam Vandenberg on July 25, 2008 8:02 AM

In our organization (or the part I'm in, anyway), good practices like commenting code have not been paramount. I'm working to change that, including a requirement in the group I lead that we comment our code. It doesn't (and shouldn't) be book length, but some helpful hints here and there, telling the next guy what was intended, is very helpful.

Scott Marlowe on July 25, 2008 8:02 AM

Comments are an invaluable tool designed to communicate what is otherwise incomprehensible. If I come behind you, I'll be cranky because I have no idea what the Newton-Raphson approximation, and you didn't bother to make a comment on the subject.

Sometimes we have to write highly complex code, and comments are a way to help understand those tough blocks, but the real power of comments and where they shine is communicating business concepts. After all, it's our job to help the business move forward, so that is where we have to focus our understanding.

Just my two cents.

Corey Furman on July 25, 2008 8:05 AM

I had a college professor who loved to kill us with documentation - his favorite example was How zero's do you see? 000000000 and then he showed us 000|000|000

The professor said: See - I added more stuff and it's more readable!

Years later - I realized you could use whitespace and change it this to get the same result: 000 000 000

Sometimes less is more.


john on July 25, 2008 8:11 AM

Yep, must agree with the majority of posters here and disagree with Jeff. I start with comments as I set the architecture in place and then flesh it out with code. Yes, the comments typically stay in some form. And if you wanted your function (which I wouldn't make something a function just to avoid a comment block), then it would require more work (which I would argue it needed anyway)...

// Newton-Raphson approximation
private double SquareRootApproximation(iRoot) {
fRootApproximation = iRoot / 2;
while (abs(fRootApproximation - (iRoot / fRootApproximation )) iTolerance) {
fRootApproximation = 0.5 * (fRootApproximation + (iRoot/ fRootApproximation));
}
return fRootApproximation;
}

System.out.println( Root Approximation = + SquareRootApproximation(iRoot) );

Phil on July 25, 2008 8:13 AM

I would have to agree that self-commenting variable names and function names area always more valuable.

As far as the other comments, my commenting style is constantly changing. Sometimes more, sometimes less. I nearly always think what I am currently doing is the best. I am sorry to say, but I think there are pluses and minuses to both. Assets and liabilities.

It's actually just a preference. Seriously (as long as your code is actually easy to read).

Practicality on July 25, 2008 8:22 AM

In Russia, comments write *you*.

B0R1S on July 25, 2008 8:26 AM

Most of my work is cleaning up and maintaining existing code. Usually the original developer was a newbie, the code is hard to read and comments would make my life a lot easier. However, if the code was written by someone who knew what they were doing it's usually obvious what is going on and comments are already in places where it makes sense to have a comment. I think the longer a developer codes, the more he/she learns to write self-documenting code and when/where to add a comment.

PaulG. on July 25, 2008 8:30 AM

Junior developers rely on comments to tell the story when they should be relying on the code to tell the story.

I disagree. Comments are the context which code itself might not provide. Normal human reasoning does not always align with code architecture; this is why we consider a meaningful understanding of design patterns to be one sign of maturity (i.e., they take effort to internalize). Just as a graphical interface needs both a usable design and helpful documentation, so does code. This is because none of us are savant designers, capable of providing fully-comprehensible designs (to all audiences, locales, and experience levels!).

That's my big picture response.

On the pragmatic side, engineers in any rapidly-changing field will need to frequently migrate between languages, platforms, and goals. While we should all have a firm grasp of programming fundamentals, the reality is that we often need to modify code we're not seasoned veterans of.

If you have the luxury (or curse?) to work in one language for your entire career, then comments may seem superfluous. But throw in either a complex architectural solution (e.g., for performance or enterprise integration purposes), or new languages and libraries, and all-of-a-sudden a few comments here and there significantly improve task completion times.

Everyone benefits from comments -- junior and senior engineers alike.

Vance Vagell on July 25, 2008 8:37 AM

You should always write your code as if comments didn't exist.

I agree to the fullest, although I find it hilarious that you can say this in the midst of using single-letter variable names.

Josh Stodola on July 25, 2008 8:40 AM

// Constant Comment is a pretty good tea.

Charles on July 25, 2008 8:44 AM

Just... whatever you do... don't add regions!!!

/had to

Ivan on July 25, 2008 8:44 AM

The best comments are like:

// Increment i
i++;

George on July 25, 2008 8:50 AM

While comments are neither inherently good or bad, they are frequently used as a crutch. You should always write your code as if comments didn't exist. This forces you to write your code in the simplest, plainest, most self-documenting way you can humanly come up with.

Disagree. Comments exist for a reason, we should make use of them, not write code that doesn't need comments. Its not like comments are included in the compiled code. Shit most editors, make comments a different colour, you can easily ignore them. You know your blogs bug me. You moan about everything, php, xml are ones that stick out in my memory. Maybe you are an old school programmer who doesn't like the new breed. But i'm afraid we are in a field where what's new is old before it hits the mainstream. You need to adapt man!

Back to your comments hissyfit, I try to write efficient code ie use less memory, less cpu time etc... This some times leads to the code being hard to understand, no matter who is looking at it. Yea i try to keep it simple and plain, but sometimes to get that speed plain and simple doesn't work. So comments come in, not on every line, hell no, but a little summary saying what the method does is quite fine.

Mitch on July 25, 2008 8:50 AM

As stated above by several others, my most common use of comments is for business logic. As the majority of applications I work on are complex applications with obscure business rules, leaving comments definitely helps future developers on the project.

David Parker on July 25, 2008 8:54 AM

The argument that

SquareRootApproximation(n, Type.NewtonRaphson)

is more readable than

// Uses Newton Raphson
private double SquareRootApproximation(n)

is pretty weak. I'd rather see a comment here than the first one. While I think you do have a good point about bad comments, please try to find a better example before you make your point. The current example is terrible because it does need at least one comment to be completely readable and easy to maintain and therefore, weakens your point considerably.

Cecil on July 25, 2008 8:56 AM

At school, the only thing the profs teach in the first 8 weeks is commenting. In my first year the teacher would knock points off every program we wrote, if there wasn't at least one comment for every line of code.

Chaise on July 25, 2008 8:56 AM

I like comments as easter eggs -- my last day at a job I added a joke to a colleague as a comment. Three months later I got a nice call from him :)

paul on July 25, 2008 8:59 AM


Scott please bring some perspective to you blog entries, you make some valid points but why do you see the need to make everything so extreme?

I promise to carry on reading but I would prefer a more balanced discussion. I appreciate this is YOUR blog, but as you have clearly positioned yourself as a semiprofessional blogger, I'm not sure it is becoming of you to be so myopic.

Joe on July 25, 2008 9:04 AM

I think the one point developers should take out of this is the bolded note You should always write your code as if comments didn't exist. It's probably one of the hardest tasks in our world and for those of you against self-describing, simple code, shame on you. There is enough complexity in the systems we produce that it makes little sense to have it at the functional level.

I am often guilty of poorly name variables (love the 1-, 2-, and 3-letter names...) but I often find myself going back and renaming them later. My past excuses for short names has since been trumped by Intellisense -- less time is compromised by typing long names as the IDE does it for me now.

I've had one what-the-heck moment with some critiqued code. The first was with a continue statement in C++. You should put a comment in there to say what 'continue' does. My confused reply -- You want me to explain a keyword of the language?

The last comment as I'm typing this is In a perfect world our comments would write the code. I like the implications of it -- imagine a world where people used proper grammar and spelled words correctly...

Great article Jeff!

Austin on July 25, 2008 9:06 AM

A slight side-note:
If the best code is no code, what is the best comment?
lets think about the 'best code is no code' theory.....

Does moving your logic into a config file really make 'less code'?
What if your config file is really 'perl' expressions that get 'eval'd?

Alternately, what if the only way to record how some 'non-coding' configuration is through some umpteen series of screenshots for what buttons you clicked?

Sometimes the best code _is_ code.

Could you write something about that?
Please?
Pretty Please?

Eric on July 25, 2008 9:18 AM

Some sniglets for you:

Obso-doc: Comment detailing what the code did last year.

Redundo-doc: Comment literally describing source code statement(s).

Histo-doc: Ever-increasing comment section detailing revision history, typically duplicating information in Revision Control.

Igno-doc: Comment revealing author's lack-of-understanding of necessary algorithms, alternate syntax, etc.

Personally, I believe in minimal commenting in-code (doesn't count Javadoc documentation, which I don't consider comments) only to warn subsequent visitors (like me during maintenance) about certain code sections that are arranged a certain atypical way on purpose, i.e. to workaround something somewhere else. I prefix these with IST for Important Safety Tip! This heads off the What the F*** was he doing here? impulse to just rip it out and re-do it the right way.

The Gassy One on July 25, 2008 9:28 AM

My extended thoughts on this (in addition to comments posted above):

http://www.krissteele.net/blogdetails.aspx?id=70

Kris on July 25, 2008 9:33 AM

Not a fan of literate programming then?

http://www.literateprogramming.com

Personally, I think Knuth is on to something very valuable.

Like you, I really appreciate self-documenting code, but there are times when comments are absolutely essential for the next developer.

Your post can too easily be misconstrued; and, if there is one extreme that I have come across all too often it is the absence of comments.

Jeff, have you ever worked as a maintenance developer on a large application?

Jo on July 25, 2008 9:37 AM

I prefer to start with comments and fill in the code. This leads to good comments and good code. Once the code is working, I might prune/edit the comments that are redundant.

Giant template-driven comment blocks at the tops of files and before each function are useless.

One of my pet peeves is when people comment the interfaces with implementation details, and the implementation details with instructions for use. If you're in C++, where prototypes are often separated from implementations, it's good to think about the appropriate comments for each context. People looking at the prototypes are trying to figure out what your function does and how to use it. Developers looking into your implementation need to understand how it works and why you made certain decisions.

The commentless Newton-Raphson example could still be improved with a comment that says Newton-Raphson. At least that's something someone unfamiliar with the algorithm can search on.

Adrian on July 25, 2008 9:39 AM

Good timing. I was just hired to add a video snippet of code into someone else's website. The previous developer most have thought it was cool to reformat all of the code into one single line with no spaces or comments. It's a mix of bad ASP and HTML. So now I believe the previous guy knew he sucked and just wanted the code to be difficult to edit by the business owner.

So the ethics question is should I just insert my properly coded, commented, indented and extra white lines of code into the other guy's jumble of mess? Or should I spend the extra time on the previous developer's code and force line breaks at all of the right spots, create indentions at all of the right nestings and add comments as to what I think he meant to do???

Well this client happens to be my friend on my weekend soccer team and I think I'll extend the courtesy to clean the entire page.

My take on comments...

I give my clients the If I die speech each time I run a project where they are given complete access to all source code, source images and help files for easy transferance to any other programmer. And within the source code there is just enough comments to help a decent programmer. And within the source images, there are just enough comments on each layer to help a decent designer. When I mean decent, I mean that the comments are not too long or descriptive to help a non-programming business owner think that they themselves could attempt to make code changes. (dangerous).

Paullee on July 25, 2008 9:46 AM

I always heavily comment my code. It's not just for people to follow behind me. No. Its because 2 weeks later I'm knee-deep into something totally different and when I return to the previous code I need a gentle reminder.

As far as not having comments in your code, couldn't you use a comment stripper as part of your automated build process?

Ian Patrick Hughes on July 25, 2008 10:01 AM

Here is another one:

Identi-doc: Author tediously annotates each modification with their date/initials.

I don't know how many times I've seen this! Please everyone give that one up.

The Gassy One on July 25, 2008 10:01 AM

Heh, aren't function names themselves an abstraction designed to succinctly describe a block of code to programmers, just like comments? I mean, computers don't really care if you call it SquareRootApproximation, foo or 0x00401000.

Saying comments are bad is like saying coding is bad. There are intelligent and stupid ways of doing everything.

Also, C#'s /// syntax is arguably superior if you want to add descriptions to the autocompleter or to API docs. You can't make function names link to a Wiki article on Square Root Approximation. Why settle for that, when you can have an actual description in plain english and rich text markup support?

Leo Horie on July 25, 2008 10:03 AM

Please, pass the approximation threshold (t) to the private method.

Daniel on July 25, 2008 10:07 AM

I think ApproximateSquareRootOf( n ) would be even better. I always tell my developers that code shouldn't need comments. Methods should be small and well named, the best ones should read like English inc which case the code becomes the comments. Complex methods almost never exist. They are instead simple method comprised of still smaller and simpler methods.

Conditional clauses are my favorite. They almost never tell you the intent:

if( lstItems 0 lstItems != null ){}

gives me a lot of technical details.

if( this.AccountIsSelected() ){}

private bool AccountIsSelected()
{ return lstItems 0 lstItems != null;

gives me so much more information. And hiding that clause in a method lets me abstract away those details if I'm a maintenance program so that I don't need to keep everything in my head. Is the program having a problem with the account a user is selecting. No? then don't trace into that method...

Russ McClelland on July 25, 2008 10:14 AM

There is a fatal flaw with your example. When you named the method SquarerootApproximation the information about *which* approximation you are using is
If you made a mistake or there is some problem with that approach then you've just lost some vital information! Oh course NewtonSquareRootApproximation is not appropriate since that's an implementation detail.

The point of the article should be what information should be expressed in comments and what should be expressed through refactoring, method names, and variables. It seems to me that there is NEVER a method that needs *no comments*. After all what does your method do when the number is negative? There should always be _some_ comments, but always try to see how much of it you could express in other ways.

That's my $0.02.

Art Bugorski on July 25, 2008 10:36 AM

I think the Spartan Programming (http://www.codinghorror.com/blog/archives/001148.html) approach also applies to comments. For C#, I use the XML documentation comments and then I decompile my assemblies using Reflector. If the code and documentation that show up in Reflector aren't understandable, I refactor my code and revise my documentation until I can't make it any better. Then, if there's still something that isn't clear, I comment it.

Matthew Kane on July 25, 2008 10:41 AM

Totally in agreement. I take comments in general as an indication that the code itself has not reached its perfect state of self-evidence.
I attended a panel with the authors of Beautiful Code not long ago, and one of the authors mentioned that in his opinion, the only valuable comment in code was do not change this!...

Mathias on July 25, 2008 10:44 AM

I agree with Jeff ... up to a point. If you can document the code using the code itself, then you absolutely should, and comments that simply reiterate what the code says are an abomination and should carry the death penalty.

Having said that, in my actual programming work I tend to use comments as commentary ... at intervals, come up for air and jot down a note on where you've got to and what the state of the system is. I would say the code describes what the program is doing, the comments describe what the programmer is doing if I didn't suspect it of being a nice but meaningless sound bite. Comments don't appear every line, but generally before a compound statement, if/switch, function call or group thereof.

The last comment I wrote, incidentally, was A push of CS in 16-bit code is taken to imply a near call to a far function. Provided the next instruction is in fact a near call, we can just ignore it. I don't think you'll make the code that does that look like the comment that describes it.

I am, occasionally, guilty of the silly:

// What do you call a function written by a chav?
void init(void)
...

jim on July 25, 2008 10:45 AM

if your feel your code should be if you feel your code.

Excellent post. Thanks!

Raam Dev on July 25, 2008 10:48 AM

While I agree that meaningful method names are a big step in the right direction, meaningful variable names are just as important. In your example I have no idea what n, r, or t mean, or why you're performing those operations.

Jesse on July 25, 2008 10:52 AM

As Jeff points out, comments are ok, but the need to tell us WHY something works. WHY did we do it this way? WHY did we take the sub-optimal path. WHY shouldn't I change this code at a later date?

Take this example from real-world code:

byte[] docBytesHash = MD5.Create().ComputeHash(docBytes);
StringBuilder sb = new StringBuilder(32);
for (int i = 0; i docBytesHash.Length; i++)
sb.Append(docBytesHash[i].ToString(x2));

What is does is somewhat obvious, and may net even need a comment. But how 'bout this:

//remote machine seems to use case-sensative comparison
// don't change below to be X2.
byte[] docBytesHash = MD5.Create().ComputeHash(docBytes);
StringBuilder sb = new StringBuilder(32);
for (int i = 0; i docBytesHash.Length; i++)
sb.Append(docBytesHash[i].ToString(x2));

That comment tells me somthing that no code could tell me. It tells me about a dependency on a remote piece of code and a reason WHY something is coded that way.

WaldenL on July 25, 2008 11:01 AM

I haven't added a single comment, and yet this mysterious bit of code is now perfectly understandable.

The fact that this is bs, because the approximation algorithm is non-trivial, has been well covered.

But I would also add that the new code is also missing any sort of explanation for why you would use this thing. Of course, I suppose Jeff could add that to the signature as well

r = calculateApproximateSquareRootBecauseCallingSqrtDirectlyReformatsTheHardDrive(n)

Danil on July 25, 2008 11:10 AM

Jeff, please learn the difference between documenting the (intended) interface, and code comments: documenting some possibly weird lines of code.

After that, you may come back to talk about code with no comments and I'll be happy to read your blog again.

Your first pseudo-example for excess comments proves my point: Two lines of the comment are actually interface documentation, the rest is either implementation detail (which could be easily extracted from any actual code here, I hope), information which you could get more reliably from your source control system, and totally irrelevant stuff which you just made up, probably because without it it didn't look worse enough to prove your point.

Although, I must admit I didn't quite get your point yet - maybe we need to add more comments. ;)

Vinzent Hoefler on July 25, 2008 11:17 AM

Good article, I often will use comments as little notes to myself as I go. They usually melt away once I refactor the code pending passing tests.

ps. Those scoping braces on the same line as your statements are cringe inducing. Blech.

J.S. on July 25, 2008 11:35 AM

The first time I had a copy of Code Complete in my hands, somebody had told me You can really just open it to a random page, and there will be wisdom there. It's uncanny. So I tried it. I picked a random spot in the book, and opened to a section that discussed commenting code. What it said was something very similar to your argument. Paraphrased from memory, Comment to your code. Then rewrite the code so it doesn't need those comments. Then comment that.

Alex on July 25, 2008 11:43 AM

I would like to see a similar post about logging. Fellow programmers use logs as debugging tool... They keep the same debugging comments as operational logging comments when in reality they don't mean much to the people operating the system.

Joes on July 25, 2008 11:44 AM

I, for once, tend to agree with Jeff.

You can certainly take it too far, but given a choice between descriptive subroutine/variable names and comments, I'd pick the descriptive names.

Paul Houle on July 25, 2008 11:58 AM

Sometimes a coder don't understand even a simple operation. I think comments are vital for a program :)

Omar Abid on July 25, 2008 11:59 AM

re senior v junior programmers.

You're way off. I find the juniors are the ones who blat out code without putting comments in, these are the ones who tend to think they know what they're doing and commenting would just slow them down.

Senior devs tend to comment what they intend the code to do as they go along.

On the other hand, perhaps junior = poor, and senior = good would be better descriptions.

AndyB on July 25, 2008 12:05 PM

I find that adding a small description of what a method does in an xml comment block is more then sufficient. Anything more than that is just padding out your line count. :)

Jeremy Reagan on July 25, 2008 12:08 PM

Nice post! Even as I myself am a Technical Writer, zillions of comments in code don't make documentation necessarily better. It is QUALITY of comments, in my opinion, that are what really make a positive impact on the generated documentation.

Keith Johnson on July 25, 2008 12:22 PM

Am I the only one who dislikes refactoring to the point where each function has a huge name and only a line or two of code? I also have to agree with the other poster who doesn't like huge variable names. I think there's lots of cases, especially in numerics and scientific coding where complex algorithms can't be easily refactored into one-liners and well-placed comments are needed to make the algorithms comprehensible.

Totally agree that the old-school documentation blocks as shown at the top of your post are horrible, though.

queisser on July 25, 2008 12:30 PM

Jeff, what the hell is 'r' ? ;) Shouldn't it be 'root', or even 'squareRoot'?

And 't' isn't even defined here, but it needs a better name too.

I agree with the other commenters who suggest that you should still have a comment identifying that you are using the Newton-Raphson technique. Makes it easier for a maintenance programmer to identify the algorithm and look up its pros and cons.

Dan on July 25, 2008 12:30 PM

How bad is the code which checks for orange? Must have some values stored in Octal.

BugFree on July 25, 2008 12:34 PM

---
Here is another one:

Identi-doc: Author tediously annotates each modification with their date/initials.

I don't know how many times I've seen this! Please everyone give that one up.

The Gassy One on July 25, 2008 09:01 AM
---

Oh.. this is needed for some programms for medical devices and code reviews. We have signed code for MR-Scanners.

DawnOfWar on July 25, 2008 12:47 PM

Because you work with joel, you think you can give us the advice of the day (Don't disable menu item) ? I mean, programming and one of your favourite book is all about subtility and heuristic, and not giving some rule you illustrate with a two line function.

This is blog trollism. Hopefully the link are there to provide us some content, and steve yegge's post is great as usual. You have a great blog, but please, give it up a bit with your strong opinion, weakly held motto.

I hope you don't do spartan programming + no comment, the result must be quite ugly :)

bandini on July 25, 2008 12:50 PM

I ran across some old Basic code the other day that I understood absolutely perfectly. I understood everything that it was doing.

But I had no idea WHY anyone would do this or WHEN it happened or WHAT it was trying to accomplish in the big scheme of things. It was clear...but pointless.

It took me 1-2 hours to figure out the code but 2 weeks to figure out when it was used and why.

Even Jeff's comment about SquareRootApproximation misses the point. As long as you tell me it's a square root function (comment or method, don't really care), I can test it fairly easily and I care very little which method is being used because I can easily replace (with return Math.Sqrt(n);) it if it's found to be wrong.

But why the HECK is Jeff rewriting Square Root anyway? Does Math.Sqrt() have a bug or something? Does one of the many easier alternatives of computing square roots not work?

I still have absolutely no idea why this was done, what to do if it has a bug in it, nothing... Everything Jeff made a huge deal about in the article is rather pointless when I come back to his code.

Huge comment block? Easily ignored with PgDn.

Comment or Method? Don't care.

Using an enum parameter to avoid a comment? You're an annoying dork, but I don't care.

Not giving the how, why and when? Major issues when it breaks.

PRMan on July 25, 2008 12:51 PM

I'll agree with Jeff on this one. Write the code to be as clear as possible. Use peer review to help. Comment on WHY and not WHAT.

I've worn out many a Page Down key by skipping over headers in files (my last company required them). Most of the time the WHAT didn't match with the working code, so I acquired the habit of not reading them.

For those of you who have never seen too many comments, consider yourself lucky. I had one project where the developer put no comments in 30,000 lines of code. He was told to comment the code, so he wrote and AWK script to put comments on every line. The comment was usually one word, such as 'yes' for if (someCondition) and 'no' for else {}, and 'oops' for exception handlers. The code itself was pretty good for it's time (1994), and when I asked an old co-worker about it, is still in use today.

Tim on July 25, 2008 1:03 PM

private double SquareRootApproximation(n)

Great, now you're paying function call overhead on each call for an algorithm that is usually used in places where it needs to be run often and fast. The comment would have been a much better choice.

Comments rapidly become out of date with refactoring, and with fellow programmers not updating it.
That is an excuse for sloppy and lazy programmers. If it hurts when we that, then maybe it's time we figure out that we shouldn't be doing that. I suggest a simple four step program:

First offense = verbal warning
Second offense = noted on performance review
Third offense = forfeit bonus
Fourth offense = termination

Harsh, you say? Far mor lenient than government or financial institutions' penalties for not keeping your house in order, I say.

Also, why are you reading the code if you don't know why or how you got there?
I take it you work in a rather sheltered environment. Ever have an emergency fix request for a project you never worked on dropped in your lap?

If you can't tell what the code does without comments, the code isn't done yet.
Have you ever considered the fact that the maintenance programmer is likely not going to be at the same level of experience and skill as you and is going to need some crutches?

GrumpyYoungMan on July 25, 2008 1:05 PM

Commenting code goes way beyond typing double slashes and telling little stories.

Jeff has demonstrated some great idea's that go beyond what a beginner would.

Isolating a code fragment (probably re-usable at that) and giving it a meaningful name is a great first step.

Getting all of the FM (Funny Magic) numbers out is great too. Constants can be named to something meaningful to add context. I realize that the constants in this example are too simple to bother naming.


I am undecided about where to document the actual Newton-Raphson algorithm and will sit on the fence on this one.

Putting a type declaration on the argument list on the method call certainly alerts callers as to what algorithm is being used, but I still wonder if that should be encapsulated inside of the function itself.

Hard to answer without knowing the importance of the algorithm and why it was chosen instead of a standard library function.

davide on July 25, 2008 1:09 PM

Agree, i have no problem with naming stuff like GetWeekNumberStartingFromLastMondayOfPreviousYear(), with intellisense you only have to type 3-4 letters anyway.

But if you have to concat some strings with several calls to the method i try to come up with a shorter name.

Crazy Ivan on July 25, 2008 1:10 PM

-- 8 -- snip --
I had one project where the developer put no comments in 30,000 lines of code. [...], and when I asked an old co-worker about it, is still in use today.
-- 8 -- snip --

That's probably because no one dares to touch 30K lines of code without having a clue what it is supposed to do.

SCNR.

Vinzent Hoefler on July 25, 2008 1:15 PM

never, ever start with comments ??
I do it all the time for almost 20 years now. Worked pretty well so far.

Holli on July 25, 2008 1:17 PM

Ok, I'm pedantic. Maybe the last line of the refactored code should pass n as the parameter, rather than r.

System.out.println( r = + SquareRootApproximation(n) );

I love the Refactor menu in eclipse - it saves problems like this.

John.

John on July 25, 2008 1:18 PM

When it comes to comments I find I have a weak beliefs, weakly held methodology. Verbosity, lack thereof, algorithm references (eg Newton-Raphson), why vs how- I mean, any one of reasonable programming experience could argue any one of these, on either side, indefinitely. The only advice on commenting I ever hard that I really feel should be applied in all situations, is in the beginning of every oreilly book. If any of the previous rules makes the code less readable, throw [that rule] out.

Every rule you ever hear about good commenting is a guideline. There will be exceptions to that guideline. Pointing out exceptions to the guideline as proof that it's not infallible (and implying that not infallible = bad guideline) is honestly kind of useless.

Alex on July 25, 2008 1:19 PM

It's OK to end up with comments in your code, but never, ever start with comments. - I guess this line was edited out? Cos I can't find it in the article. Good thing too.

Andrew on July 25, 2008 1:27 PM

Comments are great. Take another step.

Use GhostDoc to automatically generate comments for methods (a short description with parameters, if your function has a good name, also the comment is quite good too). What do you do with this comments?

Next Step: Use Ndoc to create an html Helpfile for your Code on basis of the comments.

Next step: automate the process so that you can have a daily helpfile for your actual code. Fast to browse with keywords for new developers.

A good thing is, that if you name your classes and methods correctly you can see in the comment quite good results.

Two examples of auto generated comment
E1
/// summary
/// Compares two objects and returns a value indicating whether one is less than, equal to, or greater than the other.
/// /summary
/// param name=xThe first object to compare./param
/// param name=yThe second object to compare./param
/// returns
/// Value Condition Less than zerox is less than y.Zerox equals y.Greater than zerox is greater than y.
/// /returns

public int Compare(Object x, Object y)
{
if (x.Weight == y.Weight)
{
return 0;
}
else if (x.Weight y.Weight)
{
return -1;
}
else if (x.Weight y.Weight)
{
return 1;
}

return 0;
}
E2
/// summary
/// Handles the RunWorkerCompleted event of the backgroundWorkerPoll control.
/// /summary
/// param name=senderThe source of the event./param
/// param name=eThe see cref=System.ComponentModel.RunWorkerCompletedEventArgs/ instance containing the event data./param
private void backgroundWorkerPoll_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)


You just need to add on or two lines yourself to get a code documentation. Really needed at big projects were each code is reviewed.

(The next tool in line would be something like FXCop to see if your code follows the company rules)

offler on July 25, 2008 1:29 PM

I agree that comments need to add value to the code and need to be maintained; however, I disagree with over-reduction of comments.

Source code is designed to bridge the gap between machine logic and human communication/thought. While this makes it a great medium for telling the machine what to do, it's not designed to be as fluent or natural as human language is. Reading code requires a mental translation to occur before you can make sense of it. Writing code requires that same process in reverse.

I comment a lot (oftentimes, every line.) I do this because if I can't write out the code in English, I don't understand enough of what I'm doing to be coding it. When I later revisit the code, I can read it in my own words just by reading through the comments. I also use such comments to refactor and clean up what's going on. It's easier to spot logical errors when you can see them in your own words.

I'm sure there's a benefit to developing a mental process that handles this translation for you but to me it seems unnecessary. I want to focus on the essence of the code not the semantics.

Nicx on July 25, 2008 1:39 PM

I've always felt that methods shouldn't need comments inside them, only comments describing the method should be enough.. if that even made sense

// comments go here
private void foo()
{
// not here
}

the comments are there to describe what the method does, not how it does it. How it does it can easily be seen if you look at the code

Thomas Winsnes on July 26, 2008 2:24 AM

roflmao: Are you taking the piss mate, or were you just asleep for the last 7 years?

I tend to feel that the member name and the parameter names should usually be (made to be) sufficient. Beyond that, RTFC.

This changes for binary-only distributions for developer clients, of course, which I almost never do. Mate.

Atario on July 26, 2008 3:14 AM

This is off topic, but I would like to suggest a blog entry subject.
I was looking what you have written about build systems and found these:
- December 06, 2004 The Magical Build Machine
- October 26, 2006 The Build Server: Your Project's Heart Monitor
After a quick read it seems you have changed your mind about the importance of build servers. It would be interesting to know how many of your old blog entries contain opinions that you have changed your mind about.

Not that there was something wrong with discarding old opinions. Just curious.

Bloodboiler on July 26, 2008 6:07 AM

While I'd rather have too many comments than too few, I agree that a good balance and few comments is best. It is quite obnoxious to work with developers that need to tell a story and comment every single fricking line. With spaces in between. So the simplest 5 line code becomes a whole page of tripe, and takes 3x longer to comprehend. But I'm not bitter.

boomslice on July 26, 2008 6:23 AM

Powerlord -- Miss the point much? I don't see Atwood as writing a unique function here.. he's just trying to illustrate that some random function doesn't need physical comments to be descriptive.

Anyways, I'm not sure I agree 100% with what Jeff says. In other posts he reminds us that someone else will eventually have to maintain our code. I'd like to take it one step further and say that the new set of eyes might not know what you were trying to do and that is dangerous, unless you have comments in place saying what the nondescript 'r', 'n' and 't'. I mean, would it kill you to use variables with descriptive names? Does it really hurt to put the single line comment saying what method you're using to approximate *providing* you don't overdo it?

Good post. I read your blog all the time.

Hutch on July 26, 2008 8:16 AM

Comments or not, all the extra whitespace around your encapsulations confuse me! ;)

sascha/hdrs on July 26, 2008 9:54 AM

This is well covered in CodeComplete, which well I guess is where you got the name of your blog from. I think Mcconnell would still say you still haven't taken it far enough.

private double SquareRootApproximation(n) {
r = n / 2;
while ( abs( r - (n/r) ) t ) {
r = 0.5 * ( r + (n/r) );
}
return r;
}
System.out.println( r = + SquareRootApproximation(r) );

what is r? what is n? what is t? Certainly isn't obvious. Your refactored example is still a Coding Horror because you are using 1 letter variable names.

Rob on July 26, 2008 11:21 AM

As a maintenance programmer, I'd replace this function with

private double SquareRootApproximation(double value) {
return Math.Sqrt(value);
}

since it's never explained why the algorithm is used over the built-in square root algorithm.

Even better, I'd replace SquareRootApproximation(r) with Math.Sqrt(r) directly and dump the function entirely.

P.S. Your code examples work better when they actually compile. Also, bounds checking might be a good idea, since you can't take a square root on a negative number without going into imaginary numbers. I believe that Math.Sqrt() returns a NaN value in this case.

Powerlord on July 26, 2008 1:40 PM

Suggesting that comments should be left out for readability is like pouring out the baby with the bathwater.

I'm a senior developer (25 years) and I've seen code that would make your toenails curl up. The junior programmers' most favorite comments are:

- The code is self-explanatory.
- I didn't have time to write comments. The schedule was too tight.
- Comments are detrimental to legibility.

I'm sorry, but if you're working on a project with over 10,000 modules containing 10,000,000 lines of code, a comment here and there isn't too much too ask.

Code routinely gets thrown away because it doesn't contain any comments, and only the original programmers know what it does.

Especially when you look at brain-damaged stream-of-consciousness code that lacks any structure or abstraction, you get cravings for comments. Otherwise, the reader might do a mark-delete and complete rewrite operation faster than the original programmer can say Stop, I'll explain it to you!

Spaghetti code is not just limited to C, it's also widely spread in the C++, Java and C# worlds. Bad object hierarchies, nonsensical interdependencies and so on are all around. The solution when one team is replaced by another is most often a complete rewrite, because none of the original code was documented. On the other hand, well documented code can live for decades.

Anonymous on July 27, 2008 2:20 AM

I agree. well almost. Sometimes comments are life savers.

Just wrote an entry in my blog about all this and an incident which made me write more comments than ever...

http://code.zhandwa.com/2008/07/27/code-comments-do-we-need-them/

zhandwa on July 27, 2008 2:28 AM

@Rob

what is r? what is n? what is t? Certainly isn't obvious. Your refactored example is still a Coding Horror because you are using 1 letter variable names.

r should be named root or result

t should be be eps, tolerance or precision

n is a bad variable name, because numerical coding has a Fortran tradition, in which i,j,k,l,m,n are names of integer parameters. It should be replaced by x, which is short and to the point -- you want to calculate sqrt(x).

@Thomas Winsnes

the comments are there to describe what the method does, not how it does it. How it does it can easily be seen if you look at the code

This is impossible to achieve in numerical code, because

x = (a - b) * (a + b);

and

x = a*a - b*b;

look equivalent *in the code* but they are not really equivalent due to floating point rounding errors. It is expecting too much from your fellow programmers to immediately recognize all the tricks you've done to increase numerical stability of your computation. Hence, it needs commenting.

katastrofa on July 27, 2008 3:18 AM

Never Start With Comments?

As with any edict, it has a grain of truth but I think misses the mark? Just refactor your comments like code. If you aren't starting with solid defined documentation then one of the best things to do is to pseudo code/comment code your functions and call flow. Then, you just refactor the comments with the code, removing out what is made self evident by the code itself. A touch of extra commenting won't hurt.

Stephen on July 27, 2008 3:52 AM

I'm so glad I comment my code extensively...it really saves me a lot of time when I have a maintenance task come up two or three years after writing a bunch of complex (for me) code. When I have some difficult code to write I begin by writing an outline, as comments, of what the code should do. It helps me write it, I leave it in, and it helps me maintain it. I can't see any reason why this is a bad thing.

Nebo on July 27, 2008 4:53 AM

/*
* FUNCTION: bitcount
* ARGS: n 32 bit container
* RETURNS: count of set bits
* DESCRIPTION: MIT Bitcount
* Consider a 3 bit number as being = 4a+2b+c
* if we shift it right 1 bit, we have = 2a+b
* subtracting this from the original gives = 2a+b+c
* if we shift the original 2 bits right we get = a
* and so with another subtraction we have = a+b+c
* which is the number of bits in the original number.
*
* Suitable masking allows the sums of the octal digits in a 32 bit number to
* appear in each octal digit. This isn't much help unless we can get all of
* them summed together. This can be done by modulo arithmetic (sum the digits
* in a number by molulo the base of the number minus one) the old casting out
* nines trick they taught in school before calculators were invented. Now,
* using mod 7 wont help us, because our number will very likely have more than 7
* bits set. So add the octal digits together to get base64 digits, and use
* modulo 63. (Those of you with 64 bit machines need to add 3 octal digits
* together to get base512 digits, and use mod 511.)
* This is HACKMEM 169, as used in X11 sources.
* Source: MIT AI Lab memo, late 1970's.
*
* Unit test validated on ******
*/
unsigned int bitcount(unsigned int n)
{
/* works for 32-bit numbers only */
register unsigned int tmp;

tmp = n - ((n 1) 033333333333UL) - ((n 2) 011111111111UL);
return ((tmp + (tmp 3)) 030707070707UL) % 63;
}

smallstepforman on July 27, 2008 5:13 AM

Jeff, do you think all these people write that comments are good just because they enjoy writing them?

I for one write comments because I have such a crappy memory, even with self-explaining methods variables they may not be self-explaining to me in 2-3 years. I often sit and think why did I do this again? finding a comment then is like finding a pearl in the muck.

TDD is a good tool for producing self-documenting functions however is not a silver bullet that replaces comments. The tests tend to be very detail oriented however it doesn't explain the thought process behind the function.

just my 2c
Anders.

Anders on July 27, 2008 5:29 AM

FWIW (i know this won't get read by now), i'd advocate splitting the function into 2:

a) a public function
public double squareRootNewtonRaphson(n) {
...implementation
}

b) a private function in the module which requires it:
private double squareRootApproximation() {
return squareRootNewtonRaphson()
}

This has several advantages:
- anyone reading the application code just seens squareRootApproximation, which is easy to understand without having to worry about implemenation details
- anyone wanting to dig further into the implementation immediately sees that it's implemented using newton-raphson
- the Newton-Raphson implementation can be added to a standard library (better still, find an existing implementation which works)
- the squareRootApproximation implementation can be easily switched, eg if it's found that newton-raphson is not accurate enough.

As far as comments goes, the only place i'd possibly put a comment is in the squareRootApproximation header, to explain why i'd decided to use the newton-raphson method in this particular case.

stephen on July 27, 2008 5:53 AM

Not all code can be obvious, especially if performance enhancements have been made. Long comments are typically there because the enhancement has made the code less readable. The aim of coding isn't to make haiku, it's to make programs work. (See @smallstepforman comment above)

Comments are also useful because hopefully it stops some loon coming along and 'fixing' it because they don't understand it's not broken.

Not all code is easy, and contrived examples always fail to impress.

The only thing better than a comment is a test, because the test should break when the code does.

tricky on July 27, 2008 7:28 AM

@stephen
I think that's a pretty good approach, the only problem would be that you might end up cluttering up the code with loads of generic to specific calls. Certainly, I can't see any way in which it could be misunderstood.
See, your comment did get read.

Tom on July 27, 2008 7:36 AM

«Back | More comments»

The comments to this entry are closed.