Hacker News Reader

Comment by nulagrithom | Hacker News Reader

> I don't like excessively long lines of code (120+ in most languages)

Quick straw poll on this... How many people like a line length limit?

My personal preference is a fairly strict 80 (barring silly things like URLs), but I've always been met with resistance to ANY line length limit. Is it really that imposing?

View on HN

I break lines if it looks like they’re getting too long, where it feels right to do so. Setting a fixed number of columns causes people to align hanging lines to the right in my experience:

  some_example_code = LongTypeName(argument_one=1,
                                   argument_two=2,
                                   argument_three=3)

(pretend that’s 80 columns), resulting in this mess when I try to look at it in a narrower view:

  some_example_code = LongTypeName(argument_on
  ↳ e=1,
                                   argument_tw
  ↳ o=2,
                                   argument_th
  ↳ ree=3)

Turning off word wrap doesn’t help, because then it’s an equally painful constant two-character scroll. What does help is creating indented blocks where it feels right, and letting other lines just naturally be long.

  some_example_code = LongTypeName(
      argument_one=1,
      argument_two=2,
      argument_three=3,
  )

  some_example_code = LongTypeName(
      "just a string that happens to be long; some people introduce acceptable percentages of string literals for long lines, but it’s really not necessary. let word wrap take care of it!")

(Plus: specific column counts depend on the size of your indentation.)

> What does help is creating indented blocks where it feels right

Over the years, I've come to believe that using a hanging indent for alignment is actually better in terms of readability as opposed to aligning at a column after the opening parenthesis, brace, or bracket. It's also easier to type as well even if the editor doesn't provide an auto-indent facility (or if it's not configured correctly for some reason) since you only have to press TAB the same number of times to correctly position each formal parameter in the function definition.

As a side benefit, it also takes care of any alignment issues regardless of whether one uses tabs or spaces.

> and letting other lines just naturally be long.

Using the language's feature for string concatenation still makes it as easy to read:

  some_example_code = LongTypeName(
        "just a string that happens to be long; some people introduce " +
        "acceptable percentages of string literals for long lines, but it's " +
        "really not necessary. let word wrap take care of it!")

Another benefit of doing this is that it makes a unified diff and side-by-side diffs easier to read. Contrast the wrapped version when I add another sentence to the end of your example:

  diff --git a/tmp/wrapped b/tmp/wrapped
  index 972537b..27e3e31 100644
  --- a/tmp/wrapped
  +++ b/tmp/wrapped
  @@ -1,4 +1,5 @@
     some_example_code = LongTypeName(
           "just a string that happens to be long; some people introduce " +
           "acceptable percentages of string literals for long lines, but it's " +
  -        "really not necessary. let word wrap take care of it!")
  +        "really not necessary. let word wrap take care of it! Though unified " +
  +        "and side-by-side diffs may be more difficult to read")

versus the unwrapped one:

  diff --git a/tmp/unwrapped b/tmp/unwrapped
  index 284ef1e..db47f46 100644
  --- a/tmp/unwrapped
  +++ b/tmp/unwrapped
  @@ -1,2 +1,2 @@
     some_example_code = LongTypeName(
  -      "just a string that happens to be long; some people introduce acceptable percentages of string literals for long lines, but it's really not necessary.  let word wrap take care of it!")
  +      "just a string that happens to be long; some people introduce acceptable percentages of string literals for long lines, but it's really not necessary.  let word wrap take care of it! Though unified and side-by-side diffs may be more difficult to read")

With the wrapped version, you can more easily see what I added to the end of the line in your example. In the unwrapped example, I most likely would have to either scroll horizontally to read the entire line. If the line is soft-wrapped, then I would have to realize that the second line is part of the previous line and not a different context line (soft-wrapping is simulated by hard-wrapping right after the "for long lines," comma and the space after "difficult to " based on how blockquoted text appears a rendered comment):

  diff --git a/tmp/unwrapped b/tmp/unwrapped
  index 284ef1e..db47f46 100644
  --- a/tmp/unwrapped
  +++ b/tmp/unwrapped_more
  @@ -1,2 +1,2 @@
     some_example_code = LongTypeName(
  -      "just a string that happens to be long; some people introduce acceptable percentages of string literals for long lines,
  but it's really not necessary.  let word wrap take care of it!")
  +      "just a string that happens to be long; some people introduce acceptable percentages of string literals for long lines,
  but it's really not necessary.  let word wrap take care of it! Though unified and side-by-side diffs may be more difficult to
  read")

> Over the years, I've come to believe that using a hanging indent for alignment is actually better in terms of readability as opposed to aligning at a column after the opening parenthesis, brace, or bracket. It's also easier to type as well even if the editor doesn't provide an auto-indent facility (or if it's not configured correctly for some reason) since you only have to press TAB the same number of times to correctly position each formal parameter in the function definition.

> As a side benefit, it also takes care of any alignment issues regardless of whether one uses tabs or spaces.

That’s exactly what I said.

> Another benefit of doing this is that it makes a unified diff and side-by-side diffs easier to read.

