5 ms·
Exactly. There isn't a programming language in the world, and never will be, that can explain the WHY of the code being written. I write tons of comments explai
by jameskilton 16y ago
Exactly. There isn't a programming language in the world, and never will be, that can explain the WHY of the code being written. I write tons of comments explaining WHY I'm doing things so that 1) I can understand what I did when I come back to the code and 2) Other people can understand what I was thinking and how the code fits into the greater whole.
I HATE code with no comments. And tests are not sufficient documentation, though that's an argument for a different time.
- elmomalmo 16y agoI'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 16y agoI'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.