A couple of weeks ago, Linus Torvalds laid down the law, in a particularly Linusesque sort of way. In a software community where tabs vs. spaces can start religious wars, saying that 80-character-wide code was obsolete was, to some, utter heresy. For more background on how we got here, read [Sven Gregori]’s history piece on Hackaday, and you’ll learn that sliced bread and the 80-character IBM punch card both made their debut in July, 1928. But I digress.
When I look at a codebase, I like to see its structure, and I’m not alone. That’s one of the reasons for the Linux Kernel style guide’s ridiculously wide 8-character tabs. Combined with a trend for variable names becoming more and more descriptive, which I take to be a good thing, and monitors’ aspect ratios growing seemingly without end, which I don’t, the 80-column width seems like a relic from the long-gone era of the VT-220.
In Linus’ missive, we learn that he runs terminals at 100 x 50, and frequently drags them out to a screen-filling 142 x 76. (Amateur! I write this to you now on 187 x 48.) When you’re running this wide, it doesn’t make any sense to line-wrap argument lists, even if you’re using Hungarian notation.
And yet, change is painful. I’ve had to re-format code to meet 73-column restrictions for a book, only to discover that my inline comments were too verbose. Removing even an artificial restriction like the 80-column limit will have real effects. I write longer paragraphs, for instance, on a wider screen.
I see a few good things to come out of this, though. If single thoughts can be expressed on single lines, it makes the shape of the code better reflect its function. Getting rid of pointless wrapping takes up less vertical space, which is at a premium on today’s cinematic monitors. And if it makes inline comments better (I know, another holy war!) or facilitates better variable naming, it will have been worth it.
But any way you slice it, we’re no longer typing on the old 80-character Hazeltine. It’s high time for our coding style and practice to catch up.
Sooo many comments on that other article you just needed to open a fresh place for them to keep them coming. ;-) I’ll oblige. Speak for yourself. I still regularly end up on 80×25 physical screens. It is still the native layout of every IBM style PC that I’m aware of.
Sounds like there’s a story there, do tell!
No story really. I’m just pointing out that displays limited to 80cols are still very much with us today. Although, according to the other article Linus mentioned nobody is using an old style terminal anymore, a generic IBM style computer, you buy today, still boots into a 80col mode. Its not until a video driver gets loaded that things change. Since I get called in to work on someone else’s server in a rack, which is live providing services and since little (no) effort is put into video setup for headless machines, most often they are running plain old 80×25. I’m not about to reboot them to enhance my video experience! I use what I’m given.
A funny thing: I did go to a data center recently, grabbed the monitor provided by the center, jacked into the server I needed to do work on and the flat panel display showed “signal out of range”! Apparently this was one of the few servers I’ve worked on where GRUB was configured to use an enhanced video mode. And this must have been one of the few monitors left on planet earth that was limited to much older video standards. The guy overseeing the data center looked at me like I grew a third head when I asked if he had a “more agile” monitor available. :-D
@Franq asked if I edit the Linux kernel on one of these. Not deliberately. But this is exactly the scenario I could find myself in where I might need to patch the kernel. In the past I have gone in and hacked the console driver to disable screen blanking. Nothing more annoying than going into a panic’d Linux server, knowing if only you could get the screen output to turn back on that there could be useful diagnostic data there. :-/
Personally I don’t really care what others do. But for myself I mostly stick to 80cols because I’m liable to end up having to look at the code somewhere where I’m back to the 80col limit and sometimes less. Don’t get me wrong I like the flexibility of being able to have wider displays (2x HD now, thinking of adding another two). But its naive to say this limit doesn’t exist on modern equipment. When the MoBo and/or video card I bought this year starts… HD monitors aside, I still get 80×25. If something breaks that’s what I’m going to be working with.
Siting the kernel source doesn’t make sense either since its certainly not the only source out there and this is a general discussion. Although its probably the one thing I’m least likely to have to edit.
It’s not displays that are limited, just an old useless standard. When I was doing OS dev for a while, one of the first things I did after getting control from the bios was set a higher text mode. No drivers required. It’s been supported since resolutions higher than 320×200 came out (not mode x 320×240 tricks, I mean 640×400 and 640×480). There is no reason today to use 80×25 anymore. Due to legacy reasons it still exists but unless your running an older model 486 or older, this is no longer a thing (VESA support). Yes you see 80×25 but it’s an inherit limitation in the OS not the hardware. If you remove this unecessary restriction there is no reason a monitor & video card from 1990+ can’t run a better text mode. If you’re using hardware older than this, you are very much a minority ;). But chances are if you’re running hardware this old you’d be running legacy software as well.
Okay, Bill, so by “there’s no reason”, what you mean is that you are completely ignoring the half of the people commenting on this, who are TELLING YOU the very good reasons they have for preferring an 80-column limit.
Don’t confuse reasons with rationalizations.
I could say the same thing about the “reasons” people “need” to see lines of 120 characters or more. Please don’t insult people you don’t even know, by dismissing their well-stated reasons as rationalizations. I find your comment offensive.
But do you edit the Linux kernel on them?
They exist, of course. Some still “do things”. Are they prevalent enough to impose a restriction on line length?
No, they aren’t. But let’s be clear about this: people choose the size of their editor windows, and you HAVE to make a choice. The simple fact is that if you don’t agree on a maximum line length in collaborative projects, you WILL have problems, because there will be NO window size that works for everybody’s code. What makes Linus Torvalds a DICK, is NOT that he said “80 columns isn’t enough.” It’s that he bitched about it without proposing a better standard. He wants to retain the right to complain about MY code being too tall and narrow, without saying what a proper width would be. I would be annoyed too, if I had to work with code that was 25 columns wide, so there IS such a thing as too narrow. But setting as the standard “whatever Linus uses,” without saying what that IS, is just lame.
I think the point was NOT to propose another random limit. Who uses a text editor that can’t scroll left/right? If your line of code is that long maybe it’s time to split it up into smaller steps. Yes, a 300 character line of code would be obnoxious, but why can’t an editor be smart enough to split/wrap it into multiple lines with some indicator showing to was split from another line? Or refactor the code to not be so obtuse. Because even an 80 char limit wouldn’t make it any less annoying. With all the required tabs and spacing, you end up with lines of code that don’t even have room to fit anything. Fix the software to work without unecessary limits and then you don’t need to define a new #.
I use miniterm rather than minicom, and people that have used both will understand why.
It is not just variable names. It is things like accessing complex data structures: struct, union, pointer. Use of C++ classess also add to the alphabet puke.
Also constant initialization of complex data types. Long lines can help improve readability, for instance when you have an array of structs, you can put each struct on a line, nicely organized in columns.
Constant initialization in C could be simplified to just implicit initializers in a mess of {} that reflects the struct. :P
Back to accessing those complex data structures…
It can get messy if your struct contains indices or pointer to a self contained table or something. Now you have multiple levels of names just for some simple operation. It makes sense to leave them on the same line without sounding like Captain Kirk splitting sentences with pauses.
Kinds miss the ‘with’ statements in Pascal that let you declare that you are talking about a certain record/object in the following block and not having to repeat yourself with all that stuff.
https://freepascal.org/docs-html/ref/refsu61.html#tailrefsu61.html
I couldn’t disagree more. Line-wrapping arguments for instance makes the code MORE readable and not less.
Agree with you. I like an argument per line, with the remainder being a // comment to explain the argument. Call me old fashioned but I don’t think one can accurately capture the meaning of a variable (or definitely not a class) using multi word names.
“I don’t think one can accurately capture the meaning of a variable (or definitely not a class) using multi word names.”
I’d say this is a good, practical statement, even if it isn’t literally true. The practical aspect is that a) you have to type the 220_character_log_with_underscoresOrCamelCase every time you use it, and b) a name long enough to adequately describe even fairly elementary things is still going to be too long if you use a full width window on a 4K display, and use a 3 pixel wide typeface, at which point readability arguments are self-nulled.
Absolutely. And complaining about the width limitation while insisting on 8 character indent (which also slows reading speed) is insane. But then, that’s what Linus seems to specialise in these days.
Correct.
It doesn’t help that horizontal scrolling and switching between documents is tedious. Tabbed editors help, but that’s still a pain. Just follow the standard as-is, and you can fit two source files side-by-side on a modern PC monitor. If you’re writing code in a terminal instead of in an editor or IDE, you already chose a life of pain, inconvenience, and low productivity. No reason to force that on your colleagues, though.
My general workflow is an IDE split across 2 or 3 monitors and subdivided to show 2-3 source files per monitor, and another monitor just for documentation and winamp.
The problem is that Torvalds hasn’t had to keep up with modern development workflows in over 20 years. While I appreciate his work in creating the Linux kernel and git, I’m not going to take his opinions on professional collaboration seriously until he actually works in the industry and not in his little Linux Foundation safespace.
Maybe you didn’t read the memo: Torvalds was the one saying that the 80-column restriction was outdated, and that he didn’t want to be held to it.
Even a VT220 can do 132 character displays.
https://terminals-wiki.org/wiki/index.php/DEC_VT220
I was going to suggest that you need to go back to a VT100 for 80, but that will do 132 as well.
Many third party terminals like the Hazeltine 1500 can only do 80 characters but even IBM the home of COBOL, FORTRAN and ASSEMBLER had terminals that could do longer lines….
Standard line printer width: 132 columns (plus an unprinted control column under many systems at the beginning:)
In the VT series, you’d have to go back to the VT52 to get 80 columns only. So mid-70s technology.
I’ve been 120 columns wide since the mid 90s.
A former coworker threatened to quit in 2003 if we went wider than 72. Was pretty laughable since he had a 24″ monitor.
Or maybe your coworker didn’t like having to stop typing every 30 seconds to switch to a different document for reference?
Just because you want to be slow and inefficient doesn’t mean your colleague can tolerate it.
With mobile phones being more and more important, we might end up with 40. Commodore era coming back:)))
The k3wl kids will use only languages that use emojis for everything! And I still do not understand why the “Hello World!” is in letters in that emojicode example. Aren’t there greeting emojis enough out there?
Screen width is a red herring and has had little to nothing to do with line length limits for a very long time. Coding styles are there to keep the code _readable_ and line limits in specific are there to stop asshats from excessively inlining expressions into an unreadable mess.
Asshats are gonna asshat, no matter what line length.
I’m going to put that in cross stitch. Seriously.
On 7, 10, 11, 12, 14, 16, 18, 22, or 28 to the inch count canvas?
Dang. It doesn’t seem that long ago that I was writing BASIC in 40 columns on early 1980’s vintage home computers. We called that “state of the art” until we started seeing 80 columns on the brand spanklin’ new Commodore 64!
(this is based only on my own experiences, and will probably not reflect technological history accurately as I didn’t experience all of technological history in my own little corner of the world)
I started off coding on pocket computer with 1 line LCD that scrolls around a lot. Since it is interpreted Basic, one really want to pack as much into a line as possible as comments, white spaces + line over head eats into the limited RAM.
Huh? C64 was only 40 characters.
I think the C128 had an 80 column mode.
I started briefly on a (already obsolete) vic 20 as a kid before I got my c64, and that was 22×23 chars
The argument isn’t if you can, it’s if you should. This has always been a question of least common denominator. When I coded in large companies with many People sharing the code pool, you had many configurations for devices doing that work and many styles of coding too, for smaller groups of People I could tell who wrote the code just by looking at the style they used, a fingerprint basically. It’s the same when VB/VC first came out, the screens of course were built for resolution at or above 1024×768, BUT, many customers still had machines that did only 800×600 – so that’s where you would develop the application, otherwise you would get complaints from them. “Upgrading” wasn’t the solution they wanted to hear, retail products are the same. The other question is readability and maintainability of code storage. I had guys that would code in C where they would try to nest as much code as they could within a single line statement. The problem is that less experienced Developers spend more time trying to unravel the code so they could understand it, than if it was just written in multi-line simplistic statements – long hand if you will. It also makes finding bugs easier. So they all go together in the long run, and the goals are different depending on where it is going, but for shared code stored the simplest is the best – that includes not writing lines that might wrap around on certain People’s machines. Time after all is money in business. What is that old saying? “The code explains itself”, but only if you can read it.
It hasn’t been about screen resolution for a long time. Today it’s about how tiny the characters end up on your screen, and how many editor windows you want to have open at the same time. I consider 8-character tabs to be an affront, and immediately change these (along with the ridiculous practice of putting ‘{‘ at the end of a line) whenever I steal code. Extra-long variable names are the next thing to go – I really don’t need to see “pointer_to_the_currently_selected_object” to understand what the variable is about.
Paragraphs that span 20 lines don’t do much for readability either. Just sayin’…
Let’s also remember Netbooks and low-end
notebooks.
They often have a resolution like 1024×800.
So 800×600 compatibility is Not limited
to old hardware only.. 🙂
Screen resolution is NOT the issue. All modern windowing OSs can do antialiasing on text, so the real issue is character size. The LCD on a 13″ laptop is about 11″ wide, and many of the programmers who have commented here put two editors side-by-side. I know I do, and Torvalds himself says he puts six editors on the screen, two high x three side-by-side. Anyway, even with 80-column lines, that’s 160 characters / 11″ = 14.5 char/in. This is barely big enough for people with good visual acuity, so scaling down into the 9-10″ LCDs of netbooks and tablets rule these out. Trying to put two editors side-by-side with 120 character lines puts it at 21.8 char/in, which is beyond what most people can read without eyestrain.
If you have a small screen, you still have the option of using only a single edit window across.
120 chars/11 inch is only 11 chars/inch. I just checked a regular paperback book, and it has almost 16 chars/inch.
If you look up the specs for the VT-100, you will learn that it was 80/132 chars/line. I am sure the VT-220 was also.
VT-100 was the precocious child. ADM-3a was the standard.
Gee, I remember when Dad took me to the Hazeltine plant and let me play with the Haseltine 1200 in LOCAL mode. Older than the one in the photo. Must have been late ’60’s or early ’70’s.
Look: specified programming styles are how we try to try to be civilized when collaborating. If people are going to get bent out of shape, some because the lines are too wide, and others because the functions are too tall, you’re going to have bigger problems. Or wider ones, anyway.
Look at what happened with ffmpeg. It split into two factions, the original ffmpeg and avconv, and it really came down to the avconv faction just objecting to the existence of a Benevolent Dictator For Life, and going to the extent of convincing Ubuntu to put up warnings that ffmpeg would no longer be supported, whenever you used ffmpeg. Torvalds is a big enough presence, that if Linux were to split, there would be little doubt which was the legitimate version, so we’re stuck with whatever he decrees, whether it makes sense or not. (And let’s be clear: it does not.)
“When I use a word,” Humpty Dumpty said, in rather a scornful tone, “it means just what I choose it to mean—neither more nor less.” “The question is,” said Alice, “whether you can make words mean so many different things.” “The question is,” said Humpty Dumpty, “which is to be master—that’s all.”
Portrait mode monitor. It’s life altering.
With wide tabs, you use peripheral vision to detect context changes.
(This is why to use tabs: you get to set the width to whatever is comfortable for you)
Yeah, if we’re going to talk about holy wars, let’s talk about aspect ratios, and idiots (to be clear) doing videos in portrait mode. And that’s not just 3:4, but 9:16.
Even worse is the TV news doing a background fill with blurred version of the same video. They should leave the dead space or fill it with their usual scroll of news headline.
Portrait in 4:3 (“3:4”) is delicious for coding. Enough width that you can read everything, enough height that you can take in an overview.
To be fully honest here.
If a line of code wraps over multiple lines or not is all down to the display settings in one’s text editor.
I myself follow the standard that 1 line of actual code should always remain as 1 line of code. (No line feeds or carriage returns in it what so ever…) Though, I also end up edit a lot of code in text editors where I happily let it wrap said lines of code to keep it all visible when needed. (Since horizontal scrolling is a bit of a drag at times…)
And that text editors can handle both horizontal scrolling and/or line wrapping isn’t really a new feature, so how old of a system are you working with for this to not be there?… (And if one is working on such a relic, then one likely isn’t going to utilize much modern software regardless.)
I also know of people that take a wide screen monitor and pivot it to be exceptionally tall instead, giving ample room for well over a hundred lines of code. Making editing easier. Some even let the lines of code continue off screen instead of wrapping.
Though, with “modern” programming environments, one can typically view multiple points within one’s code at once. A bit like having multiple text editors working on the same document. (And each one of those might not even have the same width/height…)
So the argument of “we should stick to 80 character wide lines!” is more than just a bit old fashioned to be fair…
I would say that if a line of code is very long, say more than 80 chars excluding tabs, it should likely be split into multiple lines for better readability. I.e:
System.out.println((x%3==0 && x&5==0) ? “jazz” : (x%3==0) ? “fizz” : (x%5==0) ? “buzz” : x)
might be better written as
if(x%3==0 && x%5==0)
System.out.println(“jazz”);
else if(x%3==0)
System.out.println(“fizz”);
else if(x%5==0)
System.out.println( “buzz”);
else
` System.out.println(x);
That’s not much better, and more inefficient.
Better would be to introduce some extra variables.
int jazz = (x % 3 == 0 && x & 5 == 0);
System.out.println( jazz ? “jazz” : … )
Or split it up in lines like this:
System.out.println( (x%3==0 && x&5==0) ? “jazz” :
(x%3 ==0) ? “fizz” :
(x%5 == 0) ? “buzz” : x
That’s got little to do with the length of the line and everything to do with abusing the ternary operator. Going more than 1-deep makes it essentially impossible to understand at a glance and really should be avoided.
Back in college, the first programming language I learned was APL; a language notorious for long, unmaintainable, “one-liners”. [aside: I once wrote a FFT function, as a single line, that wrapped at least 4-times on a 132-column printout. APL is also known as a “write-once” language.] anyway…
Given the mathematical nature of the APL language, and it’s unique character set, I had assumed that *all* programming languages would use a rich set of well-developed symbols from the sciences and other fields. Boy was I wrong, as I learned with my very next programming language. That is my complaint here.
One programmer friend, with decades of experience, once exclaimed that “computers actually destroy information”. He went on to explain with many examples, (the representation, and rounding, of 2/3 being the simplest). His expertise was ray-tracing and had many examples from that intersection of graphics and numbers.
Anyway, because with ASCII we are limited to a 96-character set, there just wasn’t room for so many imporatnt other symbols. Only letters, number, and a few random symbols. So we either use letters to write the names for the symbols we should be using, or even worse, we endless reuse the few ASCII symbols for completely different things and let the reader struggle with (or guess) the meaning from context. (e.g. “*” is a good one.). Professional programmers later labeled this horrendous compromise “operator overloading” and pretended it was a good thing, declared victory, and went home.
Wouldn’t it be wonderful to see a line of code that actually contained the *symbol* for PI. (Rather than importing a math library that somehow mangles the real-world purity of the mathematical PI, into the corrupting limitations of a man-made computers word length.
It would be nice if lines of code contained at “divide symbol”, or “epsilons” if needed, or a “sigma” symbol to indicate a summation of what follows. You get the idea. Code would be a lot more readable if it used the special symbols for the technical field that the code applies. And there should be support for superscripts and subscripts in the actual code, with functional meanings to differential related variables or exponentiation, respectively.
Instead we have a hodge-podge of long spelled-out alphabetical compromises, that is both distracting and ugly.
Unicode addressed all the worlds languages. Unicode also addressed the shortage of symbols. When will programming languages catch up and start using them?
The same FFT code in a more readable language would still be unreadable to the average coder unless he/she knows the math behind it and what the sprinkles of coefficients means. It is one of those things you wouldn’t touch once it works much like potted components.
I think this is the one example where there is a pretty strong consensus, AGAINST Unicode in source code.
APL was the thing nobody ever wanted to see again, and when programming languages started making it possible to use Unicode in variable names, virtually everybody who had formally specified programming styles prohibited non-ASCII characters anywhere but in comments and user-facing text. Think about it: what do you do when you need to modify code from your Ukranian collaborator, when half of the characters in his variable names aren’t even on your keyboard? I would think that anyone who ever used APL would recognize the problem. There was, by the way, an ASCII variant of APL, but it never gained any traction, probably because APL was just a train wreck overall, not just because of the character set.
Been waiting for Chinese programmers to do this. Instead of keywords based on simple English words, base keywords on single Chinese characters–there’s a lot more to choose from.
And Chinese used to be written vertically. So imagine switching to dark mode–let’s say, green on black–and have the characters print down the screen vertically. And to track multiple threads, have each coming down in a separate column on the screen, like a waterfall of green characters down the screen. I think there was a movie that pictured that….
I’ve been waiting for someone to use emoji’s in their variable names so I can scream in horror.
” Professional programmers later labeled this horrendous compromise “operator overloading” and pretended it was a good thing, declared victory, and went home.”
I laughed so hard at this one.
80 characters is for amateurs. Check out Line 507:
https://gitlab.com/arduinoenigma/uhrswitch/-/blob/432ff48a1d409b8a9d3d901af331101f3c24cee7/UHRSwitchLogic.ino#L507
Automatically generated by the code on Line 117:
https://gitlab.com/arduinoenigma/uhrswitch/-/blob/bb28d471afc56d03244e1d0892007e08e2039a89/GenerateTables.ino#L117
You see, this is how you can tell it’s a holy war: those who believe in the 80-column convention write their code generators to stick within 80 columns, even though it takes extra code to do that, and serves no real purpose. And I say that as someone who writes code generators that limit line lengths.
In FireFox, the line 507 link pops up in a display window which neither wraps nor side-scrolls, so it’s impossible to see the entire line. I had to highlight it, ctrl-C, then ctrl-V into Notepad to see just how crazy it is.
That’s because you’re using a browser. If you were working on a project that had source lines like this in it, they would be accessible just like any other lines in the source. But these are examples of generated code, which isn’t meant to be read by humans, so even for some of us who are religious about line length limits, we tend to be lenient when it comes to machine-generated lines.
In the browser, you have to scroll all the way down to the end of the file, then scroll horizontally, then scroll back up. In the Arduino IDE it works fine though, the horizontal scroll bar can be used on any line…
Surprised that works actually, there’s a / missing about 8 seconds of holding the right arrow across…
..
..
..
C’mon, I nearly had you. :-D
That’s why the TestGetPlug() function is there:
https://gitlab.com/arduinoenigma/uhrswitch/-/blob/bb28d471afc56d03244e1d0892007e08e2039a89/GenerateTables.ino#L162
To test all the cases and make sure both strings are intact…
I find that on today’s wider monitors, I use the extra width to have two editor panes side-by-side, so an 80-100 char limit helps for my use case.
THIS. It’s not unusual for me to have three or four IDE’s open at once when developing a system with multiple interacting devices, and even on a 4K television set it can get tight.
It’s not unusual for me to have three or four *cough*websites open with an IDE when I’m *cough*cut&paste coding. So I like to side by side or tile too.
That’s right. Linus is saying (in effect), “what’s good for me should be good for you,” without even considering the reasons other people may have for having developed their own styles.
Except the 80-column restriction is the exact same thing, and even the people who champion it are rarely using systems where they’re physically restricted to it. It’s there more by tradition than because it’s beneficial.
And, really, why shouldn’t he be allowed to specify stylistic preferences in *his own* project?
Oh, he absolutely CAN demand ridiculous things in his own project. He’s Linus Fucking Torvalds, (Benevolent) Dictator For Life. Take it or leave it.
But here’s a thought: Just as Torvalds is doing this for the benefit of many, so are the many programmers who are also working on the Linux kernel. Collaboration means figuring out how to work with people, and I think he’s never been very good at that.
Its called working with other people. Yes its his project and he can impose his own visions but that creates backlash from others and bad working enviroment. Very bad HR managment, if something isn’t technical imposed by science or other objective outside force then things like this should be discussed and outcome should be compromise that most people accept. Going dictator way especially in open project is team-killer.
Ridiculous? Bad working environment?
Come off it. Opinions on coding style are like assholes, everyone has one. But it’s a shit idea to let everyone on a project use whatever style they want. Picking a set of style rules and mandating it across a project is the opposite of bad management. It’s the consistency that’s more important than any particular rule, and if you get your nose out of joint because someone has decided on a rule you don’t like, then they aren’t the problem, you are.
Exactly.
IMHO, this shows how simple minded
Mr. Torvalds and his fan club are.😉
Or maybe they are just getting old? 🤔
On a wide screen display (=landscape),
I often use the extra space to display
two PDF pages (=portrait) side-by-side, also.
This makes reading very comfortable,
almost as comfortable as reading a book.
I can put two 120 column text editors side by side. And I just have a crappy old 22″ monitor with 1920 resolution.
So you’re putting 240 characters across a 22″ screen, which is about 18″ wide, for 13 characters per inch, without accounting for window borders. Which is doable, but a little on the small side for reading over an extended period of time. Now, try doing that on a 15″ laptop screen. This is what I was saying on the other thread the other day: he with the biggest screen wins. Torvald SAYS, “Tough – that is your choice.” Which makes him an asshole.
13 chars/inch is better than a paperback book I have here with 16 chars/inch.
My laptop is about 12″ wide, and a full size window is 172 chars., or about 14 chars/inch.
If I have two edit windows open, I just overlap them a bit.
I think that’s the gist of the problem.
80-100 character.
Probably for most people working on modern stuff, even a couple windows side by side, 100 characters would work better, but then there’s people for whom 120 would be a better fit.
or 140.
IMO, write things for readability. If a line would be more understandable broken onto multiple lines, that’s the thing to do. If you have to put an awkward line break in just because you have a slightly longer line of code that’s a few indents deep, and it’s not helping readability, just leave it alone.
OTOH, lots of people use ridiculous indents made of spaces, so I guess we can’t trust everyone to have good judgement about readability.
Long lines make for some interesting hunt when the compiler gives you “Wrong assignment in line 530” and that line is some 900 characters wide with maybe some 37 assignments …..
Code needs to be written for clarity.
Personal code ? whatever the person prefers.
Code that will be shared/worked with others ? Some reasonable style that is agreed by all, or the war axe will be unburied.
Good point
It’s not about screen width and character limitations. It’s about readability. As noted in the article, confine your statements and you will write less complex code. Just like twitter. Keep it short and too the point.
Another thing. Vertical orient your monitors.
That’s abusing a rule to get a coincidental result. There’s nothing stopping you writing awful complex code in 80 columns, just look at any entry in the IOCCC. Equally, some good code can be forced into awful shapes by slavish adherence to a line length (“oh, I can’t fit descriptive variable names in, I’ll just start abbreviating everything.”)
If you want to encourage clean code in your code base, choose rules that emphasise cleanliness, stop relying on side effects.
Twitter doesn’t make communication clearer, There’s not enough room for any nuance, or proper explanation. You have to hammer your thoughts down until they’re a blunt soundbyte.
Turn the widescreen monitor on its side and make it a secondary display… then you will have much more “short” code available to your eyes. The normally-oriented monitor can then be your primary.
I tried that, but the keyboard being sideways made it hard to type.
This worked better with 4:3 or 5:4 monitors. 16:9 is just too tall and awkward.
Poke 33,33
😁
mode co40
Arguing for wider coding is invariably based on the “They said it couldn’t be done!” Style arguments which presupposes that wider is better.
But in reality wide lines aren’t easier To read for the same reason that books are portrait mode rather than landscape mode; why newspapers choose columnar text rather than full width text etc. And it’s because of peripheral vision.
In fact the proponents of 8-char tabs are unwittingly confirming this by arguing that you need it to navigate code using peripheral vision. Well of course you do if your lines of code go on forever, your peripheral vision is so poor you need massive visual clues.
80 column text is like that because primarily it’s a comfortable width, like typewriter carriages. It’s the best psychological choice.
Well said. It’s just that dumb human tendency to want to make numbers bigger, no matter the cost. A proper monitor for coding is one that is turned on its side.
You can’t read code with peripheral vision. At best it only gives you a clue at the rough structure.
Try staring at the center of 80 column text, and see how much you can read left/right without moving your eyes.
I’d argue that lines of code longer than 80 characters are evidence of a naive coding mindset: the idea that one-liners are somehow more efficient than multi-line formatting.
With the exception of Python and other examples of semantic whitespace, both horizontal and vertical whitespace disappear in the lexer. More generally, any microprocessor from this century has multiple processing units that operate in parallel (if not multiple cores) and a complex, multistage pipeline. By the time the optimizer gets done rearranging the abstract syntax tree, any notion of line organization the programmer had will be gone.
Source code exists mostly for humans, and the quality of human text depends mostly on its convenience for readers who don’t already know what it says.
Whitespace, both horizontal and vertical, is a powerful tool for reader convenience. That’s why we have things like things like paragraphs, and why gothic blackletter is so hard to read.
Whatever opinions you have about whitespace and line organization, base them on the opinions you develop while reading someone else’s code.
IMO, from that basis, long lines are a mildly bad code smell.. about the same as deep nesting. I don’t object to LongVariableNames per se, but prefer to keep name length proportional to scope. On that principle, lots of long names smell like heavy use of global variables. That, in turn, suggests the reader needs to know lots of non-local information to understand code where a long variable name is used. In the other direction, code that remains readable with short variable names tends to suggest good locality and modularity.
Some people use long names for struct members. You could have a big heap full of thousands of structs, all rooted in a single local variable.
I try to stick to ~80 columns because I find that in the development environment I use, I find it is the best balance of readability even at high resolutions.
At work, I use 1920×1080 on a 24″ monitor. 80 chars means I can have a sensible font size and have a line not sprawl past the half-way mark on the monitor, which means I have space on the other side for either another file, or for another part of the same file.
Typically I use gvim and FVWM2 as the window manager. FVWM is set up with key/menu bindings that allow me to manually tile the windows. (I have also tried tiling WMs like awesome, found myself preferring FVWM.) Being able to maximise an editor window and use “vertical split” to view two parts of the same file simultaneously, or to display two separate files side-by-side so I can code one whilst referencing the other has been instrumental to my productivity.
As for my colleagues. One of my colleagues likes using a larger font size due to his eye sight. There: an 80 column limit actually works in his favour too since the characters are big enough that 80 of them do fill a 1920-pixel wide screen.
Indentation of 8 characters is a challenge with 80-char wide lines… you’ve got basically 10 indents. So you avoid deeply nested logic that requires such heavy indentation. This benefits code readability and maintainability, and in languages like JavaScript and Python, makes things easier to unit test.
JavaScript developers had an excuse years ago because they needed to deeply nest routines and try-catch statements to get things done. ECMA-262 showed us a better way with Promises… then ES6 came along. Personally, I’d just rather use ES6.
We do need some limits though, if lines are too long, then you can’t see the whole line with a VS code or similar sidebar open.
If a linux developer makes the lines too long, someone else will fix it, or refuse to send it upstream.
Line length is just a tiny part of writing good, readable, code, and we don’t have hard limits on many other aspects either.
This isn’t hypothetical, and this isn’t a typical Linux developer. This is Linus Fucking Torvalds saying that it’s a pain for him to deal with other peoples’ 80-character lines, and everybody should just have to deal with his 120 (or so) character lines. There IS no upstream person to reject his code.
He doesn’t write much code himself nowadays, so that’s not a very relevant objection.
Wait, there is an actual code window in VS Code? I thought all there was is side bars and side bars of side bars!
We also have bottom bars too, not just side bars! A terminal wouldn’t fit too well in a vertical bar.
Long lines in split screen buffers suck. Wide screens in my world mean more buffers and more open editors.
I’m a housepainter who learned some C, C++, PHP (yeah, it IS good), JavaScript, etc. What I’m not seeing is anyone trying to rub some science on it. Given a screen of arbitrary width, it still seems likely there is a sweet spot of width that we could determine using, I dunno, metrics and analysis. Not religion. Which is all I see here. But what do I know. I’m just a housepainter.
The other post has some of those studies mentioned, and then it’s “What’s good for English language isn’t good for code” and “what’s good for APL isn’t good for modern code” etc etc.
That’s because science doesn’t work for individual cases. The “religion” aspect you’re seeing is, “this is how I work and what works for me, and you’re trying to break it.” No science necessary. This also, by the way, is the root of all wars, not just flame wars.
I understand, but I’m not seeking THE right width, but the right way to frame the problem so that there is some basis besides aesthetics on the line. I like 80 chars, but that’s a footbullet in some scenarios, so I don’t let the idea of it overwhelm good sense. Still, we’re not all THAT different, and it seems like there probably is an optimum range, if not specific width, fit for normal human perception/hardware.
A little while ago, I came to the conclusion that ‘readability’ is bullshit because there is a lack of metrics.
But line length also factors in a bit of ergonomics, and a bit of ‘neural net training’.
Some people complain about moving moving their heads, or even their eyes. So there is physical factor of a person’s physiology involved.
As for the neural net training, we know people generally don’t like change and there seems to be a trend with a number of programmers that change causes a range of issues from mild discomfort to reasonably acute distress.
The thing is that the nature of the field at this point seems to be that saying something causes you discomfort for whatever reason is frowned on so we end up with discussions like this.
That’s why I’m a housepainter. I can code and I like it, but I don’t like to be around neurotic people, whether it’s their own emotions they struggle with, or change, or unspeakable social insecurity. Just not worth it.
Seriously, people are still arguing over whitespace? You are programmers, and it is not very difficult to write a quick script that re-formats the code. Word wrapping, and automatic token indenting are a thing. Hell even a small Javascript piece can do it. This is what Python was written for. but yet you are all still arguing over white space that can be changed with zero repercussions in most languages.
No
Sounds good in theory. I suppose if all code that is ever checked in perfectly follows the same standard always then it might work. I would be too afraid that even after running a script to change it back I would go to check in and the version control system would see every single line as being changed due to some invisible whitespace issue.
No, same here. Its just another Pointless Argument on the Internet.
What is more interesting is /why/ people argue about this sort of stuff. It would make a good article. Very few people understand their own thought processes.
I like to see the structure of the code too. But I don’t need anything near 8-space tabs to do so! How many newlines do you put between methods or functions? With that much indentation loops and control structures within the same method feel like they are less connected than two separate methods are to one another! Plus all that left/right eye movment makes it easier to lose one’s place in my opinion.
I think this kind of thing is exactly why we should be using tabs instead of spaces. One tab per level of indentation and editors that can be configured to display a tab any width you want. You can set your tabs to 8 spaces, I’ll set mine to 3 or 4 and we can all be happy.
YouTube indicates I watched this before and I don’t quite recall but I’m rewatching it… the immediately relevant bit, if it doesn’t make it in here, is from around 11:00 to 14:30.
https://www.youtube.com/watch?v=ZsHMHukIlJY&t=677
I worked with a blind firmware developer whose Braille display is limited to 40 characters. He convinced me to stick to 80 characters max, just so he wouldn’t have to keep side-scrolling to understand what the code was doing (he’s also a big fan of the Barr group’s embedded C coding standards).