Hey can i get an example of ugly code and beautiful code? is the ugliness of a code objective or subjective?

Pages: 12
There is a pretty good section on comments in "The Pragmatic programmer", by Andrew Hunt and David Thomas.

I figured I might as well post some of it.
Comments in Code
In general, comments should discuss why something is done, it's purpose and it's goals. The code already shows how it is done, so commenting on this is redundant and is a violation of the DRY principle (don't repeat yourself).

Commenting source code gives you the perfect opportunity to document those elusive bits of a project that can't be documented anywhere else: engineering trade-offs, why decisions were made, what alternatives were discarded, and so on.

We like to see simple module-level header comment, comments for significant data type declarations, and a brief per class and per method header, describing how the function is used and anything that it does that is not obvious.

Last edited on
I agree completely with that, except that I'd stress that comments in the body of a function should be kept to a minimum (they seem to agree but they don't explicitly state it). If you write functions that are only about 5 lines long, as I believe you should, then you'll rarely need comments in function bodies. I'd also like to add that comments for data types, classes and functions/methods should only be in the header file (I used to put them in both source and header files, but it's very distracting). Obviously this doesn't apply to languages which don't have header files.
Topic archived. No new replies allowed.
Pages: 12