Comment Re:We have the same... (Score 1) 689
Once assimilated you'll find a lot of the second or third generations being just as lazy as any other native.
You cannot prove that parallel lines do not intersect purely by using geometry. You cannot prove 1+1=2 using math. The former is treated as an axiom, a statement that is intuitively assumed to be true in further proofs. The latter is a definition of terms - given what 1, 2, addition and equality are defined as, the statement is true.
The former is not treated as an axiom it is an axiom and as such it cannot be proven in any system. The latter can indeed be proven if you step outside of the bounds of algebra (which is a field of mathematics that covers addition) and into the bounds of set theory where we have a definition for 1 and a definition for 2 and a definition for the process of addition and using those three definitions we can indeed prove that 1 + 1 = 2. In algebra we would define the addition of our system such that 1 + 1 = 2 at which point it is treated as an axiom. To be clear there are systems where 1 + 1 != 2 (boolean algebra) but we can assume you knew that and were specifically discussing integer arithmetic.
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.
Any circuit design must contain at least one part which is obsolete, two parts which are unobtainable, and three parts which are still under development.