Announcement

Collapse
No announcement yet.

The Linux Kernel Deprecates The 80 Character Line Coding Style

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    We use 120 at work, but we are not doing kernel Dev stuff. For the most part it works, HTML can got crazy with indention though.

    I was toying of making a TUI CSS thing, and if you take 80 x 8px (char width of an old IBM PC), you get 640 px wide. 120 gives you 960px. If you have worked in the web, 960 px was the defacto max width you should target. 130 would give you 1040 px. This might be too wide for most IDEs IMHO.

    Comment


    • #32
      But when resolving merge conflicts with vimdiff ( 4 windows ) on my 1080p phone it only shows 24 char/col + line numbers, guess I'll keep scrolling.

      Comment


      • #33
        The morons saying "haha, back to the '80s with ye" are missing the point. Even the VT102 supported wide (132x24) mode.

        Comment


        • #34
          Originally posted by kravemir View Post

          Why 120 chars would be better? Does kernel code contain very long variable names, or functions with lots of arguments?

          They have 8 character indentations... Also 120 is always better
          Last edited by carewolf; 31 May 2020, 06:18 PM.

          Comment


          • #35
            Driver dev here. When I joined a long long time ago, the sensible motivation I was told for the 80-character limit is that if you messed up a change in your graphics driver, and you lose modesetting as a result, you can still have a stab at fixing your code on your VT in vim/emacs/... Longer lines would make that endeavour a lot more painful. Rebooting into an older kernel has become a lot less time-consuming over the past 10-or-so-years, so perhaps it is time...

            Comment


            • #36
              Originally posted by atomsymbol
              Is the Linux kernel using automatic C code formatting similar to gofmt/rustfmt?
              No. There are no code formatting tools for C that aren't complete garbage.

              clangfmt exists, but it completely mangles struct initializers and line continuations, with no sane way to configure it.

              Comment


              • #37
                Originally posted by Raka555 View Post

                It is actually people that are getting dummer over time.
                The average sentence length was over 60 in the 1500's and kept declining over time.

                "Modern" humans get a cognitive overload when you go past 14 words in a sentence today:
                (It is probably even shorter than that today)


                https://medium.com/@theacropolitan/s...s-2e40f80f589f


                No wonder the poor programmers can't cope with added cognitive load of manual memory management on top of that today...
                Conversely, you could posit the ability to write has spread to the masses, not something that was true of the 1400-1500's. Reading and writing in that age was left up to the educated, i.e. nobler, wealthier classes. As the availability of the printed book became cheaper, the ability to publish became cheaper and could thus be afforded by those with less prestige. This has continued to today, when the majority of the population is able to publish for effectively nothing.

                Comment


                • #38
                  This is a good thing. As long as there are reasonable attempts to keep line length manageable. Linus is right in the sense that line breaks just make the code a mess to read.

                  what we don’t need is line length that would make CMakes command line embarrassed.

                  Comment


                  • #39
                    big news everyone..

                    Comment


                    • #40
                      Originally posted by intelfx View Post
                      Get yourself better monitors.
                      I'm running at exactly the intersection of what I prefer and what is viable. There's no room to go physically wider and, if you mean upping the DPI, I respectfully decline. I don't want to pay in money and heat output to drive more pixels if that doesn't bring a corresponding increase in how many applications I can fit on my desktop at once.

                      If I ever buy a 4K monitor, it's going to be a 54" large format display so I can keep my current DPI and width but gain the equivalent of a second row of monitors above this one.

                      Comment

                      Working...
                      X