Software developers won’t ever run out of subjects to argue and fight about. Some of them can be fundamental to a project — like choice of language or the programming paradigm to begin with. Others seem more of a personal preference at first, but can end up equally fundamental on a bigger scale — like which character to choose for indentation, where to place the curly braces, or how to handle line breaks. Latest when there’s more than one developer collaborating, it’s time to find a common agreement in form of a coding style guide, which might of course require a bit of compromise.
Regardless of taste, the worst decision is having no decision, and even if you don’t agree with a specific detail, it’s usually best to make peace with it for the benefit of uniformly formatted code. In a professional environment, a style guide was ideally worked out collaboratively inside or between teams, and input and opinions of everyone involved were taken into consideration — and if your company doesn’t have one to begin with, the best step to take is probably one towards the exit.
The situation can get a bit more complex in open source projects though, depending on the structure and size of a project. If no official style guide exists, the graceful thing to do is to simply adopt the code base’s current style when contributing to it. But larger projects that are accustomed to a multitude of random contributors will typically have one defined, which was either worked out by the core developers, or declared by its benevolent dictator for life.
In case of the Linux kernel, that’s of course [Linus Torvalds], who has recently shaken up the community with a mailing list response declaring an overly common, often even unwritten rule of code formatting as essentially obsolete: the 80-character line limitation. Considering the notoriety of his rants and crudeness, his response, which was initiated by a line break change in the submitted patch, seems downright diplomatic this time.
[Linus]’ reasoning against a continuing enforcement of 80-char line limits is primarly the fact that screens are simply big enough today to comfortably fit longer lines, even with multiple terminals (or windows) next to each other. As he puts it, the only reason to stick to the limitation is using an actual VT100, which won’t serve much use in kernel development anyway.
Allowing longer lines on the other hand would encourage the use of more verbose variable names and whitespace, which in turn would actually increase readability. Of course, all to a certain extent, and [Linus] obviously doesn’t call for abolishing line breaks altogether. But he has a point; does it really make sense to stick to a decades old, nowadays rather arbitrary-seeming limitation in 2020?
Line Lengths Throughout History
Where does that limitation come from anyway? It seems like one of those things everyone knows about and follows without questioning or really understanding it. The 80 characters are just all around us — there are these devices of yesteryear with their 80 character displays, your terminal emulator’s default width comes preset to 80 columns, and of course all those coding style guides that keep bringing up the 80 character line limit. It all just seems to magically come together somehow, and that’s how things are, period. Well that didn’t help at all now, did it? So let’s take a few steps back.
Yes, since the early days of terminals, the screen size was indeed mostly limited to 80 characters. There were exceptions in either direction, 72 and 132 for example, but 80 was the most common one. Considering we’re talking about the late 1960s here, it seems plausible that display technology simply wasn’t advanced enough to make it feasible to have bigger screens and longer lines, and that’s how they ended up with 80 characters. But that’s not it either.
Sure, the state of 1960s display technology had definitely some impact as well, but the choice was ultimately made out of habit rather than necessity. Back in that time, when the first terminals were designed, people working with anything computer-like primarily knew one common storage media: punched cards. The star of the time, dominating the industry, was IBM’s 80 columns by 12 rows card. And well, that’s pretty much it.
The popularity of that specific card lead to the decision to use the same amount of columns on terminals, which in turn defined it as the golden standard for coding styles, still widely in use today. In a way it’s understandable, considering the 80×12 punched card was quite literally the greatest invention since sliced bread at that time — as both were revealed to the world in July 1928. Yes, the full origin of 80 characters essentially dates back to 1928.
(The card’s patent application was filed July 20th 1928, the first sliced bread was sold July 7th 1928)
Present-day Line Lengths
So here we are, close to a century later, still squeezing text in the same 80 character lines. Well, not everywhere, some languages see it differently today, and if not, frameworks might come with their own guidelines. But while we have larger screens at our disposal nowadays, long lines will eventually interfere with our field of vision. In other words, requires us to move our eyes, or even the entire head, disrupting the reading flow and increasing the risk to overlook something important.
Then again, the discussion isn’t about getting rid of line limits altogether, but challenging an enforced, hard 80 character limits. From a reading comfort point of view, the difference between 80 and 85 for example is negligible, and insisting on the former will at best lead to clumsy line breaks — like the one [Linus] addressed — and worst case to cryptic variable names and other questionable formatting.
A common compromise is to encourage 80 characters, but allow up to 100 or 120 characters, and draw the hard limit there. This way, if you exceed the soft limit, you don’t have to sweat it too much, and by the time you reach the hard limit, there’s enough room to split the lines in a coherent way.
In an ideal world, none of this would matter much, and an IDE would handle all of that transparently for us. We would configure the style guide’s limit, and additionally set our own preferred limit. The IDE presents the code as we prefer it, and saves it the way the style guide asks for it.
While that works quite alright with things like indentation style, line breaks are unfortunately a lot more complex. Where is the right place to split to keep the code readable and preserve logical blocks? If done naively by brute forcing line breaks, we’re exactly back at the point [Linus Torvalds] is trying to make. Maybe machine learning gets us there in the future, but until then, we’re on our own.
What’s Your Limit?
So what’s your take on all this? Where do you have your line length limit set? And do your side projects differ from you work environment here?
Do you agree with [Linus] and say enough already with the forced 80 character madness? Or do you prefer even shorter lines?
Let us know in the comments!
Not an issue for me. 80 characters is 10 CPI on a standard letter size page. It’s not something I feel strongly about changing, since long lines fold themselves in word processors and text editors.
Sometimes I print out small sections of code to scribble around the difficult bits, and then I gain when it’s just one page.
What does “print” mean? I have heard rumors of ancient barbaric practices involving the sacrifice of trees and the dumping of bleach into streams but I thought humans has moved past this sort of thing.
You laugh, but I find that a paperless office is not nearly as good as a hybrid paper-digital one (for my use case). A piece of paper is effectively a write-once, read-many external display.
It’s:
* lightweight (except when stacked with tens/hundreds of other “displays” – but so are LCDs)
* portable – pocketable even, when folded – unlike LCDs
* low physical space footprint – doesn’t need a screen arm/stand, can be temporarily or permanently folded or stacked to take up very little space
* inexpensive to manufacture per piece (assuming a laser printer and cheap reams of paper) – have as many of them as you want, and give each viewer a copy in cases of collaborative design/review
* persistently displayed – no latency issues or “misclicks” that make the content hide itself – focus on what the content is and dismiss it with a physical action (i.e. storing away the piece of paper)
It can also:
* stay “lit” indefinitely without a power source – infinite battery life, portable, no need to run an extra power cable
* have free-form markup of absolutely any kind and shape that you can imagine – freehand diagrams, doodles, arrows, text written at arbirary rotations and locations on the page
* interoperate (by stapling/literally copy-pasting) with content stored on pieces of paper that have been produced by virtually any other digital or paper filing system – it’s still not a solved problem with digital content
As long as you treat the piece of paper as a “view” onto some digital-native content and not a master copy, a lot of issues with purely paper-based or purely digital-based workflows are eliminated.
https://youtu.be/W63_N63Qy-w
Well done, this comment made me laugh, completely factual though but you missed out a major point: if a paper copy is the only copy of a document it can easily be permanently and irrecoverably erased through means of incineration.
It also doesn’t shatter when dropped.
what’s a letter? you mean an email.
A letter is like an email that you’ve 3D printed, except in only 2D and with layers of ink on paper instead of plastic filament. It’s an interesting technology.
Really? So, a letter is intended to be sent somewhere to someone… How on Earth would you get said letter delivered to that person? You’d have to come up with something equivalent to an IP address and delivery system and standards would have to be developed to avoid (further) confusion. It would never work.
Sticky
Tariff
Aware
Mailing
Protocol
Indeed. The physical layer seems susceptible to many malfunction and it seems to lack any kind or redundancy or error control.
But, hey! In Netherlands a guy pointed that if you fill a Wolksvagen with hundred of thousands of these “letters”, you bandwidth will be more than acceptable
I am probably the only person reading HaD that has a heartfelt hate for (private) e-mail, which I check about once every two weeks or so. It is faster to reach me by mail than by e-mail.
I’d have one of my servants carry the letter to its recipient.
The 80 character line length is optimal for English word lengths, because that gives you an optimal number of words per line to read. Other languages, like German, with longer words, have optimal lines longer. However, programming languages tend to pick very short words from English for their keywords, so that shouldn’t be a problem. So it comes down to your programming culture and that of the libraries you use. So if you are forced (because that couldn’t possibly be a conscious choice) to use a language that has names like SimpleBeanFactoryAwareAspectInstanceFactory or AbstractSingletonProxyFactoryBean, then you probably need to up your line length limit to somewhere around 2048 characters at the least.
80 characters is “optimal” for English word length? How do you define “optimal?” Is it optimal for reading comprehension, reading speed, or something else? What studies were done to show this? How were they performed? What alternatives were tried and what was the result of trying them? I strongly suspect there is no evidence that 80 characters is anywhere near optimal for any given purpose, and that in fact it’s essentially impossible to show that any specific line length is optimal for any given purpose. But I’ll be happy to read any references that prove me wrong.
You suspect wrong, but I’m not going to do your research for you, especially since the questions you ask are one web search away.
The standard paper size was chosen for optimal manufacturing efficiency with manual paper manufacturing processes, so what does that have to do with reading comprehension?
Also the size was chosen when the preferred marking technology was a quill pen with a very different resolution than what is possible today. Did they enforce an 80 character limit with a quill pen? Does the 80 characters include the illuminated ones? Were Shakespeare and the christian monks counting the characters as they transcribed? Inquiring minds want to know.
Counting characters from the start and end of a page to check that the characters in the middle matched in source and copy was supposedly a form of error checking they employed.
Nonsense. We don’t invent things that have no utility. If the quarto page became a rough standard, it was because it was more useful than pages larger or smaller than that. And the quarto was what drove the size of the typewriter, and then the punched card. Remember that the original Hollerith card held only 45 characters, and it was found to be insufficient, resulting in the 80-column standard. Oh – and also the Univac 90-character card, which was roughly the same size as a Hollerith card, but with two rows of 45 six-bit coded characters, an example of parallel development. Maybe if Univac was more popular than IBM, we’d have seen 90-column terminals as the standard.
In fact, the quarto page itself comes from folding a sheet of paper that is efficient for paper manufacturing and printing, twice (once on each axis), then binding and trimming the edges.
Standards do not evolve around what is easest, but what is necessary and most desirable.
Not so sure of your statement anymore?
Yup. “I’m not going to do your research for you” ALWAYS means “I don’t have a sensible counterargument”.
>The 80 character line length is optimal for English word lengths, because that gives you an optimal number of words per line to read.
Citation please.
Just pick any book on typography. Literally any single one. Or if you prefer Wikipedia: https://en.wikipedia.org/wiki/Line_length
Thanks for that, but:
So 80 cpl is specifically not an optimal length. Most likely, it’s just that the inventors needed some number to standardize on, so they picked the only number they had — the size of a typewriter.
Ironically, the standard 10 char-per-inch font always looked like “baby’s first typewriter” to me. I much prefer the 12 cpi “elite” fonts, and fortunately most modern fonts tend toward that slimmer appearance.
wrzwicky: Are you serious? The line length followed the width of a typewriter platen? That’s the most ridiculous thing I’ve ever heard. Where do you think the width of the typewriter platen came from? FROM THE WIDTH OF A STANDARD PIECE OF OFFICE PAPER.
I’d prefer actual studies and scientific papers with published methodology and metrics. There are some on the Wikipedia page, each has some caveats and mention tradeoffs. All three papers have experimental groups that would be considered problematic in the post reproduction crisis world of psychology. For example, “Dyson, M. C., & Haselgrove, M. (2001). The influence of reading speed and line length on the effectiveness of reading from screen.” used a sample size of just 36!
A quick skim of the papers isn’t super definitive either, some generalizations seem to possible based on ‘short’, ‘medium’, and ‘long’ line lengths, but there is no hard evidence to let one programmer alpha nerd another over their personally preferred line length.
Optimum line lengths for narrative have almost nothing to do with optimum line lengths for coding. To mention just one factor, it frequently helps greatly to have a whole function on the screen at once, and if that requires 132 characters per line, that can be optimum. That concern is completely inapplicable to fiction.
Even font choice affects optimum line length.
Consider spreadsheets. Would you seriously claim that an 80 character limit for spreadsheet width makes sense?
Maybe I’m connecting dots that aren’t connected. Are you implying that spreadsheets are fiction?
Exactly. A computer program is not read as a book, and code almost never looks like a block of text, fully justified to both margins.
Haters gonna hate. Thumbs up @deshipu :)
I’m actually deeply disappointed that the article didn’t elaborate on typography aspect…
Do you read code like novel, word by word? Usually I need to follow particular execution scenario,
so ease of understanding the structure of the program is also important.
I hope you realize, that comprehending every single word is far more important in understanding a program than it is in reading a novel.
Usually not. When I’m trying to understand some code, I usually have a specific purpose, like adding a new feature, or fixing a bug, so I’ll read through the relevant stuff, and skip the rest.
If you’re going to make that argument, then line lengths should be based on *active* length – that is, excluding whitespace at the beginning of the line. Running low on space deep in a loop is where programmers start complaining about line length.
Some might complain about adjacent lines with large differences in beginning whitespace, in which case agree on another rule for the combined line length of adjacent lines. Suggest that adding short comments can be a good way to smooth the transition.
Can you explain how that would work, since it would mean that lines of the same “length” would take up different amounts of horizontal space? I mean, these days it’s almost never the programming language limiting the line length; only the programming style for the project.
The reason line lengths are (usually) specified in a project’s “acceptable style”, is so that anybody working on the project can set up their editor to the appropriate line length, and then everybody’s code becomes readable without ugly and unintended word wraps that obscure the visual indication of hierarchy. I don’t see how defining the length excluding preceding whitespace could possibly help.
If your editing environment can’t make windows of arbitrary size, you need a new computer and a modern operating system. New projects need to at least keep up with technology available a decade ago.
It’s not a matter of the capabilities of the editor. It’s not a matter of technical limits at ALL. Nobody is talking about technical limits. It’s a matter of my authority over my own screen space.
The absolute line length limit would be pretty large – say 150 characters, but only 80 characters or whatever can be used for actual text. That way, excessively long, hard to read lines are avoided, but still allow several layers of indentation without running short on space.
In short, you get the main advantage of high line length limits without the main disadvantage.
I think you’re missing the whole point.
We should stick to 80 columns just as we have stuck with railway gage going back to the Roman empire chariots, 19 inch rackspace, 1/4 inch audio jacks…
If that’s what “works best” for you.
I do not think that is a valid argument. For one thing not everyone uses standard gauge rails but the other is the cost involved. Changing physical standards is hard and expensive. Changing coding standards is cheap and easy if you apply it to just new code.
I admit that I am a tab rebel. I like tabs for indent because you can change them. If I like 3 spaces per level I set that in my editor if you like 4 I set that. Simple. The down side is it is easy to mix because on the screen they look like spaces. which is where you get into problems.
I disagree on the statement about how to come up with a coding standard. No do not work it out as a committee Pick one of the many published standards available then ask if anyone has an objection and why. If it is valid then consider it if not move on. The same with comment headers in files. Decide and stick with them unless you have to make a change for legal reasons. Nothing is dumber than paying a large team to fix headers for the 8th time.
the coding standard was somewhat tied to the physical capabilities of printers and teletypes available during the era those languages were created. We still have some physical limitations, like the aspect ratio of monitors making some widths to height ratios more practical than others.
My preference is a 10:16 ratio. That fits neatly side-by-side on a 16:10 monitor, or fills a portrait orientation 16:10 monitor. I don’t care about 16:9 or 21:9, not close enough to the golden ratio to make splitting and rotating very nice. a 16:10 window on a 16:9 display leaves you some space for a tool panel or whatever.
Page width from mainframe line printers is 132 characters. The other option was a TTY with 72 characteers. There were some consoles that used track fed letter size paper but they generally were operators consoles.
The use of letter sized paper for printing code only appeared as a main option, generally, with PCs.
@Ren: You don’t know much about railway guages.
132 x 50 works for me, unless I’m feeling nostalgic, then it’s 80 x 25.
Oh, don’t worry, with the way programs are going so they run on on vertical smart phones the 80 line limit will come back.
Even on the desktop clients, Telegram uses 80 col limits.
As the older generations fade away and the new devs work only on smart phones, all coding will return to that standard.
Sounds like a terrible situation.
Who actually writes code on phones?
I don’t know of any compiler or other development tool you can really use on a phone.
Android development is done on desktop machines. iOS as well.
A phone has no keyboard, and the display is too small for concentrated work over hours.
If you add a real keyboard and bigger display to a phone you could probably do something useful on it, but then the argument about narrow screens doesn’t carry any weight.
Have you seen the speed current users can reach on their phones? Throw in predictive text and other modern shortcuts and that is a lot of input.
There are kids going through highschool that have never used a physical keyboard, yet can still do 80odd WPM on their phones. They just need to reach high enough up in the workforce and who knows what will happen then..
And yes, I’m mostly joking, but it’s an easy world to imagine..
I think predictive text will slow you down when coding.
I don’t know about you but I love having suggestions for the most likely variables or function names pop up in my IDE because then I don’t have to waste my time typing out the full thing. It makes it a lot easier to use descriptive variable and function names.
Does it? Stuff I’ve used is only showing you 10 char or so, so SettingsScreenTopLeftWidget SettingsScreenTopLeftSlider and SettingsScreenTopLeftRadio are all gonna look the same.
I thoroughly dislike correcting it. Once in a very blue moon it is handy when using a library with poor documentation (cough STM ‘hal’ libraries), but otherwise I’d much rather the editor just take the keystrokes as I provide them. I do find auto-indent handy, however, provided it’s not too ‘smart’ about it.
Throw OUT predictive text. First thing I do with any phone. They never guess what I’m typing correctly. I’ll make my own mistakes, thank you.
it’s handy for plausible deniability
Electra – I get your point. Since ’90 we rise the size of screens to the point where people demised usability of 8″ or even 10″ laptop. But then people start to write their CV on <10" laptops where half of the screen was barely usable keyboard. 15 years ago watching movies on a 15" laptop was considered silly – now 6" cellphones are just enough.
So I can imagine that with improvement of data input (voice recognition, word predictions) there actually might appear a programming language that will make use of that. But just like graphical programming it will have rather narrow usage.
On the other hand I (only) guess that even kids with highly developed both programming and "touch typing" skills don't use cellphone for any serious coding. Sure you can prepare nice document on your 8" tablet with screen keyboard. But whoever makes living on making documents finally buys keyboard and probably some "cursor driver".
I rarely write proper* code on a phone, but I often READ code on a phone.
I can study a patch, or have a quick peek at a GitHub repo whenever an idea or question occurs to me. I’m not using it for hours, just a few minutes at a time.
* I sometimes write a bit of pseudocode on a phone.
One would have to note that an IPhone 12 is almost the perfect size to fit straight into an IBM Card Punch for non-volatile data encoding.
Pick a number. 80, 100, 120
Use a different one each week.
The straightforward and fair way to go is to use a normal distribution centered on 132 with the choice selected by a pseudorandom algorithm with the unix epoch value as a seed.
I work at a company that (at one point) decided to go for 3 characters for tab because nobody was brave enough to tell the ~50% who wanted 2 or 4 characters that sorry, they were the losers in this particular decision.
At least it was spaces, not tabs.
The nice thing about tabs — you can choose how your indents look. Makes both the 2-spacers and the 4-spacers happy.
Tab characters can lead to problems with mouse select-copy-paste, which in some environments automatically changes tabs to spaces for display, and uses spaces to perform the select-copy-paste operation. The tabs are lost.
I recall reading a study that suggested 3.6 spaces per tab for optimum comprehension. May have been where 3 came from?
I don’t arbitrarily whack the lines short in my program code. The lines are as long as they need to be for the content they have.
If a line turns into a 2000 character monster, that’s a sign that there’s too much going on in that one line. Breaking it into multiple lines of some arbitrary length won’t help in that case. The reasonable thing to do is to break such monsters into smaller logical pieces that are easily read and understood.
That might mean using some temporary variables to hold intermediate values, but that’s more acceptable (to me) than having an impenetrable monstrosity that I have to scroll five miles across the screen or an impenetrable monstrosity chopped into segments of an arbitrary length and scoll five miles down the page.
——
I used a Fortran compiler back in the 1980’s that had fixed length (80 character) lines. You could make longer statements by putting a special character in the eightieth character spot to tell the compiler that the next line was a continuation of the current line. That sucked.
I had enough of that back then. I’ll take variable length lines and common sense in writing readable code over arbitrary lengths any time.
FORTRAN’s 80 character (actually, it was 72 plus 8 for a sequence number) line length is definitely IBM card derived. But Teletypes and typewriters were 80 character devices as well, because 10CPI monospaced text fits 80 characters on an 8-1/2″ page with margins. So I submit the 80 character width is older than the Hollerith card, and that it comes down to standardised typefaces and paper width.
But the “standard” page size in EU isn’t 8.5×11 inches, is it?
I grant you 80 columns is fine on a TTY at 10CPI, leaving 1/4″ margins.
Pretty damn close:
A4 210 x 297 mm 8.3 x 11.7 in
There used to be an odd size used in Canada that was (IIRC) 210 mm x 11 inches. Why? For cross border work. The shorter pages would fit into mailers and folders made to be a snug fit for the US 8.5 inch x 11 inch.
As I recall before the standard A4 came out, the letter size in France was 21cm x 27cm. I used the A4 size and its multiples when I started to work as a draftsman. When I stated programming that was with with IBM cards and we used the 80cols for our files because it was easy to create a bunch of test files from the keypunches (We even used discarded random cards to test validation algorithms … no Debugger on a mainframe!)
Erm, standard page sizes in the EU are bound to be in modern measurements, i.e. mm.
The really nice thing about them is that the ratio of the edges always defined so that they’re the same when the paper is folded in half.
longSide = sqrt(2)*shortSide
Sorry, by “EU” you mean the reasonable rest of the world except the USA?
Sorry, do you mean that U.S. A (letter) size (216 mm wide) is enough different from A-4 (210 mm wide) to bring into the discussion?
The 80 character limit in Fortran definitley came from the punched cards.
The 80 columns in the punched cards has zip to do with written formats. https://en.wikipedia.org/wiki/Punched_card#IBM_80-column_punched_card_format_and_character_codes
IBM went to 80 columns per card as a higher density version of earlier cards that had only 45 columns. The earlier Hollerith cards had various number of rows and columns (or just arbitrary patterns in the earliest cards.)
Human readability had bloody zip to do with the number of columns on a card.
Since the number of characters on a display is directly derived from the number of columns on punched cards, that sort of nixed the arguments about 80 character wide displays being in some way “optimal.”
80 character wide displays are based on nothing more than the physical characteristics of punched paper, the accuracy of mechanical punches and readers, and the arbitrarily selected paper size. The paper size selected was that of the common bank notes in the USA at the time the punched cards were invented.
If you are arguing for the continued use of 80 character line limits, then you are arguing for the continuation of a standard made for the convenience of machines from the early 1900s.
FORTRAN Code was entered in columns 7-72 which is only 65 characters. Cols 73-80 were sequence numbers. Cols 1-5 were numeric targets for GOTOS. Col 6 was for continuation.
https://en.wikipedia.org/wiki/Computer_programming_in_the_punched_card_era#/media/File:FortranCardPROJ039.agr.jpg
An ASR33 TTY only had 72 characters.
https://www.pdp8.net/asr33/asr33.shtml
Your lines can be longer because your identifiers are long. But if you often find that they sprawl because there’s also a lot of tokens, you may want to break them down for legibility and ease of maintenance.
I’ll bite.
At work we settled on 100 characters wide, max. There’s a few reasons for this:
– When comparing pull requests, anything longer than about a 100 characters gets a little harder to compare
– Really long line lengths (I’ve seen lines over 5,000 characters) are a bit of a code smell, in my mind. (Don’t mix so much data and code).
– The 80 character limit is just a bit too restrictive, and splitting lines for the sake of PEP8 or something similar often results in slightly less readable code.
The 100 or 120 character limit seems about right.
In general shorter line lengths are better, because they really do make programs easier to read. You can prove this to yourself by taking a document, any text document and just pasting it into an editor which wraps the text but allows indefinite line lengths, like TextEdit on a Mac.
You’ll find it much harder to read than the original text, formatted for A4; or even text formatted for a newspaper column.
That’s because as your eyes scan across the text, it becomes harder to know where to scan back to to get to the next line; and your brain will lose track of the text at the beginning of the line, because it’s in your peripheral vision.
Shorter lines are easier to follow because more of the program then fits in your field of view: a block of text rather than a long line. Also shorter lines are easier to follow on text windows that aren’t so wide – it’s means you’re being kind to other programmers who don’t have your massive monitor.
What we have here, with the abandonment of the 80 character principle is an aspect of the pop PHILOSOPHY OF BIGGER NUMBERS oooohhhhhhh! “Bigger and higher and larger is always better” So, because we have windows that can do 4K or 8K and screens that are super wide we think: yeah, longer lines, bigger numbers that must be BETTER.
But it’s not, because it fails to take into account physiology and sometimes just plain physics. Like, beyond a certain size, a bigger monitor just means you have to place it further away which means that you need bigger text, so you’re not gaining anything.
Ultimately, though, Linus’ argument is misplaced. He’s taking an aspect of the limitation of the representation of program text in ‘C’ (i.e. there’s no built-in rule about how to format multi-line program lines) and using it to justify something that’s actually bad from a psychological and physiological viewpoint.
So, no. Stick to 80 columns if at all possible. Be kind to other programmers. Fix ‘C’ or other editors to make it automatically readable.
Longer line lengths make a program easier to read, in my experience. Because you never read the whole line, except when you suspect it to be wrong. So it actually reads quicker, because you skip to the next line and know up front that it’s not part of the previous line.
It’s different for ‘if’ statements with many && and || clauses. That should always be split on multiple lines, in my opinion. But that has nothing to do with basic readability. A complex ‘if’ statement should be visually broken up into its components to make it easier readable. And group with () if possible, because you WILL make a mistake with operator precedence at least once in your life. And even if you won’t make that mistake ever, your automatic merge operation will make a mistake at least once in your life.
Thumbs up. Totally agree.
I also put everything into parentheses in equations and basically don’t care about operator precedence. For the sake of the guy who had to read the stuff the in-the-past Calif wrote on his mental high, and this could even be the in-the-future Calif.
If there are larger subparts of an equation, like ORs that are later ANDed, or subtotals, they will be broken up into a separate line.
Especially important is this with Java (or probably any?) functional interface- it’s very hard to read and understand the code if you not shorten up and maintain some kind of discipline. For me, it is (normally) using only method calls in functional expressions, thus leading to load transfer objects with a lot of access functions.
Usually, I treat long lines as I treat long function bodies- I break them up. Into smaller methods, or by replacing a large number of arguments with an object.
Not driven by a number of characters but by a thought like “WTF is going on here, and I have to scroll up / down / sideways to see it”.
Together with the explaining variable and method names I use, this will reduce a method’s signature to a maximum of 4 or 5 arguments (Or so, this is not meant to be a hard limit). I think the discussion on line length does not really address the point, it’s more about readability of code.
Code is usually much more ragged than English sentences, so the “scan back” argument is null. Also, coders frequently use blank lines to separate logically coherent entities into visible blocks, again defeating the “scan back” confusion.
Personally, I use 120. But honestly, for me this is a non issue. I’ve worked at places where there is a strict 80 char limit, and was perfectly happy.
Ofcourse when limited to 80 chars, I do go into a 90s style Hungarian naming convention. (pu8MatImg anyone?)
120 Columns x 30 Lines with a decidedly large font on a 32″ 4K monitor. ends up being 1920x1080ish in 1/4 of the screen.
Not if it pulls its models off big data based on Github.
Whether it ends up writing the program you had in mind is another kettle of fish, though.
But having watched people hacking at Java with JetBrains and hitting the TAB key until the type checker is happy, I guess this is industry standard anyway.
I still use a mechanical typewriter from time to time.
It’s really useful when filling out documents.
And I like ASCII art and Packet Radio, so 80chars/line is enoug for.
Heck, I’m glad the days of 40chars (CGA, C64)
are long gone.. That was really limiting!
On DOS, I could have had ~132 chars/line by using
The mode utility of my ISA VGA cards, but I didn’t
like that. It made everything so difficult to read.
Perfect. Thank you for this example of the stupidity of arbitrary line lengths.
You’re welcome. ^^
I second what Mr. Torwalds said about
132 characters being available since the 80s.
The early Super VGA cards (Paradise PVGA,
ET-3000, Trident 8900, OTI-037c..)
all had such options in their mode utilities.
However, personally, I never liked these modes.
They made text fuzzy and hard to read.
80×25 on the other hand, was fine for
my simple mind. It was like reading a book
or a manual.
DOS Shell and later versions of Norton
Commander also supported these super
long columns, if my memory serves me well
.
And IDEs of Quick Basic, TurboPascal, too.
Yus, you wouldn’t wanna do it on your bog stock 14″ monitor, that only manages 800×600 at 56hz… There were spendy 19″ ones around that felt like sitting in front of the fishtank at the zoo at the time.
Well, yes I indeed hat got a wimpy 14″monitor only.
It was an IBM PS/2 model, in colour, 100% Analogue and fixed- frequency..
My father however,had a hot-rod 386dx40 PC with 26MiB of RAM,Fax Modem,HP Laserjet+ And 20″ monitor.
He also had got a Super VGA card
that could easily set 132 chars/line via
mode utility..
Tell you what? Neither of us made
us made of it much.
Because 80×25 was fine for us.
Programming in QB, Turbo Pascal etc.
worked fin in 80×25. We had no need
for these very long lines.
They were just eye straining, not helpful
in improving readability.
Personally, I was somewhat glad
That 80×25 existed. If you ever had
To work with a homecomputer, you’ll
Understand.
I spent many nights reading textfiles,
source codes and so on from the 80s
and 90s using the original
Norton Commander..
To this very day, I’m still using NC
for this. Even on the Raspberry Pi
By the help of DOSBox! 😁
Later on, I also dialed into ANSI
BBSes using Bananacom and the
Terminal from PC-Tools’ Desktop.
This was mind-blowing,
IF you were previously doing
RTTY and Packet-Radio in 40×25
only using these limited homecomputers
Of the day.
Speaking of the PC-Tools,
It used TUI, which uploaded a custom
VGA font into VGA memory.
This was much more efficient and
Elegant than the frame buffer GUIs..
https://en.wikipedia.org/wiki/VGA_text_mode#Fonts
I prefer long lines since I usually have much more horizontal space than vertical. Most editors can be set to wrap the line at whatever size you want so it shouldn’t matter.
For me, 80 columns looks ridiculous and inefficient to read on current screens. I usually works with 120 or 140 characters.
Non issue for me. That said, I try to keep within 80 (habit) but some code lines will flow over. Sometimes I leave it because it is a more readable than splitting the line. One must use some common sense! Block comments are always keep to 78 character line lengths. One company we supplied systems to (back in the 90s) required us to print out the source code and supply that with the product as part of the documentation (big binders). So we did go through and make sure most of the code base was within 80 chars at that time. Point is there shouldn’t be a enforced standard… Up to the user in my opinion.
Good point: If strictly sticking to 80 columns causes a single word in a otherwise single-line comment to move to the next line then it seems a bit silly. Also, all that white space on the left hand side of deeply nested blocks is available for overflow. Although deep nesting probably isn’t that readable anyway.
You need a proper standard so anybody reading the code (especially skim reading for the bit relevant to them right now) can comprehend it easily. Though much of that is in the indents and other white space breaking up the logical units not the length of line.
For me the standard should be consistent but not stupidly strict on line length – basically allow lines longer the recommended but only up to a point. Allow say 5% of lines to be longer perhaps with a fixed maximum length.
There is something to be said for lines that are short enough you can take the whole thing in and not forget the start of the line and loose the next statements context. But 80 characters is really damn short and leads to variables with meaningless names and a much smaller set of possible variables so reuse and confusion about similar variables will be a bigger issue.
If we are on it now, lest settle the dispute about line endings and tabs vs spaces as well.
*runs away fast*
Even VI supports more than 80 character line lengths! Emacs sucks!
Anyway, tabs vs spaces does help to transmit fewer bytes over a serial line, making screen updates faster when you use tabs. That is… If you’re still using a 1200 baud terminal. :D
Always set the ‘tab convert to spaces’ if present in editors. Don’t use tabs (except make files where required). It is to aggravating when moving from system to system, editor to editor and or source code from outside our company. Without tabs, code always looks the same and when adding code the cursor isn’t jumping around. I don’t know how many hours I spent over the years removing them and reformatting the code properly (company standard) before they were all ‘out’. When I was a supervisor over our software team, I discouraged the use of tabs in our code base for this reason. So all settled here. No tabs. Period.
Lol and here i keep converting those misaligned spaces back tot tabs. So much frustration with space based code bases.Tabs. No spaces.Period!
Get rid of all the ugly white space already and just have one pure information stream, no tabs, no line breaks and wrap it how you like :-D
What’s the problem with spaces ?
@oliver: In my 25+ years as software developer, I have had enough experience with tabs vs spaces to standfastly contradict your opinion. Tabs have always been a source of dismay for me and all my colleagues. Since I stopped using tabs and started using only spaces, I sleep better at night, I yell less at other people, and my bowel movements have improved beyond belief.
“So all settled here. No tabs. Period.” Working for you must be luscious. Especially for Python programmers.
The guy who was assigned the task of fixing tabs, or worse, the guy who didn’t delegate it, is not the guy I want managing anything.
You knew how to code and didn’t write a program to convert tabs to spaces?
I use 80×25 terminal windows, probably will until I die. I also use a 8×16 font I ripped from a VGA bios 15 years ago, and I scaled it up by hand to look good at 12×24 and 16×32.
I really like 8-character indent and 80-character lines when writing C because they provide provide such a direct heuristic for noticing poor factoring decisions. In Java, though, it’s down-right suffocating because they waste the first tab, and then every identifier is 3 words long, and on top of that needs to be qualified with 3 levels of class names. And so many Java idioms introduce another layer, or 3 layers, of {}, which I like to indent…I’ll find myself writing simple well-factored code with 6 levels of indent before it! But I don’t mind long lines. nvi and less make them “ugly” when they’re line-wrapped but it doesn’t bother me. The best kind of rule is one you don’t mind breaking.
Every now and then I use a bigger window size and I always come back to what some of the other comments say — 80 characters is just a good readable width. Makes the low-level visual comprehension task a little easier. Even if some of the lines are wrapped.
Of course, at work we still use FB80 — emulated punch cards — for a lot of things because we work with mainframes.
Oh, that PC font was truly awful. Designed in the era of pulse shrinking on the CRT, so the vertical strokes all have a bit of thickening – not a good choice for an LCD. There were a bunch of Human Factors guys in a separate building in Boca on the north side of Yamato Road who spent ages on it. Since I was somewhat involved in the design of text and graphics display products for IBM, I spent some time with them on various improvements – none of which saw the light of day.
These days, with CRTs largely replaced, we can put a decent font on. We’re much more educated about multi-lingual code pages as well.
Having said that I do occasionally use a good old 3270 font from the IBM mainframe days – clearly distinguishes 0 from O amongst other typo-ready confusions.
Just for grins, I thought I would check what size my terminal windows are currently on this beast here, and, will you look at that. 132 columns by 34 rows. That was just stretched by me until it looked right, from the default 80 x 24.
If you’re in the market for something a tad more modern, check out Fira Code or Fantasque Mono. Both are my absolute favourite coding fonts, distinguish O0L1 etc very well, and are just quirky enough to be fun to use in monospaced modes. Plus they have ligatures for !=, if you want that enabled.
All my xterms (yes, I still use those, had too much problems with more modern terminal emulators) are 80 characters per line when opened. If I need more I can resize them on the fly but for most stuff 80 characters per line works well enough.
I’m looking at my screen right now, working with Xcode, and actually wondering what the line length of my current view is. So, it turns out to be 280 characters (UHD monitor ;)).
And looking at the actual code, the longest line length of the source I’m looking at right now, is 112 characters. So I could add another 168 characters before my editor scrolls.
But then I look in Gitlab at a merge request, and notice that it shows only 80 characters, even if I make the screen wider.
I would ask the Gitlab guys to please get rid of that 80-characters limitation. It’s just weird.
Ok, maybe a newer version of Gitlab has this already fixed. We need to update.
But basically my opinion is: if you’re still using a screen that can not represent more than 100 characters horizontally, maybe you should consider upgrading.
Not speaking about working with vintage computers, of course. :)
But all fun aside. I guess I would set a limit at around 160 characters, which is still readable and viewable without having to scroll, on a 23″ 1920×1080 monitor. Such a monitor is probably the lowest end these days.
This is the right answer!
Wider monitors (because, cinema) and more verbose coding styles make longer lines reasonable.
Coding on a 16:9, when most of the width of the screen is wasted… grrr… It makes it harder to grasp a whole “page” of code at once. Heck, even single functions don’t fit on the vertical screen anymore — looking at you Doxygen.
Either bring back my 4:3 aspect ratio monitor, or let me write 120 characters in a line. Or get off my lawn!
My editor window @ 120 chars is about half the width of the screen. The rest of the screen isn’t wasted, because I use it for other programs.
This. I just measured 119 characters on the LHS and the RHS is for the browser.
Hmm, me and NASA disagree with you here (can’t remember the source) but they did research about this a few years ago and long lines actually make it hard to read and introduce more bugs. Had to do with having to more your eyes too much and difficulty on brain processing or some such…
That’s probably true for full paragraphs of long lines, but when I look through my code, I see that most lines are around 40 chars, some are 70-80, and in a few places they may be over 100.
Ah, ah, but what if, what if, you’re gonna need to split that in 2 because two people are using the machine at once huh? ;-)
https://www.youtube.com/watch?v=u8qgehH3kEQ
I have a quote in my computer quotes collection that, in this medium, translates something like this:
> Emacs is better than Vi
> MacOS is better than Windows
> Unix is better than VMS
> C is better than Java
> Let’s start the religious wars!
I’m sure many here can relate and there is certainly no end of code formatting related issues that could be substituted in there. I see a lot of code of varying line lengths, especially in the Open Source realm. And it mostly doesn’t bother me. Really just depends what display I’m at or what I’m tucking around it on my desktop as to whether or not I have to scroll, which makes for a minor irritant.
I don’t say this often about Linus, but he’s definitely wrong on the VT100 score. Every stock off the shelf IBM style PC, including the two new MoBos I bought this year, has a native 80×25 screen. Booting Linux on these, without a specialized screen driver, still gets you an 80 col screen. Not to mention other OSes. For me, personally, I discipline myself to stay within 80cols simply because I’m likely to be looking at the code someplace where I’m back to 80cols or even less: standard color composite video can’t render 80cols properly and is usually reduced to 40, maybe slightly more (various PIs with composite video out), various small displays attached to PIs have less than 80 avail cols, going to the data center and plugging in a monitor, printing, … I do miss my wide-carriage in condensed print (~250cols). :-D
It seems human nature to want to use any available resource, without concern, until its gone. I figure its best to limit things, in this case line lengths, somewhere. I’ve mostly stuck to 80cols because of all the places I seem to hit this limit. But still there are times I can’t resist and add those few extra chars to the end of the line… :-)
If you are writing a page on a Commodore 64 for school or college, the instructors might take issue.
If you wish to view a page from a Mac or IBM PC, 40 columns might be a problem. Old style BBSs had that problem but you could read stuff written on a BBS with IBM software. And there was an issue with line feeds or whether your computer did not have line feeds.
If you are converting pages from 80 columns to 60 columns, you might have problems reformatting everything.
Trying to read some of these online newspapers (rags) on a cell phone are hard because you have to resize everything.
The question is really: how much space do you need to do something? If you are putting together a kit from the internet and you need to read the internet to put something together and see a picture, how much screen space is needed or do you have to constantly scroll, resize and page down and so forth?
A paper white kindle might do the trick for people but most books at the library have a common range of sizes.
On one of my smaller, non-main monitors emacs can fit about 138 characters on a line so there you go. The new limit is 138 :-)
Seriously though, while it would be arrogant for me to think that MY personal limit on my personal hardware should be the hard-fast rule for everyone else I kind of feel that choosing space characters instead of tabs for indentation is exactly as arrogant as that.
A good code editor should have an option to choose just how wide of a whitespace to display on the screen. We can each set our editors to display the same tab-indented code to the widths that fit our personal tastes and displays. Everyone wins.
The unfortunate issue that I’ve run into with whitespace has to deal with alignment between lines.
Code isn’t just viewed in an editor, but can also be viewed in the command line, which has tabs at 8 spaces.
There is a simple and unambiguous way to handle tabs that could be used by code linters to make everything look correct for everyone, regardless of their preferred with of tab:
Tabs are semantically infinitely wider than a space. Indents for semantic purposes are tabs. Indents for alignment are additional spaces after the required tabs.
Emacs’s smarttabs makes all my C code look equally good/bad regardless of whether I’m viewing it using 2 spaces per tab or 8.
I don’t understand this “tabs for alignment” vs “tabs for indentation”. It always comes up in every discussion of tabs vs spaces for indentation.
Yes, most modern fonts are variable width. Different characters have different widths. So if you have whitespace in the middle of a line, even if it always starts at the same column number it might not line up.
So what? That has nothing to do with indentation! Indentation whitespace always starts at column 0 and ends at the first non-whitespace character. So long as the editor uses a consistent spacing per tab and the user uses a consistent number of tabs per level of indentation (it should be 1) then the beginnings of the code should always line up perfectly within it’s level of indentation.
If you are lining up something in the middle of your lines of code that is something else other than indentation and probably is not a job for tabs.
The only way I can see this argument making any sense at all is if you are putting comments at the ends of your lines and spreading them up and down lines that cross levels of indentation and you want them to line up.
The answer to this is easy. Just don’t do that.
Or maybe you are drawing ASCII menus and want your header line to line up with your content but your content is indented within a for loop? Hey 1985, since when did one use indentation in BASIC?
Would you honestly throw away a great way to allow everyone to see the code the way they want to see the code in their editors because of a quirk in how it cats on the command line?
Besides. If viewing code directly on the command line is your normal mode of operation, how difficult would it be to write a little cat utility that simply outputs a text file to the console but translates tabs into whatever width you prefer? This sounds like a single evening homework assignment for an introductory computer science course to me. Or about 15 minutes of no-brainer for anyone more experienced than that and I am including the testing.
And that was assuming there isn’t some arcane terminal configuration option to change those 8 char tab widths. I’m guessing there is.
I use spaces in my code, so everybody can already see the code exactly like I intended.
> a little cat utility
You mean ‘expand -t’
For years I just click on Terminal -> 132×43 and stick with it.
I’m looking at log files and long lines constantly, sometimes I prefer :set wrap and other times it’s easier to parse with :set wrap!
Yet other times it’s convenient to have :set number, but most of the time I prefer :set number!
When using Eclipse the line numbers come “for free”.
Ever time one of these code formatting discussions happen, the term readability is thrown around. As far as I can tell, there is no metric for this concept. The concept of ‘comprehension’ sometimes gets thrown in which can have a metric associated with it, but typically the test methodology is flawed in some way.
Name cases, white space usage, line lengths, vertical spacing, comment styles, comments considered useful, etc all seem largely cultural at this point. At one point in the distant past, there was at least something of a technical argument. Take the punch card example here. But why was the card set to 80 columns? That can be chased back to automated looms. I’ll bet that chases back even further to some limitation of the cloth making machinery.
Chase down the info concerning tab sizes (particularly, why there is no standard) and learn about typewriter manufacturers.
It seems to me like most people learn some code style based on the specific project they started with early in their careers and that becomes their preferred coding style. Everything else is crap and their’s is the obvious best choice.
The thing is that these formatting choices have knock-on effects like the way names are selected to meet a stylistic limit.
Maybe one day we will have ML based code formatters that can do more than translate line lengths, curly brace styles, etc, and we can store code in a formatting agnostic way. Until then, we must rely on the flexibility of the human mind.
Facepalm. There’s nothing more frustrating than trying to change the mind of an AI that’s trying to “correct” your style.
But also, the 80-column width did not come from looms; it came later, with IBM’s implementation. I wasn’t able to find a definitive answer for how many columns a Jacquard card had, but since it had a column for each warp yarn, I would think that there would be different card widths for different looms.
I believe the 80-column width came from the early printers IBM was using, which were based on modified office typewriters.
The 80 column width was pretty much driven by the technology in the 1920 and the size and quality of the card material.
https://en.wikipedia.org/wiki/Punched_card#IBM_80-column_punched_card_format_and_character_codes
IBM needed higher density cards and went from 45 columns to 80 columns because that’s what they could make work. It has absolutely ZERO to do with typewriters or page sizes.
The restrictions were the size of the card and the size of the holes they could reliably make and read in the cards.
You have your cause and effect reversed. According to the article you linked, the original 45-column round-hole card, the “Hollerith” card, was designed for the requirements of the 1890 census, and IBM’s later development of the 80-column rectangular-hole card was driven by applications that needed more information in each record. They didn’t come up with 80 columns because that was all they could get from the existing technology; they advanced the existing technology (by using rectangular holes that could be spaced closer together) to meet the need for 80 characters of data. Which in turn was related to the amount of information that could be printed on 8.5″ paper. Collating machines at the time were programmable using plugboards to sort cards according to data in specified columns, then tabulate data from various columns on the card to print to specified columns on paper. So what could be printed on paper was what drove the 80-column requirement.
I often mix text and code snippets (literate programming) and feel unwell with more than 72 CpL for text. My favourite XTerm width is 102 chars, maybe because a borderless maximised one had that size in SVGA days? Old dogs & new tricks = no go? A bit overhead to the used space (editor adds borders, indentation or such) quickly strips it down again.
To keep font sizes not too far apart, I settled down to 80 CpL for code with the same effective width as the 72 CpL for text in GUIy environments. This mix looks fine printed, in a browser and as PDF. In a terminal I just ignore my code being that bit wider than the text. Wide code is easier to follow than too wide prose, but unluckily today the nets are full of lines of more than 120 chars and I think, that converges to unreadable. I shouldn’t have to resize the browser window to get readable texts! But that converges to different topics: Browser design, text formats without implicit maximal line length, … yada yida yoda… or such…
72: the compilers I use ignore anything after that. At least the modern ones warn you! Sometimes even in mixed-case, too.
Yes, I still use Fortran-77. You’re going to regret those long lines when your eyes get to my age. 18 pt is about the smallest I can comfortably program on. B612 Mono’s nice for legibility.
Even the ancient PCs could do 50 or 60 lines by 132 characters – this was the mid 1980s on my 3 head Linux system (VGA, Hercules, 8514 vesa bus).
132 is reasonable, but I’ve continually pushed it by using the 8×8 fonts on the console screens. I forget how many columns on my 4k monitor it translates to, and I’m waiting for a 65″ 8k to go on sale.
You didn’t have a Linux system in the mid 1980s:
https://en.wikipedia.org/wiki/Linux
1991.
You might have had a computer from the mid 1980s that you ran Linux on, but you didn’t do it in the 1980s.
Good point, I also want to know in which universe IBM supported VLB at all, and where 8514s were available before the late 80s, or even how it had VLB before it was introduced.
I am also not sure how one would get a VGA and an 8514 (Which is what defined VGA) to co-exist when they’re going to want the same IRQ, i/o range and shadow RAM. Though I suppose it could be cobbled somehow if one card was 8 bit and one 16 or 32bit.
I used to use DECwriter III’s and Teletype 43’s at uni, when the video terminals were all taken. Got quite familiar with editing my assignments using VMS Edit/EDT in line mode on them, and they were 132-column machines.
Both of those terminals date to the mid-late 1970s and were 132 columns THEN.
Why, thirty five years later, can’t we have code going to 132 columns and beyond on our ubiquitous wide screens NOW?
Because we have people like the Python PEP-8 lint folks deciding you should wrap your lines to 79 characters (yes LESS than a punched card!), it just boggles the mind and to be honest I think gives Python – a language that relies on copious tab spacing, no less – a bad look.
The 79 character limit came about because some 24×80 terminals had a bug which would scroll the screen if you had a character in the last position of the last line. To avoid that, we limited lines to 79 characters.
The 80 character limit was NEVER a mystery.
Anyone who’s worked with the abortion that is XLST knows how long lines can get. I once collaborated with a guy who needed to see the line of code as an actual line whereas I was happy with the wraparound version; different people are wired differently.
I don’t like scrolling right to continue reading.
What this unit can’t stand is it once worked for a guy who insisted that PHP be indented, and indented, and indented ad infinitum.
Made it hard to read my own code. My personal standard is everything is left justified.
OK first off, any D-Dialer’s here? D-Dial was a 7 line chat system that ran on an Apple //e.
The program used 40 columns, and the extended 80 column card was used to store “E-Mail”
which was a 256 character message. There was a command where you could set your width if
you were a caller. Before I ran my own station, I’d use Proterm. The standard I used at the
time was 80 characters. Now, being that the Commodore 64 and Apple //e machines were
designed to output to a television via a video signal, the resolution of your standard
television back in the 80’s left something to be desired, hence the 40 character width.
So (he says with a wicked grin) is it 0-79 characters or 1-80?
With Windows I tend to prefer monospace fonts. Back in the 80’s when I first got an IBM,
there was an editor called “QEdit”, the Windows equivalent being TSE or The Semware Editor.
I also do not like tabs in code. I prefer 2 spaces. I also like white text on a black
background. There are times I do miss having a D-Dial station up and running but with the
internet, D-Dials have gone by the wayside. Although I have an Apple //e, I do miss the
green screen monitor with the “cloth” over it to reduce glare. I also love messing around
with 6502 and for that, I stick with a 40 character line as for me that’s easier.
It all comes down to preference. Look at the graphics of the original DOOM game compared
to its latest incarnation. Better graphics cards and screen resolution have upped the game.
There is a youtube video titled “Can we see in 4k?” which was an interesting watch.
As for me, I have a 23 inch HPw233h monitor, it works and although I’d like a bigger one,
the old saying goes, “if it isn’t broke, don’t fix it”. As I said, I prefer monospace fonts,
why? Because everything is nice and tidy. Everything lines up, and I can use whatever line
length I want. I prefer 1-79 actually. That works for me.
–> +
#1[T1:Deeply Shrouded:#249
(Sorry, couldn’t resist)
I think the “cloth” you refer to went away when LCDs took over, because LCDs had an inherently higher contrast ratio. These were common on oscilloscopes before PCs were even a thing – I remember using HP 1700 series scopes (in the form of the military version, AN/USM-338) in 1976 that had these metal mesh screens that made the background very nearly black, which was a good thing for the HP CRTs that weren’t very bright.
You realize, I hope, 1-79 is only 79 characters.
Your non-use of paragraphs made me not read your post or care about anything you say.
I think it is all fine until someone decided to write ridiculously long line. Often a result of multiple AND/OR conditions or assignment that has multiple “boolean ? value1 : value2”. To be frank, I think both situation calls for line breaks. Another situation is function that takes 5+ parameters. Again, I think that’s an issue with the designer, who want to remember parameter 3 means what? So the bottomline is that, shorter lines is meant to make code more readable and writing long line just makes it hard to read, which means more difficult to manage.
If you are using those damned ternary operators, then you deserve the mess you get.
Stop it. Now. Ask to have the stupid things removed from any language you use.
Dumb comment:
80 characters per line?
Back in my day we only had 32 chr’s wide!
And school was uphill both ways in the snow with cold gravel for breakfast.
When there was no crawdad we ate sand.
For the majority of code 80 chars is fine.
Using longer lines for the few lines it seems useful, makes the use of the text area less uniform. Most of the right side of the screen will be empty, which is still a waste of screen area, or you have to resort to horizontal scrolling or line wrap.
Using long lines for complicated calculations is also not a good practice.
Using multiple lines with intermediate variables makes code easier to read and errors easier to spot.
Then there are things like 3-way merge in which you want 3 versions readable next to each other.
I have a dual monitor setup at home, and one of the monitors is rotated, thus 1200 pixels wide and 1920 high, which gives me more then 100 lines readable on my monitor. I also have to struggle with screen area for other things. For example:
* Web browser for looking things up.
* PDF’s for datasheets.
* Sigrok / Pulseview for debugging.
* I’m a software developer, and I don’t use IDEs. Command lines and Makefiles for everything.
* I usually have four windows open at once: source, header, library, and build, although sometimes the library window gets used for something else.
* I arrange these the same, whether I’m using Windows, MacOS, or Linux.
* Once upon a time I used EMACS, but then I realized that I didn’t really want to learn another language just to edit. Then vi. Then vim. But vim has caught me with modal nonsense too many times, allowing me to accidentally delete things without noticing, so now I use gedit, which is the only sensible editor I can find that works well in Windows, MacOS, or Linux. It can be sized to arrange along with my terminal windows, so I use that for source and headers, and two terminals for building and other uses.
* 80 columns makes these fit perfectly on a laptop screen. Lines longer than 80 columns make me have to physically scan from the end of one line to the beginning of the next. This has NOTHING to do with screen resolution – it’s about how big the text has to be to be readable on an 11″ screen.
* Long indents are useless – I indent two spaces, and don’t even bother with using tabs.
* Using a consistent line length means my source editor doesn’t end up re-wrapping lines.
* I started with 72 lines because I was working on Teletype ASR-33 and Datapoint 2200, which was a glass teletype, even down to not having lower-case letters. When I later moved to 8-bit computers, I was usually limited to 32 or 40 columns, which was REALLY cramped, and I find now that if something doesn’t fit in 80 columns, it needs to be split into multiple lines anyway.
The really ironic part of all this to me is that the LKML mobile site itself ends up doing terrible word wrapping when displaying messages on my phone. Which kinda proves the point. If you like word wrapping that much your text editor will be happy to do it for you and the rest of us can actually try developing something. I mean just because GRRM still uses WordStar 4.0 doesn’t mean he should expect his editors or publishers to deal with it nor should any aspiring writer think it will help them write (or not, I wonder why) the next Game of Thrones series. Ws4, 80 columns strictly iirc. Welcome to 87..
i shouldn’t have to read more than the first paragraph to know what the article is about. in this case i had to read the first four. brevity is a lost art. work on that.
that said i agree with linus. a lot of oop languages you might have to have 20 levels of object hierarchy just to get to the thing you want. that can easily eat up 80 characters. id love to see programming languages include some kind of object localization so you can grab members without having to go through the whole damn object tree.
“id love to see programming languages include some kind of object localization so you can grab members without having to go through the whole damn object tree.”
All of the OOP languages I know of allow you to create intermediate variables that refer to any level of a hierarchy. If your references are taking up a whole line or more, you might want to look into this. I often have to decide, when my lines are getting too long and I’m typing the same 20 characters multiple times, whether it’s time to throw in another variable instead.
But to address this as it applies to the topic of this article, it’s also acceptable to use a whole line to specify the leading part of a hierarchical identifier. For example, instead of
function(thingy->description->graphic->pointlist[n]->x, thingy->description->graphic->pointlist[n]->y)
you can either do:
point = thingy->description->graphic->pointlist[n]
then
function(point->x, point->y)
or you can do
function(
thingy->description->graphic->pointlist[n]->
x,
thingy->description->graphic->pointlist[n]->
y)
Its typically called “with” in some languages:
with(obj1.obj2) {
cout << name
}
This is what it might look like in C++ or similar language. The "cout <<" line would spit out the value of obj1.obj2.name. C++ really needs this feature. But maybe its already there just not in my compiler yet.
I should also mention its a feature that starts its own religious wars too. :-D
Imagine the with() clause scrolled out of view.
And you have a couple of these.
For me no way to go. I would put the stuff in a function.
why the F is this even a conversation today? for decades one could set the line length to whatever you want in any terminal application. for those not using a terminal application and doing raw boot you can set it in your boot manager / system startup of choice.
Linus doesnt know I am going to boot a linux terminal on a ultra wide 4k or a MDA display, is that not the point of linux? to let the user set up what they want?
But the problem is, Torvalds is not calling for a change in a standard. He says that 80 columns is no longer relevant, and he has a point when you consider that a lot of basic Unix commands return values formatted in more than 80 columns. So his point is that 80 columns is unnaturally restrictive, given the size of screens that developers are using today. And he even acknowledges that there is still such a thing as lines that are too long. But he refuses to draw a line and say, “if you want to play with the big boys, you should be able to handle line lengths of “. Which is absurd, because it just guarantees that the guy with the biggest screen wins, and everybody else has to look at the wrapped lines from HIS code. I don’t think he’s really thought this through.
That should have been ‘line lengths of “n”‘.
> the guy with the biggest screen wins
No, because nobody wants 300 column code, even if they have really big screens. For example, I have my editor window set at 120 columns for my personal code, even though my screen is twice as wide.
And if a developer writes ugly wide code, it can be refused by upstream maintainer.
Of course. But what Torvalds WROTE was that HE shouldn’t be required to limit his lines to 80 columns because of what OTHER peoples’ hardware allowed. That is, he shouldn’t be required to comply with a standard. In fact, he said,
“If you or Christoph have 80 character lines, you’ll get possibly ugly wrapped output. Tough. That’s _your_ choice. Your hardware limitations shouldn’t be a pain for the rest of us.”
It’s not that Torvalds wants to write 300-character lines; it’s that with HIS hardware, he is comfortably able to put six editor windows on his big screens, with well over 80 columns in each.
Again, he did NOT suggest an alternative number as a new standard. He just said, “many of us have long long since skipped the whole ’80-column terminal’ model’.” To me this implies “whatever I can get to fit on my screen,” should be fine, because he doesn’t want to be pinned down to a specified style.
I realize he’s Linus Fucking Torvalds, but to me, this is just arrogance. He says that “I don’t want to see patches that make the kernel reading experience worse for me … based on the argument that some odd people have small terminal windows,” implying that it is somehow painful for him to see code on multiple lines that could have fit on one line. Well boo-hoo. Excessive eyeball flyback, maybe? I’m sure that’s much less painful than seeing code chopped and wrapped because some jerk who uses multiple 40″ monitors can’t be bothered to accommodate those who work on typical computers.
This to me is similar to developers who buy the latest, fastest machine and max out memory, because working on computers is their livelihood, and then when their software doesn’t work on more average machines, say “oh well – just buy a better computer.”
On the contrary, it would be arrogance of the small 80-column minority to force their arbitrary limitations on everyone else.
> those who work on typical computers.
80 column displays are not typical. I use a single 22″ monitor, which is nothing special, and I can put two 120 column windows side by side.
Then you’ve got better eyes than mine.
If you ever work on a programming team, you’ll learn the value of consistency.
Pah! Humbug! 40×25 is where it is at! Dark blue background with bright blue letters surrounded with a bright blue border.
Dumbest color scheme ever devised.
Yeah, lower the contrast so they’re one or two blue tones apart for TEMPEST resistance LOL
If electronics and programming are not scalable, you leave a customer stuck or looking for another solution.
The size of a screen is good for what it is intended for but there is built in obsolescence if cannot adapt or be reused.
Contractors always want clients to pay for updates but leaving customers in the lurch is not a good business model.
Its great if a product is only needed for one thing but it is trash when it cannot be made to be recycled into a scalable product.
You can print more than 80 columns on letter sized paper. It’s called printing in landscape mode. I hardly print code today but when I did that’s how I did it. Also used 100 columns or so back then. Now use 120 or 125. Can’t remember which.
Harrison Bergeron. ‘Nuff said. Those in the know, know.
I use a soft limit of 80 (using a highlight column in vim) and wrap block comments at this width. Code I allow out to around 100 columns. This is because I run an 8×5 font on a 1920×1080 monitor which gives 320 characters overall. I split my workspace into 3 panels (with the old VGA standard of 640 pixels) giving just over 100 characters width per panel, but a couple of columns are consumed by diff markers and whatnot in vim.
This sizing also conveniently gives 2 panels on a 1280 monitor which is the width of my second monitor, and also looks just right on my laptop.
This seems the best compromise to me.
Oh, and as an added bonus I can do three way merges nicely on the one screen with all three versions scrolling together side by side in vim, which has been very handy.
~60-lines of code at issue in Boeing 737MAX max module size investigation. http://www.prosefights.org/irp2020/windscammers12.htm#faaappeal
TL;DR: crackpot speculates that a number of high-profile airliner crashes were caused by malware, in turn caused by software modules greater than 60 lines. In the link, the crackpot, who claims to be a “co-author” of 767 software, documents submission of a number of FOIA requests, on the unsubstantiated basis that large software modules can be used to hide malware.
This is utter rubbish, and also not pertinent to this discussion. If you have a million lines of code, it makes ZERO difference whether it is one module of 1,000,000 lines, or 100,000 modules of 10 lines each. Source code is not analyzed by module, but by function. Doing a line-by-line review of source code is exactly the same for a large number of small files as it is for a small number of large files. If one desires, it is just as simple to hide malware in a program in the form of one module out of many, as it is to hide it as a set of functions (or even within otherwise legitimate functions) in a very large module. While it is easier to hide malicious functions in a million lines of code than in a hundred, the length of individual modules (files) makes absolutely no difference.
atbillp37: if you believe that there is information in this tome (a single large document many times larger than 60 lines) to support your claim, you should quote the applicable sections instead of expecting a large number of readers to repeat whatever investigative work you have done. Hint: they won’t.
I love it when someone makes a definitive statement but does not have the courage to back it up, and and worse hides behind the brave facade of “I ain’t a gonna do your research for you”. You lay down the card, then Bub, you back it up. You would not have lasted 5 seconds on the boats.
Wikipedia is NOT a reliable source to not to your research for you, by the way.
An interesting observation:
I am learning Python via PyCharm in an effort to help stave off the mental effects of old age. PyCharm throws PEP8 line errors at 120 characters for some reason.
I do find this amusing – reading the comments fervently pushing 80 chars … on a page using 110 – 130 chars per line. Having lived through the end of punched cards as 80×24 VDUs and now sitting with my 4k wide screen curved monitor – where I can happily support 300 – 400 characters at a decent sized font … I have to wonder why oh why oh why would you cut off both arms both legs and blind yourself to stick to an arbitrary decision essentially based on 1970’s VDU’s (limits of display tech – trust me).
Don’t even get me started on K&R brace styles … which were devised to maximise space on those same 80×24 VDUs …. the world is going mad.
It’s called being civilized. I’m just glad I’m not going to be collaborating with you on any software projects.
2 indents in Python, and a trivial expression like this below, would be deemed “too long to fit in a line” and “unreadable” according to you 80-char fanatics. Keep doubling down on the crazy…
reasonably_named_var = some_object.a_named_property + another_local_varname
to please ye olde gods of 80 char, I need to make some sacrifice. Which will it be?
– give extremely short names for everything, including function names, just so I can write trivial expressions in one line like a sane person
– waste vertical space on broken-down lines all over the place, so I can see less of my own code at a glance. Profit?
Or I can act sensibly, instead of listening to religious zealots.
Or of course you could choose a language that isn’t altogether idiotic. The assumption that people make, when they use arbitrarily-long lines, is that everybody who will need to work on their code will also like using lines so long, there’s a risk of skipping lines. You can go ahead and use 50-character variable names all you want. I won’t be working on your code, so why would I care?
Why not skip lines? most of the time when you are going through code you are scanning for a very specific part. it is read top down in the syntax tree sense, things not relevant to what you’re currently doing are routinely skipped. You are not reading a book.
The names in my reply were around 15-20 chars each. Of course you talk about 50 char names because you don’t have a sensible counter argument. Using 5 or 6 names of things in one line isn’t much at all (x = foo(a, b, c) or x = a*b + c*d, even x = foo(obj.a, obj.b, obj.c)), and even with 10 char names on average, you will be hard-pressed to fit against the silly line limits already. It’s just ridiculous.
I mean, come on, it stopped being about convenience or making a sensible choice a long time ago, now it’s all about rationalizing your collective self-inflicted misery. Surely it wasn’t all for nothing….those who believe in the 80-char to the end of time will be rewarded. Maybe in paradise.
Oh, and don’t forget to set the tab size to 8. Kernel devs are doing it, so surely it is a brilliant decision now and forever.
You were doing just fine until you got to 8-column tabs. That’s just ridiculous. If you can’t get a sense of how deeply you’re nested with 4-column tabs, you are hopeless. Beyond that, it’s just “how much screen space can I waste?”. Similar with 20-character variable names. I have to read the whole name to make sure I’ve got the whole variable, and that’s going to be like eight to ten syllables I’m subvocalizing, so i think you’ve passed the point of diminishing returns. Wait – was that ‘user_input_without_whitespace_character_count’, or ‘user_input_with_whitespace_glyph_count’? You’re right, I’m not reading a book, where skipping a word or two when I already understand the sentence is sensible. I’m reading code, where every character can distinguish between two disparate things. I remember back when I was doing hardware design, I had to work with schematics that were written by someone who had just discovered hierarchical schematics. He would put ONE CHIP on a page, and use a separate page to place the connections from THAT chip to the bus and the rest of the system. Infuriating. Page turning for the sake of having lots of pages to turn.
So you’ve got an acre of screen. Good for you. I use a 13″ laptop for most of my work, and a 7″ screen for some, for very good reasons. Please don’t waste mine. Source code isn’t an expression of aesthetics, it’s a communication of thought. If you want to communicate that your thoughts are mostly empty, I guess I can’t stop you.
Just an opinion here and not based on “readabily” or “clean code”.
Using Java in a modern IDE with a reasonably large monitor I often find 120 chars not enough.
With relatively sensible verbose method names, annotations, optionals, lambdas, etc. I often hit this limit quite quickly.
So while *most* of my code fits in 120 chars, the checkstyle warnings about hitting the 120 limit are kind of annoying when they light up like a beacon in my IDE. :)
Previously the 80-char limit didn’t account for all of these “features”.