As for "Save data
I might have a better impression of comments if I had ever seen a good one but the code base I work in now is clean enough that they're often unnecessary but conspicuously absent when needed.
You go ahead and just read the code then - I can read five words a LOT faster than five lines of code, and the code only tells you *what* is being done, not *why*. A brief statement of intent can save you a lot of work reverse-engineering the code to extract it's purpose.
I find about 20-30 lines of code per function/method to be about right with descriptive naming you can gather the why from the context and the how from the code. It also allows you to skim the code for function names which if properly descriptive can be guessed at least approximately without prior knowledge. If your code goes above that 20-30 lines (for a good reason they do exist) then comments become more useful as delimiters. I am quite sure there are times my advice is not applicable but for most cases (50% + some epsilon > 0) refactoring would be the better option.
Ugly code is still obviously where most of the comments live, precisely because you (err, I mean the *next* guy, obviously) probably will need help understanding *what* is being done. For the same reason those comments tend to be the least helpful over time unless everyone who modifies the code is really anal about updating the comments to reflect their code changes.
Sad fact is that every time I've wanted to see a comment in code there wasn't one and almost every comment I've ever seen in code referred to code that was no longer there or was in fact wrong (Save data to database set isDirty flag to true WTF???).
That's why we have a police force. It's called civilization.
And the police are going to protect you? That's not their job and it never will be they're there to clean up the mess after you're already dead.
Chemist who falls in acid is absorbed in work.
