i don't think you can judge a book by it's cover, ie just because some program is not commented doesn't mean it's not understandable. For example, my code is very simple, as I come from a C background and modular functions school. If anyone can't understand my Perl code, it's because they don't understand Perl, and shouldn't be trying to evaluate it on that basis. What you should have in the first place (hopefully getting written and updated as a program is created) are standard design docs: requirements spec, any implementation spec eg flowchart/functional decomposition/data flow diagram, and a data dictionary. If you haven't got these then how can you tell if a program is doing what it's meant to. With code, in particular, what is more important than a count of comment lines is a measure of code obscurity. I do produce docs when I write any code that's going to be roughly more than 50 lines of code, or is quite complex. Also have gotten into the habit of putting a comment line just above where I process longer bits of data, spelling out it's structure. There is no replacement for code clarity. So I would rather go through nice code without comments rather than deciphering obfuscated code and its' comments.