[elmomalmo]

I've worked with a lot of legacy code over the years. I don't usually care whether code has comments or not. Comments are a very poor way of expressing semantics in code.

Usually, I'm looking for general readability and understandability. I'd much rather see short, well-named classes and methods, well-named variables and good unit tests before I see a single comment.

In the absence of clean, readable code, comments are probably a reasonable but nevertheless inferior resort. I also agree that, sometimes, they 'why' of code is often best expressed as comments.

[nupark]

I've worked with a lot of legacy code over the years. I don't usually care whether code has comments or not. Comments are a very poor way of expressing semantics in code.

When working with legacy code that is not commented, how do you determine the invariants of an API?

That is, how do you ensure that the change you're making will not break other code? Do you have to scan the entire project, and any other projects that depend on it?

Unit tests are often not sufficient here -- changing the invariants of an API may not result in deterministic failure -- in fact, invariants often describe requirements necessary for deterministic behavior.