Linus Torvalds Argues Against 80-Column Line Length Coding Style, As Linux Kernel Deprecates It (phoronix.com) 296
"The Linux kernel has officially deprecated its coding style that the length of lines of code comply with 80 columns as the 'strong preferred limit'," reports Phoronix:
The Linux kernel like many long-standing open-source projects has a coding style guideline that lines of code be 80 columns or less, but now that while still recommended is no longer going to be enforced. This stems from Linus Torvalds commenting on Friday that excessive linebreaks are bad and he is against ugly wrapped code that is strictly sticking to 80 characters per line. This is part of the broader trend that most are no longer using 80x25 terminals...
This deprecation involves updating the documentation on the kernel's coding style to be more sensible and updating the checkpatch.pl script that checks patches to no longer have a max line length of 80. Instead, the check patch script is using a maximum line length of 100.
Torvalds noted Friday that spreading code over multiple lines created problems for single-line utilities like grep, while longer lines "are fundamentally useful..." [H]onestly, I don't want to see patches that make the kernel reading experience worse for me and likely for the vast majority of people, based on the argument that some odd people have small terminal windows... 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...
So no. I do not care about somebody with a 80x25 terminal window getting line wrapping. For exactly the same reason I find it completely irrelevant if somebody says that their kernel compile takes 10 hours because they are doing kernel development on a Raspberry PI with 4GB of RAM. People with restrictive hardware shouldn't make it more inconvenient for people who have better resources...
If you choose to use a 80-column terminal, you can live with the line wrapping. It's just that simple.
"Yes, staying withing 80 columns is certainly still _preferred_," notes the official commit message for this change. "But it's not the hard limit that the checkpatch warnings imply, and other concerns can most certainly dominate. Increase the default limit to 100 characters. Not because 100 characters is some hard limit either, but that's certainly a 'what are you doing' kind of value and less likely to be about the occasional slightly longer lines.'"
This deprecation involves updating the documentation on the kernel's coding style to be more sensible and updating the checkpatch.pl script that checks patches to no longer have a max line length of 80. Instead, the check patch script is using a maximum line length of 100.
Torvalds noted Friday that spreading code over multiple lines created problems for single-line utilities like grep, while longer lines "are fundamentally useful..." [H]onestly, I don't want to see patches that make the kernel reading experience worse for me and likely for the vast majority of people, based on the argument that some odd people have small terminal windows... 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...
So no. I do not care about somebody with a 80x25 terminal window getting line wrapping. For exactly the same reason I find it completely irrelevant if somebody says that their kernel compile takes 10 hours because they are doing kernel development on a Raspberry PI with 4GB of RAM. People with restrictive hardware shouldn't make it more inconvenient for people who have better resources...
If you choose to use a 80-column terminal, you can live with the line wrapping. It's just that simple.
"Yes, staying withing 80 columns is certainly still _preferred_," notes the official commit message for this change. "But it's not the hard limit that the checkpatch warnings imply, and other concerns can most certainly dominate. Increase the default limit to 100 characters. Not because 100 characters is some hard limit either, but that's certainly a 'what are you doing' kind of value and less likely to be about the occasional slightly longer lines.'"
Sense at last (Score:5, Interesting)
Artificial limits to the line length is a mistake, it's a totally arbitrary value, and has horrendous knock on effects. People end up choosing bad variable names as otherwise the lines get too long. The intention was to produce readable code that can be viewed and understood, and if that is the intention, then line length should defer to readability, not the other way around.
Re:Sense at last (Score:5, Funny)
Yes! Give me a hard limit of 80 character lines and I'll show you a bunch of 3-letter variable names!
A.
Re: (Score:2)
Re:Sense at last (Score:5, Funny)
How about 1-letter variables? [xkcd.com] (SFW).
Re: (Score:3)
Instead of 1 letter variables, how about store everything on the stack and use color to decide the type [ultratechnology.com] ?
Re: (Score:3)
You have to dig into the implementation specific parts of the outer interpreter (usually INTERPRET) and hook in >FLOAT as a fallback when >NUMBER doesn't work. (or look for a "." before trying to convert to a float, else try as a double-cell number, then finally as a single cell number)
When I write a Forth compiler I always make the number conversion a vector so the user can extend it easily for floats, DHMS, Ft-inches, or whatever it is they need to work with as literals. If you grab the old vector then it's easy to chain them too.
Re: (Score:2)
Overly long names are as bad as overly short names though. FortyCharacterColobNames don't really help, as they're just slower to read. Typically, that's a sign of prefixing or suffixing names with a bunch of needless, repetitive crap.
Long class names aren't so bad, unless you're that guy who names every variable with a short name followed by the full class name. Don't be that guy.
Re:Sense at last (Score:4, Informative)
FortyCharacterColobNames
For many people - like me - they are not slower to read, as we read whole words as a symbol more or less instantly.
Translation fccn into a meaning full thing requires mental effort for me, though, and slows me down.
Re:Sense at last (Score:4, Interesting)
I have seen that in Java code. >80 char variable names and 2 or 3 chars different between them. Needless to say, the project was later scrapped because if numerous design defects that could not be fixed and constantly caused problems.
Re:Sense at last (Score:5, Informative)
Hungarian notation was actually well motivated for its intended use, and then went horribly wrong. First within Microsoft, and then it spread like a disease as people took MS APIs as gospel.
The original intent, which was smart, for for prefixing row variables and column variables in the Excel codebase with rw and co, so that you'd never accidentally try to add or subtract a row and a column. Both types were ints, so this wasn't something the compiler could check for you, nor was the information redundant. Sadly, it was all downhill from there.
Re: Sense at last (Score:3)
I actually like to believe it comes from a misunderstanding of language. Its originator says "types" in his paper, but actually means "kinds" of variables (i.e. by purpose they fulfill, rather than by what they mean in terms of data typing). E.g.: "int imgWidth, imgHeight; float imgScale;" vs "int winWidth, winHeight; float winZoom;".
You keep the variables that belong to the same logical thing you try to do together - kind of like micro-structures.
Re: (Score:3)
Re:Sense at last (Score:5, Interesting)
Possibly, in an Egyptian pyramid.
Meanwhile, for the last 500 years, people have been aware that narrow (newspaper style) columns are easy to read, and A4 (US letter) size paper with (approx) 80 12 point characters was the standard for readability long before the 80 column card was used for text.
I have a 4k screen for coding, but very few of my code files are bigger than 3 A4 pages of text for readability, not because I used to maintain 3,000 card Fortran using an IBM 026 card punch.
Disclaimer: I did used to type set a hippy newspaper using an IBM Selectric typewriter in the 60s.
Re:Sense at last (Score:5, Insightful)
You're right, narrow columns improve readability. However, I believe the question we should consider is "is 'readability' in a newspaper and 'readability' in code defined in the same way?".
I think the answer is negative. For example, typefaces with serifs, ligatures and variable widths improve readability, but when it comes to programming - we prefer monospace fonts. Do newspapers come with "dark mode"? :-) Perhaps there are other differences too.
Code is not always read like prose. One could argue that the programmer operates in several modes, each at different levels of abstraction:
(b) is necessary when you're debugging it, but once the code was written and tested, subsequent reads of it can go at level (a).
For example, this Python chunk would be autoformatted by black ("the uncompromising code formatter"); note that you might have to zoom out a bit to make sure Slashdot doesn't add its own line breaks:
for route_id, route_number, name in curs:
result[route_id] = Route(route_id, route_number, name)
result[route_id].stations = self.load_route_stations(route_id)
result[route_id].station_ids = [station.station_id for station in result[route_id].stations]
result[route_id].checkpoints = self.load_route_checkpoints(route_id)
result[route_id].checkpoint_ids = [entry.checkpoint_id for entry in result[route_id].checkpoints]
to:
for route_id, route_number, name in curs:
result[route_id] = Route(route_id, route_number, name)
result[route_id].stations = self.load_route_stations(route_id)
result[route_id].station_ids = [
station.station_id for station in result[route_id].stations
]
result[route_id].checkpoints = self.load_route_checkpoints(route_id)
result[route_id].checkpoint_ids = [
entry.checkpoint_id for entry in result[route_id].checkpoints
]
In the top code excerpt, the programmer sees it as "each line sets an attribute of the object in question", mode (a). Whereas in the bottom excerpt some of these logical operations span across multiple lines and you're forced into mode (b), because you're not sure if these several lines are a part of the same logical operation or not, until you read them.
This reminds me of the "Thinking fast and slow" dichotomy, where "system 1" makes a fast decision, while "system 2" makes a slow one. In my experience, quite often when long lines are broken down into multiple lines I am forced to deal with them using "system 2" when "system 1" would suffice.
So, there are cases when long lines are appropriate.
Re:Sense at last (Score:5, Interesting)
I agree that arbitrary limits are a bad thing, but rules of thumb can be a good thing, as long as you know the correct thing to do about them. It's kind of like a grammar checker; you can't really rely on its advice because it doesn't know what you're trying to say, but when it puts a lot of flags on a sentence, that sentence nearly always needs some attention.
I started programming on VT220s, which were 80 columns x 24 lines. This is a rather small window into code; when functions are over a hundred lines long, or indents to more than fifty columns, it hampers your ability to understand what's going on. But the right answer wasn't to *mangle the formatting* of your code to make it fit. The answer is to refactor your code so that when you're looking at a function or procedure, everything you need to see to understand it is nearby.
Even then you have to apply common sense. The goal is to make the code readable, assuming it works well enough.
Re: (Score:2)
The answer is to refactor your code so that when you're looking at a function or procedure, everything you need to see to understand it is nearby.
This. I noticed that when I set myself to adhere hardly to an 80 character limit, that what I wrote started to become more refined and coherent. I never write multiple line prototypes or broken lines anymore, but I will give myself some leeway if it goes over a few characters.
Re: Sense at last (Score:5, Interesting)
I *continued* on vt220 terminals (and vt100 terminals before them). That size came from teletypes. That size came from IBM punch cards. That size came from matching the size/format of 1890 census cards. That size came from US currency during the 1880s.
Similarly to the cargo cult history of the standard gauge railroad rail width coming from old Roman roads, which were optimized to accommodate vehicles like chariots of the time, whose wheel separation width was defined by the standard width of two horses side by side.
Learn your history.
Re: Sense at last (Score:5, Insightful)
Well, there is "true" and then again, there is "true".
The British engineers also used a wide variety of gauges, and indeed, there are still examples of 2' and 3' gauge railways in the UK. However, 4' 8 1/4" as we call it (you call it 4' 8 1/2" but this is partly due to differences in how and where it is measured), was chosen as the standard because of the need for compatibility with the human world after a lot of research, and the observation that it was the same as the Roman's had used during the research and planning of the standard. (The same reasons the Romans chose it).
Famously, much larger gauges were tried and found to give much better performance. But there was a problem with compatibility and interchangability. So the decision was taken that standard is more important than best a lesson that, despite it staring them in the face, today's computer industry regularly strains itself to fly in the face of!
The Snopes article also discusses the sizing of clothes: These are not due "copying medieval tailors" one little bit. American sizes/shapes are based on measurements taken on US Navy personnel during the Vietnam war. UK sizes are based on measurements taken in 1949 - ie after ten years of starvation level food rationing. Hence the fashion industry's obsession with models with advanced malnutrition. (And not, as some people have suggested, because the industry is run by perverts who want their (female) models to look like under-age boys).
Apologies: I had to take my grammar checking module out the back of the shed and shoot it for reasons entirely unconnected with this posting.
You scared me (Score:2)
> when functions are over a hundred lines long, or indents to more than fifty columns
Right about there I thought you were going to say you need longer lines, so that each function could have 70 lines of 120 characters each. Gotta have that column width so you can indent 20 levels, right?
> The answer is to refactor your code so that when you're looking at a function or procedure, everything you need to see to understand it is nearby
So much this. One thing I learned late in my programming career, somet
Re: Sense at last (Score:3)
I think you will find that VT220 had a 132 column mode.....
Re: (Score:3)
It should be a rule of thumb that code as written should be understandable by a new hire or a novice. It should not be written so that only others highly experienced in the project understand it. Someday, maybe a long time off, someone else will have to maintain the code and the original author will be long gone. Prepare for that day from the start!
Re:Sense at last (Score:5, Informative)
No, it's not an arbitrary value, there was a good reason to pick it at the time. Specifically, it came from the early days of computing when most if not all input and output was via punched cards. Punched cards have eighty columns, making for eighty card records and eighty column lines. That doesn't mean that we have to be tied to that standard now, but it does demonstrate that the number eighty was never arbitrary.
Re: (Score:3)
Isn't it also the width of a VT100 terminal?
Re: (Score:3)
Re: (Score:2)
And if VT100 terminals had an 80-columns limit, why weren't they called VT80?
Re: (Score:3)
Yes. They choose that width because it was the width of the punch cards the terminal was replacing. The alternate width of 132 characters was because that was the standard width in large-format printers.
Re: (Score:2)
but it does demonstrate that the number eighty was never arbitrary
Except for the original number eighty, you mean?
Re: (Score:2)
Re: (Score:3)
No, it's not an arbitrary value, there was a good reason to pick it at the time. Specifically, it came from the early days of computing when most if not all input and output was via punched cards. Punched cards have eighty columns, making for eighty card records and eighty column lines.
Punched card did not have 80 usable columns, though. Usually the last 6-8 columns were reserved, and ignored on input. They were used for sequence numbers, continue character, and the like.
The "80 column mind" comes from early displays. Sure, the displays were 80 columns because the cards were, it's not arbitrary, but you didn't code 80 columns wide in the early days.
I use two limits when coding. Lines should fit in 80 columns after the initial indentation. Reading a column of text wider than that is f
Re: (Score:2)
Well, except that some card readers wouldn't read anything past column 72. The last few columns were intended for sequence numbers, so that if you dropped your deck you could put it back in the correct order. And, of course, the first 5 columns were intended for labels so that you could go to the proper place when you branched. And the 6th column was intended for a continuation marker, in case your statement wouldn't fit on one card..... A lot of arbitrary choices there. If you were using cards as your
Re: (Score:2)
Re: (Score:3)
How about, can you fit a line of code into a book or manual? I know not a lot of people do it, but it's a good rule of thumb. Notice that by default when you create a text document that you do not get arbitrarily sized virtual pages. There's a limit. 8-1/2x11 for Americans, similar proportions internationally. If the code doesn't even fit when you go landscape that way, then it's almost certainly going to be more difficult to read no matter what you do with it.
I know people who used to do this, they'd
Re:Sense at last (Score:4, Insightful)
Lemme educate you, son.
The 80 column limit is by no means arbitrary, or a mistake. Back before you were born, in the dark ages before RGB, terminals had 80 columns, thus coding style locked into that column width. For a long time, word wrap wasn't even a thing. (some coding languages and shells to this day use a backslash to denote a continued line, that's why.)
Eighty columns is legacy, maybe even tradition, for sure, but not at all arbitrary. (I don't have space/time/desire to explain 'why 80', but the info is out there if you seek it.)
If you're still programming in a terminal then you're a weirdo, but the limit is no more arbitrary than other standards, current or outmoded, like 24 fps standard for filmed motion pictures, 4:3 ratio of broadcast TV, or the number of scanlines on a 4k display. All of this stuff is at the intersection of technological limitations, standardization and budget at the time these things were originally being worked out.
Re: (Score:3)
At a company I worked for, I changed the coding standard to 164, because that was how many could fit on a landscape printout, as we were required to do code reviews in meetings with printouts.
My current company has a 132 length, completely arbitrary but usually sufficient except for comments and generated tables, which can gat rather large with longer symbols.
Re: (Score:3)
No by the dictionary arbitrary is to pick based on random choice or personal whim, rather than any reason or system.
In this context picking 132 columns which was the largest width supported on the commonly available terminals and line printers of the time is *NOT* arbitrary as there is a well founded reason for the choice.
Further the 132 column limit on terminals and printers was there because of limits on the technology at the time. Sure today I could build a terminal 256 characters wide, back in 1980 that
Re: (Score:2)
Linus also mentioned (right there in the summary) that it's not a hard limit precisely for the reasons you mentioned. He'd prefer descriptive variable names as opposed to shorter line lengths. I agree that it makes much more sense as a guideline.
And longer lines are simply useful. Part of that is that we aren't
programming in the 80's any more, and our source code is fundamentally
wider as a result.
Yes, local iteration variables are still called 'i', because more
context just isn't helpful for some anonymous counter. Being concise
is still a good thing, and overly verbose names are not inherently
better.
But still - it's entirely reasonable to have variable names that are
10-15 characters and it makes the code more legible. Writing things
out instead of using abbreviations etc.
I also found it mildly humorous that his post was formatted to fit in 70 columns.
Re: (Score:3)
Still with 8 space tabs though... Linus claims it's for readability but I don't have any problem following indents with 4 character tabs. Do other people?
Re: (Score:2)
Nah, some people just can't let go of what was right in the 80s. I use 3 space tabs when I have a choice in managed languages, as almost all your code is indented at least twice and it's wasteful. I tried 2 space tabs, and for me that's where it starts to get a little visually fatiguing to keep the indent level straight.
Re: (Score:2)
Personally, I usually use tabs for indentation, and I have my tabs set for 3 spaces in the editor. If indentation starts getting too deep, I can set them to 2 spaces without impairing readability much. 1 space, however, loses all merit.
Re: (Score:3)
Personally, I usually use tabs for indentation, and I have my tabs set for 3 spaces in the editor. If indentation starts getting too deep, I can set them to 2 spaces without impairing readability much. 1 space, however, loses all merit.
For the sake of others, PLEASE don't use Tabs for white space, use spaces for white space. Please?
The problem with tabs is that it's not the standard to put tabs in as a constant number of spaces, so when somebody else pulls up your Tab laced code into their editor, it may or may not "line up" as you expected. If they have tabs set to say 8 characters wide, then it makes that line you so dutifully limited to 80 chars that's indented a few times longer than 80 forcing the editor to wrap it (or the display
Re: (Score:2)
I use 4 columns for my own stuff, but 3 for work because that's the "standard" there. I can read either without difficulty, but I prefer the extra visual space 4 columns gives me.
Re: (Score:3)
Yes, it is. But it's it's an arbitary value trying to solve a real underlying issue: lines that are too long are a PITA. At the extreme lines several thousand characters line (and yes, I've seen that in PHP scripts) are very difficult to read and utterly unnecessary. Any coding style guide should ban them, and all I've seen do.
But what line length is acceptable? I can give you one good place: when you can't see the entire line. I've seen quite a few programming errors caus
Re: (Score:2)
It's actually an obsolete artifact of earlier technology. Line limits made sense when you were feeding your programs into the machine with punch cards. Now, not so much. Also, back in the dark ages, the amount of storage your source code took up was actually a significant cost factor.
Re: (Score:2)
So, 80 chars bad; 100 chars good (Score:3)
Seriously?
Sign, I must not be nerdy enough for this to be news here on /.
Not going hog-wild over 100 chars is very good (Score:3)
Or not old enough to have recognized the onset of presbyopia - the first symptoms of irreversible body degradation due to age. Its onset typically becomes noticeable about 40 to 42, is pretty much universal by 45, and worsens until about 65.
For most things it's an annoyance.
Didn't he say 80 characters is enough? (Score:3)
Re: (Score:2)
It depends on style too, if you indent case statements then you are already three tabs in (function, select, case) which means very limited logic it a bunch of function calls.
Some people like to save vertical space with if statements that put everything on one line, but that makes them harder to follow in most debuggers.
Best solution is to buy a bigger screen, which fortunately is really cheap now.
Re: (Score:3)
Single line if and case statements do make sense in a specific context though: where you have a bunch of structurally identical statements in a row, with only 1 value being different. That is, explicit mapping from input to output where you can't use array lookup, or a computed jump is faster.
Re: (Score:3)
It makes sense.
I was wrong. It wasn't about the character limit but the amount of characters representing indentation.
Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.
From https://www.kernel.org/doc/Documentation/process/coding-style.rst [kernel.org].
Re: (Score:2)
Re: (Score:2)
The "four characters per indent" is your problem.
Linus still used a 80x25 terminal?! (Score:3)
Explains a lot... wonder if it was green or amber... probably amber...
Seriously tho - I've encountered this in Python recently as its a PEP guideline to keep your lines under 80 characters. Real pain in the butt when you've indented a few times and really hated it at first coming from Java/C++ where I'd rack up an offscreen line easily (i mean, c'mon, it's a function call with a dozen parameters - I'm not going to put them all on a separate line!). But with mucking around Python long enough I've come to agree that seeing all the code on screen at once is really "a good thing"(tm). I still think 80 characters is too short but probably anything over 132 is too long.
My 2 cents anyway.
(and don't get me started with treating tabs as functional operators!)
(tabs, of course, should 5 spaces as God intended with the typewriter)
(now get offa my lawn!)
Re: (Score:2)
The adoption of such line limits by other languages/projects is interesting. I'm of the opinion it's the same sort of logic mistake that drives lots of marketing - 'Linus writes great code. Linus likes 80 character line lengths. If I use 80 character line lengths, i'll code like Linus' (hint, no you won't).
Re: (Score:2)
Maybe languages shouldn't rely on hard indentations? I'm a hardware guy and Python seems like such a pain in the ass to deal with. Oops one extra space on this line and the whole thing dies. The compiler doesn't care about whitespace.
Re: (Score:2)
I do mostly embedded stuff in C, but I do enough other stuff in Python that I've gotten used to the indentation thing. It's still kind of a pain in the ass, but it doesn't make me want to hurl the keyboard across the room like it used to. I guess I've got a bit of Stockholm syndrome going on.
Re: (Score:2)
Compared to:
InvokeCall(String callName, String callId, String oAuthtoken, String parm1, String parm2, String parm3, String parm4, String parm5, String parm6, boolean invokeAsync, FuncPtr eventCallbackNotifier);
My preference:
InvokeCall(String callName, String callId, String oAuthtoken,
String parm1, String parm2, String parm3, String parm4, String parm5, String parm6,
Re: (Score:3)
Actually, I would probably prefer
lineDraw(int32_t startX, int32_t startY,
int32_t endX, int32_t endY,
uint32_t colour);
to leverage the symmetry in the parameter names.
Re:Function Parameters on multiple lines: (Score:5, Insightful)
Eww. Put the commas at the end of lines, dude, not at the beginning.
Weirdo.
Re:Function Parameters on multiple lines: (Score:5, Insightful)
Re: (Score:3)
I've seen this argument often and I've never really understood it. Putting commas at the beginning or the end of the line changes whether it's the first or the last line which requires a tiny bit more effort to comment it out using line comments (in contexts which don't allow floating commas), but even if the asymmetry in frequency of commenting out the first vs the last line is high enough to compensate for the cognitive load of parsing the symbol in the less common position, I'm not sure I've used any lan
Re:Function Parameters on multiple lines: (Score:5, Interesting)
Spotted the amateur who has never had to add items in an enum. Plus commas at the beginning make it EASY to spot if there is a missing one and improves readability instead of them being at the end where they are all over the place.
Reasonable Size but Reasonable Amount of Info? (Score:3)
Of course I'm saying this because I've been coding with 100 column x 56 row editors for a few years now ;^)
More seriously, there should be a discussion as to what is too much information on a line of code. The goal should be to maximize ease of understanding the code versus having to add comments to explain what's happening.
For example, which is more readable, this:
if ((0 != columnOffset) && (0 == (xCoord & 0x80000000)) {
or
if ((0 != columnOffset) &&
(0 == (xCoord & 0x80000000)) {
The condition is true if the column is not zero and the x coordinate is zero or positive - which line conveys that message better?
Re: (Score:2)
Neither is going to compile, and neither is close enough to 80 columns to matter much.
0 == (xCoord&0x80000000) is something I'd flag, regardless, because nobody is checking whether that on bit is in the correct location for the test you intend. Did you place enough zeros? Is xCoord the size of integer you're assuming it is? Is 0x80000000 the same size of integer as xCoord? It's not 1988 any longer, we can do better than this. Personally, I'd suggest !(xCoord 0) and let the compiler figure it out.
Re: (Score:2)
!(xCoord 0)
What language is this? Definitely not C.
Re: (Score:2)
Slashcode ate his < I'm guessing he was being clever with signed ints, which is usually a mistake.
Re: (Score:2)
Re: (Score:3)
Having the constant first when using a comparison operator is new to me....
I adopted that habit years ago specifically so this would generate a syntax error instead of inadvertently becoming an always-true assignment.
if (7 = x) {
Re: (Score:2)
Re: (Score:2)
Yeah, where I work, doing "if (x == 7)" will guarantee a beatdown at a code review. :-)
Re: (Score:2)
In th bad old days, compilers wouldn't warn you when you did
if (x = 57)
But you meant
if (x == 57)
So putting the constant first became a habit. Back in the 1980s, that sort of shit made sense. Hasn't made sense in a long time now, and just makes code harder to read, but some people just can't let go of 80s coding styles.
Re: (Score:2)
There's still ways of triggering the same issue. Much like the definition of kilo I wish they'd left the "equals" operator from math alone and done it VB-style like x := 57 (but keep it as x == 57). Most code of any significance is read far more often than it's written.
Re: (Score:2)
It's fine that most if not all compilers nowadays will flag that with a warning, but during code reviews you generally aren't compiling the code, and don't have a guarantee that the coder didn't just ignore the warning. It's just as easy to miss an accidental assignment during a review as it is when you're writing code, so there is still a benefit to doing it the other way, and if you're used to that style it's not any harder to read.
Re: (Score:2)
Is there any good reason to not use the greater than operator for checking greater than zero here? The compiler should optimise it well and there is no chance of missing a zero in your rather big constant.
Maybe xCoord is unsigned? Casting to signed can look a bit messy I guess.
What? (Score:2)
People with restrictive hardware shouldn't make it more inconvenient for people who have better resources...
So those with money get to stick to those who don't? Why does that sound familiar?
Re: (Score:2)
I've defended 80x25 for many, many years. However; it was the standard 20 years ago and was probably a bit dated back then, and honestly, we've moved on.
I've got relatively crappy hardware, but when I just expanded my xterm to the edge, echo $COLUMS returned 320.
I'd be fine with accepting I'm probably affluent, and go for half that. Going for just 100 seems a bit restrictive, and I'll argue for 160 character line length as probably entirely OK.
Re: (Score:3)
Technology advances. If you're still using a 4:3 or 5:4 aspect ratio display in 2020, for example, it's time to change since most software assumes people are using at least a 16:9 or 16:10 aspect ratio display.
I do understand that if it's possible, software should support whatever aspect ratio your monitor is (from 4:3 to 32:9, for example) but sometimes older technology just doesn't fit with modern needs. I know it doesn't sound like a nice thing to say, but people with older hardware can't delay progress.
Re: (Score:2)
I disagree, splitting lines increases legibility (Score:2)
But my punch cards only have 80 columns, (Score:2)
now what am I going to do?
Why not eat some cake? (Score:2)
People with restrictive hardware shouldn't make it more inconvenient for people who have better resources...
Or, as we put it over here in the first world, your poverty makes me puke.
Re: (Score:2)
I agree with you in general. But in this particular case I think Linux is right. He is talking about some prehistoric machine right there. My laptop is standard issue in my university and that is the model (Dell Latitude E7250) that we are starting to replace because it is out of warranty. And it is a 4-core system with 16GB of ram (I may have gotten the upgraded model because I do performance).
I am all for accessibility, but you would expect kernel contributors and people who frequently compile the kernel
132 then (Score:2)
OK, you can go to 132 characters if you must
[for those who don't remember the dim past, 132 characters was the width of the "super-wide" IBM 3270-type terminal; never really replaced the true 80-column 3270 though]
Re: (Score:2)
heh, someone else does use 132. More commonly, 132 was the width of wide printer paper, of the kind used to review code in the old days. 132 characters was a good limit for shops with better text editors, but that still used paper copy for review and sign off.
should have been 132 a couple decades ago (Score:2)
And easily the graphic displays of the '90s supported 132 char views.
This is like FAT and should have been dead long ago.
LoB
Finally some sense (Score:2)
But we've been using large wide LCD screens for two decades now, and the self-imposed limit makes no sense at all. What the heck is people's aversion to using the middle and dare I say over to the right side of the screen? My editor can reformat and do all sorts of fancy stuff for me, so have
multiple terminals (Score:3)
i was taught at university - interestingly not by the professors but by a lab assistant - that if you cannot see the purpose of a function clearly written on one terminal, then fundamentally there is something wrong with the code. that if you have gone beyond the indentation level to the point where the code wraps around, this is a straight simple indication that you need to break the code down into functions.
i have followed these rules for 30 years and found that they serve projects extremely well.
over that time, screen sizes have increased drastically, from 800x600 to 1024x768, then to 1280x1024, 1600x1200, 1920x1080 and now finally 4k screens. throughout that time, i have *always* kept terminals at 80x60 - or now with a 4k screen, 80x70. this allows me to do things like this:
https://libre-soc.org/HDL_work... [libre-soc.org]
that's a whopping *ELEVEN* visible 80x70 xterms, another three of which are temporarily obscured by a graphviz display, nine of which are in active use at the time that the screenshot was taken.
how the hell can you have *nine* active xterms in use at one time? it's very simple: seven of them have code open, and two of them have commands running. one of those commands is a stack-trace of the application being debugged, and the one next to it contains important command-history of yosys (controlling the display of the graphviz).
each one of the *seven* active editing windows - each where every single line of code respects an 80 character limit (with the exception of 3rd party code) - provides vital information about the bug being investigated. they fall into the following categories:
* files being edited that functions are being added to
* files that those functions *use* (immediate-use)
* commonly-used library routines
often in some cases i will have 1200x800 browser windows - two stacked one under the other - next to EIGHT 80x65 xterms, particularly when doing internet research. in others, i will have PDFs side-by-side with the code being edited.
what benefits are there by having such a huge amount of information on-screen? the question itself contains the answer: "huge amounts of information". it turns out that having the files being edited next to the files containing the functions that they use, means that i am not flipping back and forth constantly, trying desperately to memorise the header file, or trying desperately to recall what the function parameters are of the subroutine that i want to call, because that subroutine's definition is right there, right in front of me.
bottom line: i don't have to memorise millions of lines of code in order to maintain complex state information in my head: i can see it all, right there, at a glance.
and this is where Linus Torvald's statements become problematic. he's forgotten that not everyone has a working mind-map of the linux kernel codebase in their head. tools such as emacs split-windows, ctags, and IDEs with "Mouse-over" hints that show the definition of the function being called are *not enough* when it comes to massive multi-million-line codebases.
80x65 terminals fundamentally forces developers to break code down into smaller chunks that fit on the screen. with multiple such chunks being visible at once, newcomers and seasoned developers alike can not only keep track of complex code, they are much less likely to write code that requires memorisation of state and context spanning vast swathes of text that cannot be displayed on any screen, let alone a single 80x65 terminal.
But ... (Score:5, Funny)
I
get
paid
per
line
of
code
.
About 130 characters (Score:2)
My line length is basically dictated by how many characters I can fit on a line in an emacs frame split into two. Programming with two files open is the most common case for me, and everything follows from that. The only problem is that as I get older I like the font to be bigger so Iâ(TM)m starting to lose line real estate.
Thank goodness . . . (Score:2)
It *is* the year 2020 you know... (Score:3)
I can only imagine the head-smacking Linus did, sitting down in front of his shiny new $8,000, 64 thread/32 core desktop with 256 Gig of RAM and wondered wy he had to stare at little 80 column windows on his 40" curved QHD display?
He probably had been looking at 80 column code lines since he first coded his little kernel on his new 80386 desktop back in the day...
Re:It *is* the year 2020 you know... (Score:4, Insightful)
Because he can put up 16 of those windows now tiling them across the screen any way he wants. Having just one window for code? Pfft. He shouldn't have to make the editor fullscreen every time he gets a submission from Widelines McDevguy.
Welcome to the 90's, Linus! (Score:2)
Most of us have escaped the constraints imposed by Hollerith cards.
80 character limits is simply ridiculous.` (Score:2)
His code is in in "C" right? (Score:5, Interesting)
#include <stdio.h>
#define f(f,g){z e=0;for(;e<f;e++)g;}
#define i(f,g)static z f(z a){return g;}
#define j(f,g)static void f(z*a,z*b,z*c){g}
#define h(f,g)static z f(z a,z b,z c){return g;}
#define g(f,g,h,i,j)static z f(z b){z a=g,c=h;for(;i)a=j;return a;}
typedef unsigned char y;typedef unsigned long long z;extern y*w;static z b(z a,z b){return a>>b|a<<(64-b);}i(_,
(a>>6)^b(a,61)^b(a,19))i(_a,b(a,39)^b(a,28)^b(a,34))h(x,((a^b)&c)^(a&b))i(u,b(a,41)^b(a,18)^b(a,14))h(t,(((((3*(a*c+b*b)>>9)+(3*
b*c>>32))*a>>21)+(3*a*a*b>>6)+((b>>4)*(b>>4)*b>>46))>>18)+a*a*a)h(m,t((b<<16)|(c>>48),(c>>24)%(1<<24),c%(1<<24))>>48<a)h(s,(a&b)
^(~a&c))i(r,b(a,1)^b(a,8)^(a>>7))g(o,0,0,c<8;c++,a*256+w[b*8+c])g(d,0,0,c<13;c++,a*31+w[b*13+c]-96)g(p,0,4,c;c/=2,a|c*m(b,a|c,a)
)g(q,0,1ull<<63,c;c/=2,a|c*m(b,p(b),a|c))g(v,b>1,2,c<b;c++,a&&b%c)g(l,b?l(b-1)+1:2,a,!v(c);c++,c+1)j(n,z d=a[7]+u(a[4])+s(a[4],a
[5],a[6])+q(l(*b))+c[*b%16];f(8,a[7-e]=e-3?e-7?a[6-e]:d+_a(a[0])+x(a[1],a[2],a[3]):d+a[3])f(16*(*b%16>14),c[e]+=c[(e+9)%16]+r(c[
(e+1)%16])+_(c[(e+14)%16])))j(k,f(8,b[e]=a[e])f(80,n(a,&e,c))f(8,a[e]+=b[e]))int main(){z a[8],b[8],c[16];f(8,a[e]=d(e))f(16,c[e
]=e-15?o(e):d(8))k(a,b,c);f(16,c[e]=e?e-15?0:11264:1ull<<63)k(a,b,c);f(8,printf("%016llx%s",a[e],e-7?"":"\n"))return!w;}y*w=(y*)
"crsmyiajqhwy{unwa|hjoi`hlxhpxrzb~edko~rtr~ileqyjk`znqgsuitvgqnfdfa||wedvnmhozkpokootqzcexeld~oibqzpcsuw{ib{x`m`hsa`jmn}wcfzpb";
I didn't count, but that looks like about 80 characters wide, and it certainly doesn't use "space" characters to indent, so it's all good, right?
"effective" line length (Score:5, Informative)
Those web pages that wrap paragraphs into 150-character lines drive me nuts. I refuse to read them as-is; they are in fact one of the major reason for "reader" extensions to web-browsers. Before these came into common availability, I wished I could punish the web-authors that did such things -- severely!
ironic (Score:3)
...that we're having a discussion about shitty, primitive formatting on Slashdot.
Re: (Score:2)
IBM punch cards supported 120 characters - Generally though, 80 were reserved for code and the other 40 were used for things like line numbers/indexing up front and line comments at the end.
No, I didn't actually program with punch cards - my college had a bunch of ancient machines lying around and one of my first professors made us all copy a simple "hello world" program he had written on them just to get the experience of what it was like.
Re: (Score:2)
Re: (Score:2)
Which card punch? 80 was the IBM 027 cardpunch, but they came out with a model that used 96 holes, and punched round holes rather than rectangular ones (and had square cards). I never used one of those, though. I think I did use the 029, if I remember the model correctly. That one introduced upper and lower case letters. I liked the change, but I was quite the junior programmer on the team, and others though them annoying.