Comments are "reached for rarely and last". Whatever shortcomings comments have pale in comparison to being faced with and trying to figure out undocumented or too sparsely commented code, which, in my long experience, has been an order of magnitude more prevalent than sufficiently documented/readable code. Heck, even a wrong comment is sometimes preferable to no comment if it at least gives me a clue as to what the purpose of that section of code was at some point in its evolution.
I personally strive for code that can be read as a sentence, especially in complicated sections of code.
This sometimes leads to weird intermediate variables which might look superfluous, e.g. intermediates like:
foo_has_at_least_1 = len(foo) >= 1
(not a great example, usually it’s a bit more semantics. than that) but later code using those intermediates reads as english,
which can reduce cognitive load when reading the code and obviate comments, and preconditions are more readily verified.
It’s literate programming and I prefer that to long comment blocks like those in some
of the examples. All that said, it can be hard to get coworkers into such a habit, especially those who feel brevity and abbreviation is a virtue.
The problem comes not with what the code does but why the code exists in the first place.
The only time I ever feel the need to leave comments is to explain code that doesn't appear to be needed or isn't obvious why it exists. Usually this comes from agreed upon technical debt, short notice requirements with tight deadlines, or some other form of tradeoff.
"We're doing a simple check and throwing an exception here since we have work to introduce a more comprehensive permission system in xyz epic"
or something like
"There's a complicated race condition in xyz so we're doing a simple sleep here since the proper fix involves introducing a distributed lock"
Sure those types of things are cases you want to avoid but unfortunately you occasionally end up there anyway and leaving a short explanation about a compromise is better than ambiguous code that appears to serve no purpose
I dont think that held in the examples or a lot of what I have seen in practice once comments become the norm. Most classes should not need a comment in them at all. Most methods should be self-explanatory. A comment detailing every line of code is a huge smell.
Although some geniuses have mental disorders, don't make the mistake of thinking that all people with mental disorders are geniuses or have special insights - we're just run-of-the-mill people that run the gamut of abilities and personalities. And "happy" is not the right word to use for depression. As Peter Kramer said in his book, AGAINST DEPRESSION, the opposite of depression is not happiness, but resilience. If you suffer from true clinical depression, you can appreciate this distinction.
Agreed. Depression isn't about happiness versus sadness. Depression is about feeling so overwhelmed by everything in life, about every problem and issue being the same "volume" in your head and being unable to prioritize. This leads to a feeling of helplessness and impairment and withdrawal from decision making - a cycle that perpetuates itself.
A number of programming languages allow an arbitrary range of indices for an array, including Ada, Fortran 77, and Pascal. See the "Specifiable Base Index" column in this table at Wikipedia: http://en.wikipedia.org/wiki/Comparison_of_programming_langu...
I was a long-time Tcl user and loved it. [incr Tcl], incidentally, is not a play on "+=1", but "++"; i.e., [incr Tcl] is to Tcl as C++ is to C. Speaking of event loops, before Tcl had its own event loop, I wrote a select()-based event loop extension to Tcl that was similar to the Xt event loop. For that, I was (or still am for all I know) listed as an extension contributor in the Tcl/Tk FAQs.
[incr Tcl] was a great OO framework for writing GUIs. Perhaps not the greatest framework since it was trying to mimic C++.
As antirez said, "It's like learning Scheme or FORTH: mind changing."
Have you ever read a technical article by Donald Knuth? He is not brief; he writes engagingly about low-level details. David's posting was just fine, in fact great. The posting was not that long and you could pick up the gist of it in the first few paragraphs.
From Wikipedia (http://en.wikipedia.org/wiki/UTF-8): "UTF-8 (UCS Transformation Format — 8-bit[1]) is a variable-width encoding that can represent every character in the Unicode character set."
I read a couple of papers on the backlash (even by expert economists) against the heavy emphasis on mathematics in economics, which, IIRC from the papers, began back in the 1940s. Basically, economists work hard producing mathematically coherent models that aren't applicable to the real world.
This is a good point, and it's a problem in theoretical economics. Some economic models abstract away some important real-world conditions.
My experience, though, is with applied macroeconomics. We'd derive models consistent with theory, then make sure we avoided a number of time series pitfalls (autocorrelation, mistaking cointegration for correlation, overspecifying a model) using a variety of statistical techniques.
UCSD Pascal compiled to p-code. Other Pascals compiled to native code. The Wikipedia entry for Turbo Pascal indeed mentions that the TP-generated executables were extremely fast, which was a revelation to UCSD users.
Early in my programming career, my team leader took me aside and explained how to write an effective and persuasive memo that would get through to management. It was valuable advice as the rant I had written got nowhere. And management is not the only target audience with short attention spans; same-level colleagues have been equally challenged by having to read an E-mail longer than 1 paragraph, even when it concerns technical details of the project they're working on. Consequently, I dumb down E-mails in an effort to get the attention of as many of the recipients as I can. Condescending? No. Realistic? Yes. (Given my druthers, I'm normally prone to writing Yegge-length E-mails and memos; I've just learned that less is better when trying to through to the most people.)
