2011/1/31 Andrei Alexandrescu <seewebsiteforem...@erdani.org>: > On 1/31/11 11:54 AM, Ulrik Mikaelsson wrote: >> I'm not sure whether text-books and program-code are really comparable >> in this respect. When reading books I hardly put much attention to >> each particular word, while in computer-code, each token is very >> significant. The "flow" of reading is simply different. If it weren't, >> we would hardly use hard line-breaks at all, just concatenate >> statements like we concatenate sentences in text, and use<your word >> processor> to format code. Especially, we would not use monospaced >> fonts and care about "columns". > > Well the fact of the matter is that style used in books is very influential. > People do copy book samples into code and continue working in the same style > from them. I've been asked for (and released) the source code of all > snippets in TDPL.
Sorry, maybe I was unclear, I wasn't referring to code-snippets in a book. I meant the kind of text-books I understood Walter refer to, that made the basis for 80x25. Think fiction, not programming books. I absolutely agree there are good UI-design reasons to limit column-width in these. Commonly such text is also "text-align: justify", and even broken up into multiple-column layouts to reduce horizontal scan, but precisely those two things make me skeptical about just HOW relevant it actually is for computer-code. >> I would rather like to hear whether any mathematicians ever insert >> hard-breaks into their equations just "to not get them too wide". > > I'm not sure I can qualify as a mathematician but my research is very > math-heavy. In my thesis (http://erdani.com/research/dissertation_color.pdf) > I frequently inserted line breaks even when not technically necessary, check > e.g. eq. 2.16 on page 12. Thank you, interesting for the topic (although I didn't understand a thing of the actual math :). I note however that given the very terse variable-names (as is common in math), the lines don't actually grow very long. However, where you HAVE chosen to insert line-breaks, is at equality-operators which I would say is roughly a statement in programming-language terms. ("A = B" is a statement, while "A+B" is not.) Interestingly enough, this is roughly the rule-of thumb I use. Try hard to keep statements below 90 characters, but don't resort to manual line-breaks if it's not possible. >> Personally, I've been a long time on the fence regarding strict >> line-length, and my current position is: >> 90 columns is the rule of thumb. 80 columns is often hard to fit >> using readable names, but 90 columns generally works. > > Seems reasonable. Since both Jonathan and Don prefer longer lines, I'm now > more inclined to increase and/or soften the recommended limit for Phobos. Actually, writing and reading about it got me thinking. I think the real value of the 80/90/120/whatever-rule is not really the actual line-length itself. If that was the case, editors with auto-indentation could quite easily have additional rules for automatic code-wraps. The actual value of having the rule is to alert the coder that something _might_ be sub-optimally expressed. Perhaps D should have something similar to pylint? Sure, much of the need for pylint goes away in a statically typed language, but it's also quite good in diagnosing design by code-complexity measurements. OTOH things like symbols-per-file, arguments-per-function, operations-per-function, etc. could be good indicators to quickly spot hairy code. One could also check for naming-conventions and probably other cleanliness-aspects as well.