GameboyHippo wrote:

> Ideas like that make my job that much harder. I'm constantly porting
> old code to new code. Comments are crucial. Maybe not a comment for
> every line of code, but perhaps something at the beginning of each
> code item that is public (such as functions and classes). Trust me,
> I'm not a guru in every business out there so sometimes I need
> comments to explain a business rule or two.

I did not say don't comment. I said your code should be
self-documenting. I don't know in what domain you are
programming, but if your design conveys your intent,
the compiler should do the talking when you are using
the code erroneously (ideally). All said, we don't live
in an ideal world. Nevertheless, use the mechanism
given by the language and your compiler to convey your
intent (and to encapsulate) and then things will be clear
enough for you (and the maintainers).

Yes, if old code does not convey intent, sometimes
comments are sorely missed, but this has nothing to
do with my point. I've also maintained large ugly
projects (with lots of comments), and the comments
did not seem to help.

In fact, sometimes a requirement or two were commented
out, and when uncommenting this, the program would
suddenly crash in some weird place. Other times
code that was not used were kept just in case it
might be used again, etc, etc. It was hard to figure
whether comments were applicable, as comments
applicable to commented out code were left in etc,
etc. I've had my day of maintenance with and without
comments.

W