4 ms·

The patch rejected by Linus is a good example why you want "long" lines: the argument list of a function was broken into two lines, with the second line only co

by _ph_ 5y ago

The patch rejected by Linus is a good example why you want "long" lines: the argument list of a function was broken into two lines, with the second line only containing a single function argument. While I can see that overly long lines can reduce readability, there is a lot of value in keeping function parameter definitions and functions calls in one line, if this line doesn't get overly long. We are not talking about written text like this comment here, but about program code, which has a very specific structure. For comment blocks, I try to stick to roughly 80 chars per line, but that then is text which can be broken up easily. For program code, I try to stay below 100 chars but exceptions can be made, if breaking up lines would be detrimental to the structure. With very complex function calls though, one would switch to multi-line breaking, sometimes with one argument per line (and a posssible comment). This discussion makes me wonder, why there are no editing modes with "smart" line wrap. As in being syntax aware when wrapping long lines. A function call which extends the set limit, like the 80 chars, could be automatically displayed as a multi-line call, properly indented. So independant of your terminal size, you could always see nicely looking code optimized for that terminal, without imposing your perfect view size onto others. Of course, this is easier to do with languages, which have a very strictly agreed upon code style. Go for example would make this easy, as all Go code usually gets autoformatted by gofmt. Lisp would be another language suitable for this, as the syntax makes this easy and overall code-formatting and indentation is pretty universally agreed upon.

bee_rider 5y ago
I write long lines from time to time, but only because I've messed up and made my subroutines into magical do-everthing monstrosities that need a million arguments. It seems to me that (while there are exceptions) the real problem is the existence of lines that want to be long, rather than things like whether the language supports line breaking lines inside a function call or whether your terminal has enough columns. It is unavoidable sometimes, but if we're trying to reduce the burden of figuring out what's being passed to a function, that would seem to indicate something has gone completely wrong on a deeper level.
raverbashing 5y ago
I would go further and advocate that the editor alone should do line wrapping as a viewing help. It would show up as smart and syntax aware wrapped code. But the actual code should be unwrapped. This would also cut down on format discussions.
janaagaard 5y ago
> The patch rejected by Linus is a good example why you want "long" lines: the argument list of a function was broken into two lines, with the second line only containing a single function argument. I would chop the arguments, putting a single one on each line.
- _ph_ 5y ago
  That would be a good alternative, especially if you use the space for documentation. I don't think there is one right way to do it, but certainly just wrapping arguments as if they were flowing text was the worst :)
  - necovek 5y ago
    Flowing text is almost never wrapped that way: I make a reference to handling of "widow" words above, and they're very undesired in typeset text. Getting to know those simple gotchas about where to avoid line breaking can help with both prose and code writing.
necovek 5y ago
In proper typesetting, "widow" words or lines are taken care of with fluid spacing and rewriting. It's a small science in how best to approach that, and you basically take the entire page/chapter into account to avoid them. Rewriting stuff to get rid of them is perfectly natural. I don't see why we don't care about readability to the same extent when programming. When typesetting code (which is what we are doing when discussing line limits), natural questions to ask are: 1. Why have a line length limit? 2. If there are reasons to have it, what should it be? 3. Should it be in characters or actual width? It seems that there's no (big) disagreement that we should have a length limit on lines in code. If you are disagreeing, none of the stuff below matters :) When it comes to what it should be, a limit of 80 has proven to be sufficiently long not to impede development, and is likely just good as any (you get benefits like multiple side-by-side-by-side windows on wide screens, yet you need to break lines more often; you need to factor your code more carefully to avoid too many indentation levels, yet you can't use sufficiently expressive symbol names....). If you decide on any particular limit (100? 120? 400?), you'll still have cases where you need to break up long lines. The tools argument (grepping and such) is thus rendered moot, because you've got all the same problems, just less frequently (and that's probably scarier, because it'll be easier to miss something when refactoring). Finally, the question of monospaced fonts is a curious one: unfortunately, I know of no code editor that works well with non-monospaced fonts, so I've never seriously considered not using them, but the only place where I truly care about fixed-spacing is indentation. And since that renders equally in non-monospaced fonts, I'd be willing to get rid of them too ;-)
- GoblinSlayer 5y ago
  In my experience proportional fonts look and work better than monospaced in all editors I use (including email clients, messengers, browsers, ebook readers, dictionaries, file managers). In general I would say anything you can say about preferences will be overriden by habit.

by _ph_ 5y ago

bee_rider 5y ago

I write long lines from time to time, but only because I've messed up and made my subroutines into magical do-everthing monstrosities that need a million arguments. It seems to me that (while there are exceptions) the real problem is the existence of lines that want to be long, rather than things like whether the language supports line breaking lines inside a function call or whether your terminal has enough columns. It is unavoidable sometimes, but if we're trying to reduce the burden of figuring out what's being passed to a function, that would seem to indicate something has gone completely wrong on a deeper level.

raverbashing 5y ago

I would go further and advocate that the editor alone should do line wrapping as a viewing help. It would show up as smart and syntax aware wrapped code. But the actual code should be unwrapped. This would also cut down on format discussions.

janaagaard 5y ago

> The patch rejected by Linus is a good example why you want "long" lines: the argument list of a function was broken into two lines, with the second line only containing a single function argument. I would chop the arguments, putting a single one on each line.

_ph_ 5y ago
That would be a good alternative, especially if you use the space for documentation. I don't think there is one right way to do it, but certainly just wrapping arguments as if they were flowing text was the worst :)
- necovek 5y ago
  Flowing text is almost never wrapped that way: I make a reference to handling of "widow" words above, and they're very undesired in typeset text. Getting to know those simple gotchas about where to avoid line breaking can help with both prose and code writing.

necovek 5y ago

In proper typesetting, "widow" words or lines are taken care of with fluid spacing and rewriting. It's a small science in how best to approach that, and you basically take the entire page/chapter into account to avoid them. Rewriting stuff to get rid of them is perfectly natural. I don't see why we don't care about readability to the same extent when programming. When typesetting code (which is what we are doing when discussing line limits), natural questions to ask are: 1. Why have a line length limit? 2. If there are reasons to have it, what should it be? 3. Should it be in characters or actual width? It seems that there's no (big) disagreement that we should have a length limit on lines in code. If you are disagreeing, none of the stuff below matters :) When it comes to what it should be, a limit of 80 has proven to be sufficiently long not to impede development, and is likely just good as any (you get benefits like multiple side-by-side-by-side windows on wide screens, yet you need to break lines more often; you need to factor your code more carefully to avoid too many indentation levels, yet you can't use sufficiently expressive symbol names....). If you decide on any particular limit (100? 120? 400?), you'll still have cases where you need to break up long lines. The tools argument (grepping and such) is thus rendered moot, because you've got all the same problems, just less frequently (and that's probably scarier, because it'll be easier to miss something when refactoring). Finally, the question of monospaced fonts is a curious one: unfortunately, I know of no code editor that works well with non-monospaced fonts, so I've never seriously considered not using them, but the only place where I truly care about fixed-spacing is indentation. And since that renders equally in non-monospaced fonts, I'd be willing to get rid of them too ;-)

GoblinSlayer 5y ago
In my experience proportional fonts look and work better than monospaced in all editors I use (including email clients, messengers, browsers, ebook readers, dictionaries, file managers). In general I would say anything you can say about preferences will be overriden by habit.