Live data from Hacker News

Excessive line breaks are bad

lkml.iu.edu

11–16 of 16 posts

Re: Excessive line breaks are bad

#11
This rant feels a bit banal, like it's going up against a straw-man just to be ... a rant. On one hand, I can't think of the last time a developer in an org I've worked with hasn't conspicuously and regularly used text windows wider than 80 columns. On the other, well-written code (and prose!) also exploits limiting line length for clarity and readability. There's clearly a balance, helpful rules of thumb paired with useful times to break those rules.

To be honest, the worst regular example I encounter, in either direction, is Markdown source with no hard line breaks. Markdown fully supports them, and trying to read paragraphs in whatever-hundred character lines is a painful exercise. Such irony, since part of the beauty of Markdown is dual readability in both source and rendered forms.

Re: Excessive line breaks are bad

#15
> But still - it's entirely reasonable to have variable names that are 10-15 characters and it makes the code more legible. Writing things out instead of using abbreviations etc.

This is my main justification for ignoring any particular limit on line length when writing code, especially when I'm using libraries that have really long method names.

Re: Excessive line breaks are bad

#16
post #6

I'm confused. This page [1] claims to be the "Linux kernel coding style" and it says "The limit on the length of lines is 80 columns and this is a strongly preferred limit". So he's reversing that without actually updating the guide? And without setting a new limit? He implies maybe "100" is a good limit but maybe "142" is even better? Weird. I know he's primarily talking about terminal output not code, but he implie…

I believe they are talking about existing code - i.e. Linus does not want patches to re-wrap existing long lines just to get them under 80.

For new code 80 columns is still the recommendation, unless this discussion causes that to be changed.

Post reply on HN