[HN Gopher] Linus on Line Breaks (2020)
___________________________________________________________________
Linus on Line Breaks (2020)
Author : belter
Score : 177 points
Date : 2021-11-28 17:17 UTC (5 hours ago)
(HTM) web link (lkml.org)
(TXT) w3m dump (lkml.org)
| TrianguloY wrote:
| As I think I said in a previous entry, I use line breaks to
| separate "logical" instructions, whatever length they have. This
| is very common with chains (like the typical
| split.filter.map.filter.join). This also helps with comments,
| because you can put a comment above the corresponding line of
| code. If the comment is long and involved multiples explanations,
| maybe you need to try to split the code into multiple lines, for
| example a function call where each parameter is something worth
| explaining. Other times the are a lot of syntactic useless code
| that is required only to wrap the important part (looking at you,
| Java) and often I split it so that the important part is the one
| on a separate line, something like: // Get the
| ids from the data var ids = object.stream().map(object->
| object.getName() + object.getType()
| ).distinct().collect(Collectors.toList());
|
| Word wrap is the one that automatically adapts the code to my
| screen, not the other way around.
| AprilArcus wrote:
| Shorter lines are easier for the eye to visually scan without
| accidentally skipping up or down during the leftward return
| saccade.[1]
|
| 80 characters happens to be just a little longer than the
| supposedly ideal measure for continuous text promulgated by
| Robert Bringhurst.[2]
|
| I take the even more draconian approach of wrapping to 72 columns
| when writing comments, after the fashion of PEP 8.[3]
|
| Of course, Linus will dictate the style of his projects'
| codebases as he deems fit.
|
| [1]https://en.wikipedia.org/wiki/Saccade
|
| [2]http://webtypography.net/2.1.2
|
| [3]https://www.python.org/dev/peps/pep-0008/#maximum-line-
| lengt...
| jagger27 wrote:
| > I take the even more draconian approach of wrapping to 72
| columns when writing comments, after the fashion of PEP 8.[3]
|
| Which also happens to be how Linus wrapped the lines of this
| particular email.
| SonOfLilit wrote:
| Plaintext email is wrapped to 72, that's in the RFC - Linus
| didn't have much choice there.
| rhn_mk1 wrote:
| Sure did:
|
| > Each line of characters MUST be no more than 998
| characters, and SHOULD be no more than 78 characters,
| excluding the CRLF.
|
| https://datatracker.ietf.org/doc/html/rfc5322#section-2.1.1
|
| https://www.arp242.net/email-wrapping.html
| coldtea wrote:
| That's for books.
|
| When reading code, I'd rather see a single statement on one
| line, rather that break it at 2 lines because it passed some
| ancient 80 char limit...
| nomercy400 wrote:
| Thank you. I was looking for this.
|
| I don't care if a line needs to be 180 chars if it starts
| with log.debug. Just like searching, I read my code globally
| based on the first 10-20 chars. If I need details on a line,
| I'll read the whole line.
|
| I do however put chained methods on new lines, because they
| are often a new statement.
|
| And I use 4 spaces for indent, because my IDE is smart
| enough, it is in my programming language guidelines, and
| that's what my comapny uses.
| d0mine wrote:
| "ancient" doesn't mean wrong. Round wheels are ancient, it
| doesn't mean we should switch to the square wheels.
| hsbauauvhabzb wrote:
| We also shouldn't burn people deemed witches at the stake.
| Being ancient doesn't make it right, either.
| mayoff wrote:
| And we all use 80-column wheels because that's what the
| ancients used, by Zeus!
|
| Oh wait, we use wheels sized for their use cases...
| coldtea wrote:
| > _Round wheels are ancient, it doesn 't mean we should
| switch to the square wheels._
|
| No, but it means we better use rubber wheels, not stone
| ones...
| cortesoft wrote:
| It doesn't mean right either, and the person you are
| responding to gave specific reasons why they prefer longer.
| kortilla wrote:
| So it's almost as if the "ancient" qualifier was useless.
| coldtea wrote:
| It was intended to mean "relavent in old times".
| cortesoft wrote:
| Well it was clearly meant to imply that the reason we are
| using it is merely tradition, and that there was a reason
| a long time ago that no longer applies.
| thow_away_soon wrote:
| I'd rather not have that statement more than 80 char long;
| that might be a one liner where many things are happening, in
| case there _is_ value is breaking it up, or maybe the
| variable names are too long, not helping readability.
| rocqua wrote:
| Long variable names can cause long lines.
|
| So can simple arithmetic that would be worse with
| intermediate values.
| coldtea wrote:
| Even PEP8 says "Some teams strongly prefer a longer line
| length. For code maintained exclusively or primarily by a team
| that can reach agreement on this issue, it is okay to increase
| the line length limit up to 99 characters, provided that
| comments and docstrings are still wrapped at 72 characters."
| indymike wrote:
| > it is okay to increase the line length limit up to 99
| characters
|
| PEP8 is strongly biased towards making code readable, and has
| helped a generation of programmers start thinking about
| readability when coding. The line length limit, though, is
| one of the few parts of PEP8 that introduced defects as a
| practice. Holding to 80 characters causes:
|
| * string concatenation bugs from breaking up long strings
|
| * errors in expressions broken up into multiple expressions
| just to fit
|
| * bias to use shorter variable names
|
| My favorite part of PEP8 was the warning about "foolish
| consistency".
| unixhero wrote:
| Are we supposed to be reading the PEPs?
| novok wrote:
| If you care about the reasoning behind whatever feature
| they are implementing.
| weego wrote:
| 1) has tenuous relevance at best
|
| 2) The 80 or 66 char or whatever is literally a non-science
| driven designer rule of thumb that's actually the opposite
| conclusion from results of actual research into the issue
| (granted it's not exactly a deeply studied niche but there is
| research).
| michaelcampbell wrote:
| These opinions about readability "flow" using numbered
| footnotes strikes me as the height of irony, but that's me.
| phil294 wrote:
| When "visually scanning" code, in 90% of the cases, only the
| first 10 characters matter anyway, so I fail to see your point.
| How often do you really need to grasp, say, all function
| arguments at once?
| Diggsey wrote:
| - Code is not prose. It's not read like a book so it's not
| clear that an "ideal measure for continuous text" is at all
| relevant.
|
| - Most lines are short even if the limit is more than 80
| characters, so you're unlikely to accidentally shift up or down
| after reading a long line.
|
| - Even if there turns out to be some benefit for reading code
| based on Saccades, that means nothing unless you can make some
| quantitative comparison with the other advantages and
| disadvantages of a longer line length.
| lgrapenthin wrote:
| Why does code have to be "read like a book" to be considered
| "continuous text"? Of course code is continuous text.
| throwawayboise wrote:
| For me it's not just the length of the line but the level of
| indentation. I think wide indents are good for readability,
| so if you're using standard tabs and also sticking to 80
| columns as a hard limit then you have only 64 characters to
| work with at two levels of indentation. Excessive indentation
| is a clue that you may want to refactor, but two levels is
| pretty common.
|
| 80 charcters starting at the point of indentation is more
| reasonable. At two levels of indenting, you might get out to
| 96 characters, which still fits comfortably in most GUI
| terminal windows.
| AlphaSite wrote:
| W is the bare minimum, it's a function and a conditional or
| loop, 3 or 4 is pretty common.
| xxpor wrote:
| The biggest problem with short lines isn't even the line
| length, it's that it encourages stupid variable names in
| order to keep things on one line. Silly abbreviations that no
| one new to the code can figure out are the bane of my
| existence.
| stephc_int13 wrote:
| Short lines (about 72 chars) are easier to read prose. But most
| code is tabulated, and is much less dense than prose.
|
| I tried a few different thresholds over the years and I finally
| chose 100 chars. It is a good compromise, wide enough to not be
| obnoxious and enabling long names.
|
| And still narrow enough to display two columns on a single wide
| screen when needed.
| timzaman wrote:
| Amen
| mkoubaa wrote:
| Now do cpython c source
| lostdog wrote:
| I do get tired of reading code that isn 't
| formatted in a clear way because the
| autoformatter is a slave to the column limit and
| especially in the case of 1. lists 2. instructions. 3.
| Other things that should line up--is overzealous
| in breaking up lines and making the code as unreadable as
| possible.
| andy_ppp wrote:
| It's amusing to me that the article body seems to be wrapped at
| 80 chars.
|
| I think all of this stuff is an art not a science but I'd rather
| people didn't go much over 100 chars, it becomes really difficult
| to read and I'd argue in most cases there should probably be
| descriptive names given to parts of a long line in the form of
| variables/constants. Maybe this doesn't apply to kernel
| development but I love to name things really descriptively rather
| than giving things short names or building clever one liners.
| mikojan wrote:
| Natural human language is taken to be the most legible at 9 -
| 12 words per line (in non-justified running text). Which is
| pretty much what you're seeing there.
|
| Plus, you're most likely not going to check this conversation
| in into git. And you're probably not going to pipe it into
| grep. :^)
| kstenerud wrote:
| I usually target around 120 characters as a right margin,
| allowing up to 130 before I start seriously considering a hard
| line break.
|
| Anything more than 140 or so and it gets harder to scan (too
| sparse). Anything less than 100 or so and it gets harder to scan
| (too dense).
|
| 80 is just painful.
| layer8 wrote:
| This is certainly subjective. I agree that 80 characters are
| often too constraining, but significantly more than 100
| characters is already difficult to scan for me. I find a limit
| of 120 to be too much; around 100 is the sweet spot.
| laurent123456 wrote:
| I feel that having longer lines means you can scan through a
| program more easily, by quickly scrolling through it vertically.
| Then once you're at the part you're looking for you can start
| scanning the text horizontally for more details.
| layer8 wrote:
| The problem is if you have to scroll horizontally. Either you
| have to size your terminal or editor window very wide, wasting
| space that could be better used for other components (project
| tree, debugging views, other inspector views, documentation,
| ...), or you can't see the complete line at once. IMO the
| maximum line length shouldn't be much more than twice(-ish) the
| median line length (not counting empty and brace-only lines).
| enriquto wrote:
| I feel as if I was a christian and God himself had just
| materialised in front of me and said that he doesn't exist, after
| all.
|
| An utterly confusing situation.
| kevincox wrote:
| I largely agree with this. However I also tend to have short
| lines. For example if a function takes more than a couple of
| arguments I put each on its own line. I like to keep a few number
| of "ideas" on each line, ideally one or two.
|
| What I don't worry about is long function names or similar. I
| won't wrap a line because a function name is really long or
| similar, as I think that doesn't generally add more complexity to
| the line.
|
| That being said I think soft-wrapping of code is very lacking.
| The best I have seen is matching the indent of the previous line.
| It would be neat if it preferred breaking on separate arguments,
| operators etc. I guess this is now moving to the realm of code
| formatters but now you are back to hard-wrapping which loses the
| info about the target screen size.
| tails4e wrote:
| I wrote some code (I'm an engineer) that ended up being the core
| logic of a HW driver that was linked to linux. One of the actions
| by the SW dev team was to reformat it to 80 chars wide. Made it
| less readable by a long way, even spilt up strings into multiple
| sections, if they heaven forbid, ran over the golden limit. They
| assured my it was a requirement to be upstreamed. It does not
| seem to be based on this, so who is pushing this 80 char
| standard?
| jonahx wrote:
| Linus takes a seemingly opposite stance when discussing word-
| wrapping commit messages:
|
| https://github.com/torvalds/linux/pull/17#issuecomment-56611...
| evilotto wrote:
| The main problem I often run into is not wrapping when reading
| code in an editor, but rather wrapping when reading side-by-side
| diffs, for example in a github PR or review board RB. You get not
| only double the code width, but also an extra 6 or so columns on
| each side for line numbers, plus margins and scrollbars; so
| 80-column text is really more like 180 columns wide that your
| window needs to be if you don't want any wrapping.
|
| On my typical developer laptop a full-screen terminal window
| (which I personally never use) with a system default 11pt font is
| 202 columns. A modest bump to 13pt drops that to 176 columns,
| meaning I can't view a side-by-side 80-column wide PR diff
| without some line wrapping.
|
| That's great that you have a 350-character wide display.
| Requiring everyone to have acres of screen space, either because
| they can afford a 34" monitor (or 2 24" monitors) OR because they
| have good enough eyesight to be able to use a microscopic font is
| excluding a lot of people.
| DreamFlasher wrote:
| Again a tooling limitation. Use github or horizontal diffs.
| kelnos wrote:
| I dunno; I don't use an external monitor, and code on a 1080p
| 13" laptop screen. At my normal font size, a full-screen
| terminal is 190 characters. That's fine; and I try to soft-
| limit my line width to 120 characters or so.
|
| Personally I don't like side-by-side diffs; I'm fine with
| unified diffs, so I guess I don't run into that problem.
|
| But still, I recognize that nearly everyone else I know codes
| on a larger monitor (you can get a decent, but not great, 27"
| monitor for $300 or so) with much more horizontal space, and I
| wouldn't ask them to cater to my small-screen preferences.
| lytedev wrote:
| Look at your diffs in horizontal splits?
| alisonkisk wrote:
| How? Rotate the text 90deg?
| evilotto wrote:
| AFAIR, not an option for RB.
| xxpor wrote:
| Adding horizontal diff support was the single thing that
| made me happy when my company got rid of RB.
|
| I can't believe that in 2021 they still haven't added it.
| xdennis wrote:
| Linus is making the typical bad faith argument that people use 80
| char limit because of hardware limitations.
|
| No one has ever advocated 80 because of hardware limits. Hardware
| has progressed but our eyes haven't.
|
| In prose, shorter lines help because you can easily go to the
| next line.
|
| For programming, shorter lines help because you can navigate your
| function better because most of what you're tracking is in a
| smaller area. With long lines you have to move your eyes more.
|
| Shorter lines also force you to write one param per line when
| calling a function. No one is saying you need to mk yr vrbls
| shorter.
| emsy wrote:
| Nesting exists, and 80 is an arbitrary number.
| xdennis wrote:
| Every number is arbitrary. 80 is often used simply because
| it's in the right ballpark and already used by many who agree
| on short lines.
|
| People who like long lines have no main limit they agree on
| and if a line limit does exist, it often varies by project...
| making it even more arbitrary.
| danachow wrote:
| The main argument is that it's not in the right ballpark
| though - which has no universal correct answer. However at
| this point 80 is not arbitrary - It's primarily used as a
| default because of ancient history when 4k let alone 640k
| was enough for everybody. A time when the expense of
| expanding a meager terminal buffer 50% was hundreds of
| dollars - and this goes back to ancient history of 80
| column punchcards.
| numlock86 wrote:
| Doesn't Linus also regularly argue that you shouldn't nest
| deeper than like 3 or 4 levels?
| kyralis wrote:
| > Shorter lines also force you to write one param per line when
| calling a function.
|
| And this is unconditionally good why?
|
| Linus isn't wrong when he describes lines as a natural unit,
| already operated on by our tools and our brains. Having to
| stitch multiple lines together has its own mental cost.
|
| Is a longer line always better? Definitely not. There are
| absolutely cases where an expression split over multiple lines
| and well-indented can make code much clearer. There are also
| cases of the inverse, where you have to take a single atom that
| was split across multiple lines and re-integrate it while
| reading. (The patch that Linus is referring to here has some of
| these.)
|
| Line length should be driven by some combination of total
| character width and expression cohesion.
|
| A single line can be overly complex even far below an 80
| character limit, and a single line well above that limit can
| still be easy to read.
|
| Prose, and therefore comments, have different reading patterns
| and therefore different motivations for line length. You want
| to limit comments and documentation to 80 characters? Fine.
| Code? That's valuing one metric over another, or simply hoping
| that strongly clamping one metric is going to also improve
| another.
| rendall wrote:
| > _Linus is making the typical bad faith argument that people
| use 80 char limit because of hardware limitations._
|
| Disagreement does not mean "bad faith".
|
| The character limit is 80 because of hardware. The argument for
| using 80 characters is not "use short lines because it's easier
| to read". It's not "use 85 characters if it increases
| readability and understanding". It's "80 characters is a hard
| limit and if you go over we're gonna wrap or truncate"
|
| Yes. It is 80 and not another number only because of hardware
| and history. It has never been about readability.
| layer8 wrote:
| Arguably, the hardware was designed to support an adequate
| and sufficient line length.
| [deleted]
| marcus_holmes wrote:
| This reminds me of the thing with musical albums.
|
| Albums are the length that they are because of the technical
| constraints of the medium: you can only fit so many tracks on a
| vinyl disk.
|
| However, this constraint has been adopted by musicians as a
| creative constraint - an album is a "feels right" amount of
| music for an artist to produce. You can tell a story in an
| album, fit a narrative arc in that much space.
|
| But, y'know, sometimes you need a double album to tell the
| story properly. Some stories need more room.
|
| I like 80 lines as a guideline. It feels about right, and fits
| my eyeballs. But I'm not going to let that stop me if I need
| more space. Some code demands more space.
| waynecochran wrote:
| Also you have to view code in multiple contexts and sticking to
| 80 characters per line allows it it be viewable in more places.
| For example, I like to look at the diffs in github and it is
| more flexible to read in a web browser if kept to 80 chars.
| kstenerud wrote:
| I used to be an 80 char zealot, but since working in 100 and
| 120 char codebases, I've seen the light. Such line lengths make
| it MUCH easier to scan the code because we are able to scan
| that much without moving our eyes around a lot, and now it's
| not so cramped.
|
| One param per line of a function call is bad for readability
| (unless there are more than four params).
| orwin wrote:
| 100 is my sweet spot, unless i do Java/groovy and in this
| case i'd rather have 120. I still like 80 char
| comments/docstrings though.
| ok_dad wrote:
| The best world would be if every language had a decent formatter
| so everyone could view code as they wish and it was checked in at
| some standard width for a company. Or, a world where git didn't
| see a formatting change as a code change if there were no change
| in logic; where it sees the AST rather than the textual content.
| Then, I could use whatever width I want and you can use your
| preference, and neither of us have to care about the others
| settings.
|
| Go further, and you could even have a file to map one or more
| variables to a different name, so that is someone prefers
| "avg_val" and you prefer "average_value", then you could both see
| the different name, although that starts to get dangerous as you
| discuss the same code with different syntax but the same
| semantics.
| _ph_ wrote:
| 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 wrote:
| 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.
| janaagaard wrote:
| > 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_ wrote:
| 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 :)
| raverbashing wrote:
| 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.
| JustSomeRando4 wrote:
| Linus' position is one of privilege and he's an asshole. He's
| saying that if you're too poor to afford a wide screen then fuck
| you. That position works well for rich people, and is not
| something that should be tolerated in open source.
|
| If you're using grep on your source that much, you're throwing
| away all of the benefit of modern compiler tools to provide
| symbol info.
|
| Basically, fuck off Linus.
| r-bryan wrote:
| I dunno. Don't we have yet to resolve where the curly braces
| belong, or emacs vs vi, or mac vs pc, or red sox vs yankees, or
| at least what materials to use for the staff bikeshed?
| kazinator wrote:
| Well, Linus needs the extra width for his 8-space-hard-tab
| indentations. At least in all the situations when he breaks his
| own rule that you shouldn't indent more than two or three times,
| but write functions instead.
|
| Kernel coding style guide:
|
| "Now, some people will claim that having 8-character indentations
| makes the code move too far to the right, and makes it hard to
| read on a 80-character terminal screen. The answer to that is
| that if you need more than 3 levels of indentation, you're
| screwed anyway, and should fix your program."
| shmerl wrote:
| I also don't like excessive line breaks and prefer longer lines.
| No way 80 is a good idea. I'd say even 120 is too short.
|
| So what is the recommended style for line length in the Linux
| kernel?
| prpl wrote:
| My personal guide boils down to this:
|
| 100 soft/best effort limit, 120 hard limit (with exceptions), 150
| absolute limit (rarely used), 72 limit for docs/comments.
|
| Auto-formatters usually set to 120.
|
| More than 120 does come up, but very rarely - e.g. long URLs in
| documentation.
| tyingq wrote:
| Curious if 132 characters per line would work for most people.
|
| I don't mind going past 80, but would still want some de-facto
| standard, and there's a fair amount of precedent for 132.
| [deleted]
| evilotto wrote:
| Based on experience and experimentation, I advocate 110
| characters as a hard limit (i.e., would reject a change based
| on line length alone) and 90-95 as a good guideline.
|
| The rationale for the 110 is that above that you cannot avoid
| wrapping in a side-by-side diff on a reasonable
| screen+font+layout. 90 is where you should be asking yourself
| "is this cleaner to split across multiple lines?" and still
| allowing some headroom to make minor changes without needing to
| reformat things.
|
| There are of course some things where it is impossible to
| constrain things to shorter lines (e.g., markdown tables) but
| those are definitely the exception.
| layer8 wrote:
| Agreed, personally I find 120 already too much.
| anon9001 wrote:
| What's the 132 precedent?
| throwawayboise wrote:
| Back in the day some terminals had a choice of 80 or 132
| column modes. Since obviously the window (screen) didn't
| change size, this was achieved with a narrower font.
| CSSer wrote:
| Monospaced, right?
| cogburnd02 wrote:
| yes, but using fewer horizontal pixels.
| rjsw wrote:
| You used to be able to run old terminals in either 80 or 132
| column modes.
| chungy wrote:
| GNOME Terminal's four presets are: 80x24, 80x43, 132x24,
| 132x43
|
| I always kind of figured "132" was some arbitrary
| programmer decision, never knew it dated to old terminals.
| At least I recognize 24 and 43 as the number of lines old
| text modes (on, eg, VGA) had.
| egberts1 wrote:
| Ahhh, the good ol' DEC VT-240 CRT.
| cogburnd02 wrote:
| This.
|
| I know the DEC VT340 was capable of 132 columns, as was an
| Apple II with a Videx Ultraterm card and a suitable (hi-
| res) monitor.
|
| There are probably even more examples, but those two are
| what came to mind first.
| upofadown wrote:
| Many line printers back in the day did 132 columns. As a
| result the popular DEC VT-100 had a 132 column mode to allow
| proper viewing of the output of programs without having to
| waste paper. It wasn't that great and was sort of hard to
| read.
|
| As part of VT-100 compatibility, many subsequent terminals
| also supported 132 column mode.
| tyingq wrote:
| Others have mentioned printers and older terminals that
| supported 80 and 132 column modes. That bled into other
| things. Like, for example, Gnome's terminal app has a couple
| of 132 column settings as selectable presets. Also, the
| framebuffer/vga console in Linux (and probably other OSes)
| can be set into a 132 column mode. It's an official "VESA
| mode" also.
| tooltower wrote:
| Maybe add "(2020)" to the title?
| shrimpx wrote:
| The asinine argument at the heart of that rant is that we should
| format our code so it's more greppable. Let's not consider making
| a better/semantic grep that can match code. Let's all instead
| insert strategic line breaks in our code so that the current grep
| sort of works on it.
| ianbicking wrote:
| Semantic line wrap serves the same purpose, and can be done at
| any line width when viewing.
|
| Even the simplest improvement in line wrapping of maintaining
| the leading indent is pretty much enough. Once I started using
| Atom and then VS Code, which both do this, I pretty much
| stopped worrying about line length except when it was
| semantically confusing (like many arguments to a function where
| I use newlines to separate the top-level arguments from the
| expressions).
| dathinab wrote:
| > for things like "grep" both in
|
| I don't think using grep is a adequate development technique in
| 2020.
|
| > "80-column terminal"
|
| Sure but code breaching idk. ~120-200 Lines is still supper
| annoying and much harder to read.
|
| > checked, and my main one is 142x76 characters right now,
|
| Which brings us back to the 120-200 Line length limit.
|
| Given that most IDEs have some side panels 150 Lines should be
| the max. instead of 200.
|
| > 80x25 is really really limiting, and is simply NO LONGER
| RELEVANT
|
| True, it's now 120-200x~50 but nice scrolling so it's more like
| x100+.
|
| > 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.
|
| I would go as far and say it's recommended, auto-completion is a
| thing and typing speed should never be your limiting factor (*).
|
| > we do use wide tabs,
|
| Is that 4 or 8 spaces?
| worik wrote:
| grep rocks. Still.
| Zardoz84 wrote:
| I follow the rule of 80/120. 120 wide chars as the hard limit. 80
| wide chars as a soft limit that I not should surpass.
| jefftk wrote:
| Most of my professional life has been 80 columns, two spaces for
| indentation, and an auto formatter. I love it: on a 27" monitor I
| can have four 81-column terminals side by side, with room for a
| fifth column wide enough for commands. Being able to see many
| parts of the codebase side by side is incredibly useful.
| e_proxus wrote:
| I'm in the same boat. I'd rather have more views than longer
| lines. Currently have a file tree, three editor columns and one
| terminal column.
|
| Keeping to a shorter line width makes me write shorter
| functions with less nesting. In my opinion that leads to higher
| quality code which is more readable (your mileage may vary, I
| write Erlang which is very terse and expressive which fits that
| style very well).
| nixpulvis wrote:
| Didn't people in the news-printing business eons ago do studies
| on large lines and readability? Why else are there multiple
| columns in so many papers? Does anyone have a good reference for
| this? Personally, it makes sense to me, since I start to get lost
| reading long lines.
|
| Plus the whole modern hardware comment is not well founded, since
| I like to put some monitors in vertical orientation.
| IshKebab wrote:
| I don't think you can extrapolate from prose, in which line
| breaks are meaningless, to code which is clearly very
| different.
| [deleted]
| keymone wrote:
| https://mksm.dev/blog/2019-11-24__case-for-80-rule/ with some
| references
| niccl wrote:
| I have no reference for this, but I understand that a
| significant limitation in the news print industry would be what
| the Linotype machines could produce. They literally produced a
| Line-Of-type, cast in lead. You couldn't practically manage
| slugs of lead that are much longer than the typical newspaper
| column width, and so they ended up the width they are.
|
| And prior to Linotype, there would have been practical
| limitations to the forme size that could be easily managed and
| quickly re-set to fix typos.
|
| So I don't think the newspaper column width was the result of
| centuries of experimentation into readability. It Just
| Happened. (Same as the gauge in railways)
| kevin_thibedeau wrote:
| They were concerned about the ease of editors and typesetters
| making revisions. You can reformat shorter lines with less
| effort. It also affords more opportunity to insert ads.
| kstrauser wrote:
| Code is drastically different from prose, as code has _a lot_
| of repetition. For example:
| some_long_variable_name = 42 new_value =
| description_function_name(some_long_variable_name)
| do_something_with(new_value)
|
| All of the above has 5 unique tokens, several of them repeated.
| Unless you're using lots of global variables, most of those
| tokens will be scoped entirely within that function, so you can
| also infer an awful lot of meaning just from the context.
| Glavnokoman wrote:
| "Plus the whole modern hardware comment is not well founded,
| since I like..." That is exactly the essence of Linus comment.
| If some people choose to do something that does not mean the
| rest needs to accommodate. 80 chars limit is just ridiculous in
| 2021.
| leetrout wrote:
| I dont think its that cut and dry but i find 120 which got
| popular with githubs viewable columns to be pretty great.
| BoardsOfCanada wrote:
| But remember that it's a huge difference between reading
| compact text in a newspaper or book compared to reading source
| code. I don't remember get lost reading long lines in source
| code ever but it happens regularly to me when reading books.
| riversflow wrote:
| One of my favorite parts about reading on a computer is that
| I can highlight text with the cursor as I read it. Just
| dragging down a line at a time while reading means I
| virtually never lose my place while reading even very wide
| format text on a computer.
| tzs wrote:
| I do a similar thing when reading paper books using a
| digital system much older than computers.
| valevk wrote:
| https://reddit.com/r/linusrants for a few more Linus stories
| raverbashing wrote:
| Nothing but coming sense and I'm surprised I didn't didn't read
| this first. I fully agree and I'm surprised he would advocate
| that even for kernel development (where sometime you do need to
| work whichever the basic terminal format is, right after boot)
| viktorcode wrote:
| I mean, should I write very long comments now packed into a
| single line? That's silly.
| kaonashi wrote:
| Not the first time he's been loudly wrong. It really depends on
| the semantics of the code in question and not on the absolute
| line length anyways. I've seen 30 character lines that are hard
| to parse, I've seen 120 character lines that I don't really think
| about at all.
| halayli wrote:
| Getting used to a new style is like wearing new shoes. It takes a
| day or two to break in, before it feels natural.
|
| Most arguments can be translated to "because I like it this way".
| layer8 wrote:
| There's nevertheless a bell curve. Hardly anyone would argue
| fir a 1000-character line limit.
| halayli wrote:
| Definitely. I thought I mentioned the "within reasonable
| boundaries(80->150)" and evidently I have not.
| devit wrote:
| It's surprising to me how software developers, supposedly very
| rational, cannot come to the obvious conclusion that the correct
| coding style is to have unlimited line length and using tabs for
| indent.
|
| The reason that's the best choice is that it's the approach that
| provides logical data rather than a specific visual style,
| allowing people can just configure their editors to do word
| wrapping to whatever line length they prefer and set tab width to
| whatever value they prefer (including fractional values!), so
| it's strictly better than all alternatives.
|
| And if someone doesn't like the editor word wrapping, they can
| always write an extension or patch for the editor to wrap in
| whatever syntax-aware way they want.
|
| Also, while for some other bizarre reason it's traditional to
| program with monospace fonts, there is in fact no reason at all
| to use them instead of the more efficient proportional fonts, and
| if you use proportional fonts the concept of a length limit is
| meaningless.
| shrimpx wrote:
| I'd say your maximalist view is not maximal enough, by
| requiring tabs. Why not store code in the most minimal way
| possible (one-liner, no whitespace [assuming whitespace-
| insensitive languages]) and let viewers and editors wrap and
| indent it however they want.
|
| That aside, I'd say the reason your vision is not achievable
| today is due to lack of great view/edit tools.
| klabb3 wrote:
| Thoughts:
|
| - prose and comments are greatly improved with shorter lines (I
| switched to reader mode to read the post)
|
| - a logical code line often exceeds optimal prose length (70-80),
| due to indentation, syntax, language idioms etc
|
| - code is more sparse and _much_ less visually homogenous than
| prose, which means code can have longer lines without causing
| "staccation return issues"
|
| - it is technically easy and non-destructive to auto wrap in-
| editor for display output (long source -> shorter display)
|
| - it's ambiguous and hard for an editor to "unwrap" (short source
| -> longer display)
|
| - grepping source works better with less wrapping
|
| - diff tool UIs seem to struggle with long lines, today
|
| - some single identifiers are commonly longer than 80 - such as
| URLs
|
| - comments and code doesn't have to have the same max length
|
| Linus got it right in this case imo. In the future, I'd be
| curious about ubiquitous and standardized auto-wrapping in
| editors so that you can set whatever length you damn please
| without imposing it on everyone else.
| kazinator wrote:
| I just calculated the 90th quantile of line length over the TXR
| project, for all the C, Lisp, Lex and Yacc sources:
| 1> (let ((q (quantile 0.9))) (each ((l (flow "git ls-
| files '*.c' '*.h' '*.tl' '*.y' '*.l'"
| command-get-lines open-files
| get-lines))) [q (len l)]) [q])
| 63.9840684046716
|
| The project follows two character indentation except in one
| inherited source file and its header.
|
| The 99th percentile: 2> (let ((q (quantile
| 0.99))) [ .. SNIP ] [q]) 78.9882857548558
|
| Of course, that's skewed by the internal pressure to stay within
| 80 columns.
|
| When we go to the 99.99th percentile, things take a bit of a
| leap: 3> (let ((q (quantile 0.9999))) [ ..
| SNIP ] [q]) [q]) 104.790549931036
|
| Still, that shows us that long lines are quite rare. Probably the
| column limit set by the 99th percentile is reasonable from this
| perspective.
|
| Moreover, if we want to be quite generous, we don't have to add
| too many columns. 105 characters will only break 1 in 10,000
| lines. Something can almost certainly be done about those. Or
| these outliers have something wrong, like being accidentally
| joined or something.
|
| --
|
| Let's tidy up the code, by eliminating the _each_ iteration with
| _mapdo_ : 1> (let ((q (quantile 0.9999)))
| (flow "git ls-files '*.c' '*.h' '*.tl' '*.y' '*.l'"
| command-get-lines open-files get-lines
| (mapdo (opip len q))) [q]) 104.790549931036
| zamadatix wrote:
| As you note towards the middle I think you're just measuring
| that code styles traditionally limit to 80 columns not that 80
| columns was really the natural 99th percentile of freeform code
| lines. Similarly I don't think that shows 104+ character lines
| are really 1 in 10,000 it shows 1 in 10,000 lines weren't yet
| refactored to fit into the 80 columns per line standard.
|
| I'm all for >80 column wide lines I just don't think these
| stats really tell us anything about it other than 80 column
| lines have been the standard in the past.
| powersnail wrote:
| Does this account for blank lines?
| kazinator wrote:
| No; we can introduce a (remqual "") element or similar to the
| (flow ...) pipeline after get-lines to achieve that. The
| numbers become: 66.06, 79.61, 105.89. Different, but not by
| much.
| oblak wrote:
| I remember when this was posted. I agree with Linus.
|
| Most monitors have been wider than taller for many years. Yet,
| people insist on putting silly horizontal task bars up and down,
| thus making the problem even worse.
|
| My mind is blown on an almost daily basis when some of our junior
| developers shares their screen with me.
|
| Two of them consistently have:
|
| 1. horizontal task bar
|
| 2. display scaling set to 125% or worse (1080 native)
|
| 3. a terminal launched from VSCode (whaaaaaaaaaat) they leave on
| the bottom
|
| That setup leaves them with a total of 30 lines of code.
| Literally more than 50% of their desktop remains unused most of
| the time. I don't want to force my opinions on them but stuff
| like this takes its toll and triggers my OCD. Only it's not an
| OCD, I just can't see shit
| ChuckMcM wrote:
| You'd hate my display which is often in 9:16 mode :-)
| pjerem wrote:
| 1) Like 100% of the people whose upgraded to Windows 11 since
| it's now mandatory. 2) Nobody's does scale up for for fun. It's
| to be able to see what's written. Especially when it means
| getting under << 1080p >> real estate. 3) Terminals in IDEs are
| buggy (at least VSCode and JetBrains). Vertical terminals in
| IDE are _super_ buggy. But terminal in IDEs are integrated with
| your current workflow. So you are basically saying that they
| should not use an IDE and ... it's an uninteresting debate.
| cmauniada wrote:
| Genuine question: What's wrong with 3?
|
| I mostly don't need my terminal after getting docker up and
| running, and if I just want to view the output, I can always
| open it (Control + V).
|
| And I usually have vscode and chrome open.
| codesections wrote:
| > What's wrong with 3?
|
| You may have missed the "[that] they leave on the bottom"
| part of 3. It sounds like you don't leave your terminal
| open/visible unless you press ^v
| marcosdumay wrote:
| If you leave it there, it eats vertical space.
|
| I usually don't like IDE terminals, they don't do anything
| that you can't do in a real terminal, but comes with all
| kinds of problems that wouldn't be accepted on a single
| purpose program. But that's my preference, yours is fine too.
| The only real problem is leaving stuff eating up a portion of
| the screen when you are not using.
| elcomet wrote:
| What's wrong with 2? People can have troubles to read small
| text..
| _kulang wrote:
| It's the default on many laptops and is often completely
| inappropriate
| jraph wrote:
| > 1. horizontal task bar
|
| I use an horizontal task bar, out of habits and default
| parameters, I guess. However, I considered putting it on the
| side, haven't tried it seriously, but I do like having the
| title of the tasks and that would probably not be so
| comfortable vertically.
|
| There are only so many lines of code my brain can handle anyway
| and I don't think the screen height is not the bottleneck.
| wlll wrote:
| I have my task bar autohide and haven't used it in years.
| Seriously, I never see it. Between cmd+tab and Alfred to
| launch apps it's just redundant.
| moogly wrote:
| 3. VSCode has the ability to interact with the console (for
| example automatically attach a node debugger whenever you run
| something calling node in that console), so that shouldn't
| necessarily automatically be scoffed at.
| rocqua wrote:
| Horizontal task bar takes up much less space.
| xxpor wrote:
| If they're on a 1080p monitor, agreed scaling shouldn't be
| needed, but anything above 1440p (unless the monitor is
| absolutely enormous) really does need to be scaled at at least
| 125%. Otherwise you'll get closer and closer to the monitor to
| read it without even realizing it
| Zababa wrote:
| > 1. horizontal task bar
|
| That's something I honestly never thought about. I'll try it on
| the side for the next week, thanks for sharing the tip!
|
| > 2. display scaling set to 125% or worse (1080 native)
|
| Be grateful that your vision is still great I think. I have
| Hacker News on 125% because it's hard to read for me when it's
| smaller than this.
| axegon_ wrote:
| I completely agree with this. I am considering an ultra-wide
| monitor(the only thing really missing from my home setup at this
| point) but even at a 1920x1080 on all my monitors, 80 characters
| occupy at most 25-30% of my entire screen. The rest of the screen
| is just sitting there, being all "OK, black pixels all day long,
| gotcha boss". 130-140 characters is perfectly usable for any
| 1920x1080 screen which is what most people have. My old laptop is
| 13 inches fits those perfectly and still leaves plenty of unused
| space, even in the context of an IDE where you have your
| directory structure on your left for instance. Not to mention
| something like vim where a vertical split would still leave
| plenty of space laying around. I think most standards need to be
| updated and ditch the whole "Someone is using an 800x600 CRT
| monitor and they need to be able to work". I am sorry, no, I used
| to have such monitor in the 90's as a child from eastern Europe
| in an average income family. 2021, I cannot name a single
| developer with anything less than HD. People should seriously
| wake up and revise those standards-they are the equivalent of
| wearing the same underwear for 30+ years. Even side by side diffs
| work perfectly fine in those scenarios. 3 way diffs might be an
| issue on a 13 inch laptop but honestly I don't know anyone who
| actually likes working with those(one notable exception but I'd
| definitely disregard his opinions on anything to be quite
| honest).
|
| Side rant, I have a lot more issues with people writing functions
| that are 500 lines long and contain 10 individual sets of logic
| which would make sense to be fragmented in different functions.
| As a matter of fact I had a fight over this at my now old job.
| Ideally the body of a function should fit in one screen: ideally
| 60-80 lines. In fact there is a study on the subject described in
| "The Psychology of Computer Programming" [1]. If it's something
| larger, in 90% of all cases you can segment your logic in a way
| which allows one component to be responsible for one specific
| thing and take that out in a separate function. With good naming,
| this makes the code infinitely easier to read 6 months down the
| line when you have to figure out what someone else or even you
| have done. The argument I got was "Well what if I have an ultra-
| wide monitor set up vertically, then it's not a big deal?". Fffs,
| are you stupid??? What if I start coding on my 4k projector and I
| can fit 1000 lines in a single screen? Fetch a vector from one
| place, iterate over it, populate a hashmap, compute some standard
| deviation, save a backup on disk, check the bounds of the values,
| store them somewhere for future reference and call an async
| function to a message queue, check if a set of conditions are met
| and have 8 different fragments of code handling those based on
| the conditions that were matched. Function name:
| fetch_history_data. There's a lot more than fetching history data
| in there now, isn't there? End of rant, I think I had to get it
| out of my system.
|
| [1]
| https://www.goodreads.com/book/show/1660754.The_Psychology_o...
| throwawayboise wrote:
| I basically agree. There is a point where lines get "too long"
| but it's more than 80 (or 72) characters on modern systems.
|
| But if I'm working in a code base where all the lines are broken
| at <80 characters, it makes sense to stick with that rather than
| introduce inconsistent formatting.
|
| Bottom line, your brain will adapt to either style without a lot
| of fuss, and consistency helps.
| novok wrote:
| The linux kernel doesn't have an autoformatter script that stops
| stupid conversations like this, where certain code files can look
| different than others?
|
| One of the most productive policies you can do to a company is
| make autoformat mandatory and move formatting discussions from
| specific commits to discussions about the formatting rules
| themselves. If you want to make a change in formatting, you have
| to write a rule to make it done automatically at the very least.
| quocanh wrote:
| THANK GOD. This convention has always annoyed me especially in
| cases where I was told to shorten variable names (sacrificing
| readability) or where a line of code was clearly more legible
| even up to 120 characters. Finally, I can point out that there is
| a Linux wizard out there that disagrees.
| taftster wrote:
| I liked this response in the thread related to blind contributors
| and braille displays.
|
| https://lkml.org/lkml/2020/6/5/685
|
| To summarize, this blind user at least doesn't consider
| 80-characters max width to be a supportive argument. They are
| more worried, instead, about matching up the terminal width to
| multiples of their display. And of course, to avoid forced guis.
|
| Sometimes I think it's easy to make arguments about accessibility
| without actually consulting someone with an accessible need.
| kstenerud wrote:
| You should also read the response to the response. This is not
| an issue.
| quelsolaar wrote:
| This needed to be said! What bothers me most about the 80
| character mafia is not just the line-breaks, but also the
| insistence on short cryptic variable and function names. Good
| code is wide code.
| geerlingguy wrote:
| Good code can be wide code. Doesn't have to be.
|
| And code editors are decent at wrapping lines nowadays, if you
| like it.
| worik wrote:
| adjustFooSOItFitsIntoTheSpaceAvailableIfNeeded
|
| What gets me is long verbose names.
|
| noun-verb. Short names. They are mnemonic not descriptive
| d0mine wrote:
| A docstring can be used instead of making a many-words
| sentence-long name.
|
| IDE can show it automatically when you focus on the name in
| the source code.
___________________________________________________________________
(page generated 2021-11-28 23:01 UTC)