Until you rewrap and it adds noise to the diff. I recommend a combined word/line diff instead.

Concatenation also hides whitespace problems. Not a serious error, but a very common one.

  "This ends with a period." +
  "But this doesn’t start with a space."

I'm also at a fairly strict 80 (errm, 79 inclusive).

At work, I've managed to get a 99 column limit, with 79 columns for comments. But yeah, some people just don't like the limit. I like it because of monitor size/font size/distance from monitor/side-by-side editor windows. Autowrap doesn't cut it.

I don't get the 80 char limit at all. But then my display is 43" at 3810 pixels horizontally, so at my normal font size I would be able to fit, what, 7 or 8 windows side by side at 80 columns wide?

What don't you get about it? I can understand you having a different preference. That's normal, we all like different things. But not getting it at all? That's just weird.

I'll explain why for me. On my 24" 1920x1200 monitor, I want to be able comfortably fit two editor windows side-by-side where neither window auto-wraps the code. 79 columns works well for that. This is a function of my ability to read the text, which in turn is a function of font size, monitor size and viewing distance.

(I actually have many more horizontal pixels than you too, because I have three 24" 1920x1200 monitors. My center monitor typically is where my code lives, while my other monitors have other terminals open doing other things, like searching or compiling code.)

I suppose I phrased it badly - I meant I don't get why anyone would have a limit as low as 80 unless they're coding on an Apple II or a 10" netbook. But you fill your 24" 1920x1080 with 160 characters and change? That's like font size 18, just sounds huge to me. But hey, it's your display.

Also, I do quite a lot of numerical code where it's more important to me to line stuff up so that physical symmetries are reflected in the code, makes coding much easier and less bug prone. So I guess that also explains my bias.

But like you say, we all like different things.

I like an 80 column limit for C and python, but it starts to be a problem in C++. This says something about C++ and I don't think it's positive.

I actually also like a fairly small limit on the number of rows (around 40). If my functions and methods are too complex to understand in this much space then it's time to refactor. Of course, I usually have to work on existing code and the functions/methods are not always so compact.

I've often found that having all the code that's doing one thing in the same place is better than splitting it up into a bunch of functions just to keep rowcount low. It makes it easier to step through and reason about what is going on if all the steps of a logical sequence are actually laid out in a sequence (instead of intermittently jumping to other files). Whenever I find a function that I discover is only called in one place I just inline it, and in my opinion that improves the code every time. Abstraction is important, but understandability is more important.

The row and column limit is more of a guideline, not a hard and fast rule.

I render a column at 80 and rarely exceed it. Given that my font size is quite large, there's not much wasted space. A lot can happen in 80 chars though, especially in Clojure, so allowing 100, 120, or even more is asking for one-liners which are far too complex.

I prefer the 79 or 80 character line limit because it makes it much easier to read unified diffs pertaining to code changes. It also makes viewing files side by side much easier as well.

I think line limits are a good idea, though I sort of do them by feel usually. That said, 80 feels incredibly restrictive, a relic of bygone monitor sizes.

It's not just that, in fact the reason for limiting to 80 is mostly because short lines help readability because of how human eyes operate. Eyes prefer to stay within a small circular region located in the center of the visual field. Too much vertical or horizontal movement makes it harder to see, but vertical movement isn't an issue in text because of scroll, but horizontal movement is a problem.

Yes; see https://en.wikipedia.org/wiki/Line_length

This assumes that code should be read as prose. I posit that code should be skimmed, then the eye can track right if the code is relevant to the task at hand. This is all subjective, which is why I feel soft-wrapping is appropriate as it allows the coder to decide their preference.

Does anyone have rules that take into account indentation? I suppose too much indentation is its own issue, but seems like 80 could be flexible with your indentation.

I like 100 or 120 characters. I feel like 80 is far too restrictive, especially in “nesty” or “chainy” languages like JavaScript and Ruby. On a 30” display I can comfortably fit three or four columns at 100 chars in Vim.

I don't believe in hard limits, but if a line goes over about 120, I'll put its length under more scrutiny, to see if there's somewhere that it would make sense to split it. There almost always is, unless it's some kind of data table embedded in the code (or a long string).

I really don't care most of the time, mostly because I don't get long lines, and when I do ( like sometimes in tests I have a string that has some test data in it that's quite long ) I'm all good with it being long rather than wrapping.

I also will strictly use 80 character lines. I like that because it means I can have two vertical panes of code open at the same time even on my 12-inch MacBook (regular/not pro), which I love b/c of it's battery life and weight.

In python, 80 feels like reading a newspaper column. I use 4 spaces as an indent... with an indent for def():, try:, and couple if statements, I'm already 16 characters in.

Plus python seems to use super_descriptive_names_which_take_up_alot_of.space()

After years of Objective-C I don't blink unless a line is over 140 characters.

Some things just look better that way.

Ditto for C#. It's otherwise a fine language, but you're already 12 spaces into a line before you write any executable code (assuming tab = 4 spaces). 80 chars per line just doesn't work :-(

I just let them soft wrap.

Reply on news.ycombinator.com