 |
lua-l archive |
|
|
||
|
On 6/6/2017 2:58 PM, Russell Haley wrote:
On Tue, Jun 6, 2017 at 2:27 PM, Hisham <h@hisham.hm> wrote:And here's another Style Guide added to the list, taking input from the ones posted in this thread, and adjusting them to the style guide as used in the LuaRocks codebase. Enjoy! https://github.com/luarocks/lua-style-guide -- Hishamhttps://github.com/luarocks/lua-style-guide#line-lengths Rationale: No one works on VT100 terminals anymore. If line lengths are a proxy for code complexity, we should address code complexity instead of using line breaks to fit mind-bending statements over multiple lines.
I've had my head stuffed in a book design task (using LuaLaTeX) recently. There really is good rational from book design for shorter line lengths based on studies of readability of running text. Printers (the people who handle lead type and spill ink on things) have known this intuitively about as long as moveable type has existed. The rule of thumb is that lines of print should be perhaps 45 to 75 characters long to avoid tracking to the wrong line as one reads. Mitigating that in code, you have the varying indentation, but generally keeping the ink to 66 characters more or less is likely easier on the reader.
In an 80 column screen, a block of 66 characters leaves up to 14 spaces for indentation. At 4 spaces per indent, you get three levels, at three per you get four levels. I'm inclined to argue that if you needed five levels you might have a problem that could benefit from some refactoring. In the deeply nested loop cases where you can't refactor that away, the loop body is likely expressible in less than 66 character lines if you choose local variable names judiciously.
Of course, code is usually set in fixed-pitch fonts, which actually makes tracking on long lines even more difficult.
Adding to that is the observation that at 10 chars/inch, an 80 column screen fits within the printable borders of a letter-sized page (both US letter and metric A4). Scatter in a few ASCII FF characters in front of significant breaks in program flow, and listings become almost pleasant to read.... (ok, I guess I'm old.)
-- Ross Berteig Ross@CheshireEng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602