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.
I had them when I used PygmyForth: F+ F- F* F/ FSIN FCOS FTAN...
Theoretically any Forth that lacks floating point support can have it added pretty quickly. The operations are pretty easy to write. for a 16-bit forth with 32-bit floats you can write a lot of things : FDUP 2DUP;
Where it gets a little harder is how you want to handle the float literals. 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
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.
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.
}}} Overly long names are as bad as overly short names though. {{{ --- Coding for Windows around the turn of the century was ridiculous with that gawdawful variable naming convention. What was it called, Hungarian notation or something like that?
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.
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.
Not in C. If you want the mathematical operators to work, you've got ints. typdefs don't change that. It's a fundamental failing in most languages that you can't create something that is as easy and efficient to work with as an int, but is treated as a different type.
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.
It's a clash between people who get stuff done when coding, and people who'd rather argue for a few months about proper style and coming up with a team standard about precise variable naming. If your function is so long that you need to remind the reader what the variable is being used for on every line, then your function is too long and might be worth breaking it up.
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.
8x16 font at 2560x1440 is 320 columns. Very easy to see, plus you can emulate old CGA/EGA/MCGA graphics with just space character and background color.
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.
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:
(a) high-level: "iterate over a list"
(b) low-level: "this is a for loop that begins at 0 and ends at X, and increments the counter with 1 at each step"
(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.
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.
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.
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.
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.
> 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
Ugh, there is some code in the system I'm working on that's a few thousand lines long. Now, people who've learned in school may have bad style, but too often I see the self-taught programmer who never had a mentor who ends up with the most unreadable code, or who seems the most baffled when someone asks to split a function into pieces.
Not many do flow charts anymore, or structured diagrams, but you're allowed to have several boxes sequentially in a row and it makes the charts easier to understand that way.
Ick. Also, breaking up into small functions means you have a chance to give each function a descriptive name, so the scope and concern can become self-documenting.
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!
I'm pretty sure that 132x24 was support on DEC VTs starting with the VT102 (I think it was a video option on 100s, which would only do 132x14 by default).
Artificial limits to the line length is a mistake, it's a totally arbitrary value,
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.
No, that was the VT52; the VT100 also had a 132 column mode. The 80 column standard went back at least to the '60s, when I was using punched cards to program an IBM 1620.
Never seen it on an actual VT102, but on the Vt220 with the green screen the 132 column mode was perfectly crisp if a bit small. Readability would depend on your eyesight I guess.
And if VT100 terminals had an 80-columns limit, why weren't they called VT80?
Actually, VT100 terminals had a 132 column limit, but hey... The real limiter was the LA120, which printed on 132 Column green bar tractor feed paper.
80 x 25 was generally the standard due to backwards compatibility with punch cards, which limited line widths to 80 and 25 was 24 lines and a control line which makes sense for most programing languages of the day.
Yes, this is antiquated... But hey, having Nibbles, Bytes and Words defined as 4, 8 and 16 bits is an antique thing too.
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.
Note that the 80 character punch card did not mean you got to use all 80 characters for each line of code. Often you had to use the first few columns for other things, depending upon the language or OS. Ie, in Fortran you have to indent by at least 6 characters, depending upon standard or variant, some systems reserved 8 characters for line numbers for sorting purposes.
When 80 characters is given as the limit for coding, it's not meant as a challenge to fill up the entire line. Typically most lines are 5
Some cards were 72 characters wide, and I think the ASR33 also was that. I remember the noise and smell from an ASR 33. I might have a punched tape from one in my stashes too.
Don't put words in my mouth, it violates social distancing. The 80 column limit was imposed by the size of the Hollerith Cards that were used for input.
The original punched cards were designed to fit into a man's shirt pocket, which had been designed to hold greenback dollar bills. Once the dimensions of the card were set, the number of columns was set by the size of the holes needed. How arbitrary do you want to be?
You mean the *original* cards, the ones with 45 columns? The decision to make the *later* mainframe cards the same size was an arbitrary one. IBM itself had yet another punch card format for their smaller computers that had completely different dimensions.
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
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
What you wrote is mostly applicable only to program cards, not data cards where only the sequence numbers take away from the total number of available columns. Of course, this whole conversation has to do with programs, making it relevant.
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.
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.
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.
Nope 132 is not arbitary, it ties in with the fact the VT100 and later terminals had a 132 column mode. Anything emulating a VT102 (which is like everything) should cope with it.
VT102 choosing it is arbitrary. Being compatible with it is arbitrary.
You could easily build a computer with a different number of columns and it would work fine. It is not a natural limit. It is a chosen limit that could have been whatever they wanted, but what they chose was convenient to them. That's arbitrary.
What isn't arbitrary, for example, is the frequency range of an LED intended to be viewed by humans. Or other things that you would calculate after observing n
ou could easily build a computer with a different number of columns and it would work fine.
The computer might work fine, but no one would be able to sell you a line printer that would print it.
132 columns was the width of paper used by accountants and, in case you don't know it already its the bean-counters wot counts the beans
No one will sign of the payments for a line printer of any other size.
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
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.
I use descriptive variables mostly except for index variables that often are 1 or 2 characters like i, j, k, i0, i1 etc. As there's often no need to have long variables everywhere.
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?
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.
Another one who likes 3 space tabs, so many heretics around here... It might be because I like a space between the if and the bracket, so with 4 spaces multi-condition ifs line up nicely. And also because 4 is the correct number.
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.
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
Whyever not? If I want to share the code with some group, and they don't like tabs, I can easily use one of several tools to convert them into the appropriate number of spaces, but for me they are much more convenient. So much so that I normally convert leading spaces to tabs when I import code.
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.
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
Your other examples make sense, but I'm not convinced by this one. Why should textbooks need narrower columns than novels? It seems more plausible that textbooks have huge margins because it's expected that some non-trivial percentage of their users will want to make annotations.
it's a totally arbitrary value...[t]he intention was to produce readable code that can be viewed and understood
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.
}}} People end up choosing bad variable names as otherwise the lines get too long. ((( --- The problem you highlight is not the line length. The problem you highlight is programmers who choose not to write readable, maintainable code. I've seen excellent code written within the 80 character line length. I've also seen some pretty horrendous code written without concern for line length. The problem is not the line length.
Actually, it is not arbitrary and 80 chars is already on the long side. There is a line-length limit on the human side. Make things longer and stuff becomes very hard to read. Sure, there can be occasional exceptions but that is something different.
Arbitrary limits that approximate a reasonable value can make total sense. If we took away age limits to drive a car and said we'll make individual decisions based on maturity that would be pure hell to enforce with any kind of consistency and there'd be massive attempts to game the system. It's not like you level up and gain any great insight the day you turn 16, but it's easily quantifiable and you don't need to get into any long arguments about every case. Same with a character limit, maybe it doesn't ha
Well actually it wasn't a totally arbitrary value at all. It was value purposefully selected for a very specific reason, one which was mentioned over and over again in TFS.
No, it's nonsense. The problem is all the tools out there that want shorter lines. I have maximized my window once and still been unable to fit all of one dev's lines in it. If I go to a code review tool where it shows side-by-side code, then the team that doesn't follow such limits routinely has me doing horizontal scrolls just to see the code. Is the 'git diff' readable? Can you see the whole line in the automated build error that shows up in email? I don't care what your tool can do, it has to work w
Now the big problem is those language fashions that demand huge lines. C++ without having a "using" statement, where you can go 80 lines just naming a function - fundamentally broken in my view.
Is there some C++ style guide that bans "using" (or the old-style version "typedef")? That's stupid.
Readability is exactly why the 80 character limit should be enforced. Keeping it there lets you easily have *lots* of terminals open and visible at the same time.
If the coder isn't smart enough to be able to be reading multiple terminals at once, replace the coder.
The 80 column limit was not arbitrary but based on ancient technology of 80 column punch cards and serial based terminals such as VT100. Remember that RAM was expensive so constraining resources was a useful thing to do.
However, in modern times, the 80 column limit is too restrictive so I agree with the change in emphasis.
While they are at it, do we really need tabs with 8 spaces ? I suspect tabs are used to save RAM and so is historical.
There is nothing wrong with removing the limits. I'm an older nerd, and I started coding with 72 character IBM punched cards, which were based on Hollerith cards invented to program semi-automated looms. Yes, the cards contained 80 characters, but the last 8 were reserved for auto-sequencing punch machines. Once you got your code right, you ran it through the sequencer which punched the last 8 characters. Then if you dropped the deck, you could run it through the sorter and it would sort them back into the
Oh come on. I have a composite CGA display on an old TV. I need 40 columns so I can read the text.
But seriously. 100 columns I feel is good enough for most coding. 80 columns on modern displays is just stupid. Back in the days of 80 column monitors. They were 12" - 14" displays were common, with 640x480 resolution, when Linux started. Now those size displays with modern High-Res LCD Screens are incredibly small. I would had chosen 160 columns myself. (using the old VT220 compress font settings)
Personally I like about 160 as it's 1/3 of a super ultrawide at my preferred font size. But this is the problem: it's an editor-side issue.
Line length is a stylistic rule and those are designed to increase readability by normalizing the appearance of code. However this can't be done with line length because a given length will look different in different environments. Better not to enforce a limit and let the editor decide.
(YMMV for languages where line breaks actually have syntactic meaning)
I find 80 character lines a good rule, but like all rules, they can be broken.
But before you break it, think about it. Maybe your variable name simply too long. Maybe your long formula will benefit from an intermediate variable. Maybe your indentation level is too deep and you should write a function. And if you really don't see how you can improve your code, go ahead and write that long line.
Over the years, I relaxed many rules of my coding style. But only after I giving it careful consideration. Line leng
Only through hard work and perseverance can one truly suffer.
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:2)
Don't you mean 962 names?
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: Sense at last (Score:2)
Forth and RPN calculators.
Only headache I had with Forth was the lack of floating point support.
Re: (Score:2)
I had them when I used PygmyForth: F+ F- F* F/ FSIN FCOS FTAN ...
Theoretically any Forth that lacks floating point support can have it added pretty quickly. The operations are pretty easy to write. for a 16-bit forth with 32-bit floats you can write a lot of things : FDUP 2DUP ;
Where it gets a little harder is how you want to handle the float literals. 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
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)
Forth.
I enjoyed forth back in the day, when 'putering was a hobby and not a significant part of my vocation.
It was, and still is, the best write-only language ever!
And The Inspiration for Yoda talk it was.
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: (Score:2)
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: (Score:2)
Both types were ints, so this wasn't something the compiler could check for you,
Except it could - by making the concepts different types. That's what types are for, and was possible even back then.
Re: (Score:2)
Not in C. If you want the mathematical operators to work, you've got ints. typdefs don't change that. It's a fundamental failing in most languages that you can't create something that is as easy and efficient to work with as an int, but is treated as a different type.
Re: (Score:2)
Pascal, Modula, Oberon, Ada - they all do that. No idea about C++, I have to admit.
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:2)
It's a clash between people who get stuff done when coding, and people who'd rather argue for a few months about proper style and coming up with a team standard about precise variable naming. If your function is so long that you need to remind the reader what the variable is being used for on every line, then your function is too long and might be worth breaking it up.
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: (Score:2)
Well, since I have seen 100 char variable names (3 char difference sometimes) in Java _production_ code, I do not agree.
Re: (Score:3)
Re: (Score:2)
8x16 font at 2560x1440 is 320 columns. Very easy to see, plus you can emulate old CGA/EGA/MCGA graphics with just space character and background color.
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:2)
The point overall is to avoid hard arbitrary constraints. As long as the code is readable it's good.
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: (Score:2, Informative)
Funny how you say to "learn your history" after spitting out a well-known urban legend that isn't true.
https://www.saferack.com/railr... [saferack.com]
https://magazine.engineerjobs.... [engineerjobs.com]
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: (Score:2)
Ugh, there is some code in the system I'm working on that's a few thousand lines long. Now, people who've learned in school may have bad style, but too often I see the self-taught programmer who never had a mentor who ends up with the most unreadable code, or who seems the most baffled when someone asks to split a function into pieces.
Not many do flow charts anymore, or structured diagrams, but you're allowed to have several boxes sequentially in a row and it makes the charts easier to understand that way.
Re: (Score:2)
Ick. Also, breaking up into small functions means you have a chance to give each function a descriptive name, so the scope and concern can become self-documenting.
Re: (Score:2)
And unit tests for each chunk.
Re: Sense at last (Score:3)
I think you will find that VT220 had a 132 column mode.....
Re: (Score:2)
Yes, and when you printed it out on wide paper it was still pretty unreadable compared to 80 character mode.
Re: (Score:2)
I'd have had to put on my glasses though.
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: (Score:2)
I'm pretty sure that 132x24 was support on DEC VTs starting with the VT102 (I think it was a video option on 100s, which would only do 132x14 by default).
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)
Coding standards are bad (Score:2, Interesting)
Because they cement in bad ideas. Like the width of punch cards affecting modern code.
A classic was internal Oracle code which had a standard of 6 character identifiers for many years, you can imagine what the code looked like.
Spelling is another issue. The reason English spelling is so bad is because Johnston wrote a dictionary that defined "correct" and prevented fluidity.
Only the most anal retentive would have trouble reading code indented differently, or different line length, or other trivia.
Let it b
Re: (Score:2)
132 column text on a VT100-AA was somewhat unreadably blurry though.
The first place I remember 132 column text actually being clear was on a PC with a Hercules card and an amber display...
Re: (Score:2)
Never seen it on an actual VT102, but on the Vt220 with the green screen the 132 column mode was perfectly crisp if a bit small. Readability would depend on your eyesight I guess.
Re: Sense at last (Score:2)
When I started coding the screen had 40 characters. A wrapped line was limited to 120 characters.
Re: (Score:2)
And if VT100 terminals had an 80-columns limit, why weren't they called VT80?
Re: (Score:2)
And if VT100 terminals had an 80-columns limit, why weren't they called VT80?
Actually, VT100 terminals had a 132 column limit, but hey... The real limiter was the LA120, which printed on 132 Column green bar tractor feed paper.
80 x 25 was generally the standard due to backwards compatibility with punch cards, which limited line widths to 80 and 25 was 24 lines and a control line which makes sense for most programing languages of the day.
Yes, this is antiquated... But hey, having Nibbles, Bytes and Words defined as 4, 8 and 16 bits is an antique thing too.
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)
Note that the 80 character punch card did not mean you got to use all 80 characters for each line of code. Often you had to use the first few columns for other things, depending upon the language or OS. Ie, in Fortran you have to indent by at least 6 characters, depending upon standard or variant, some systems reserved 8 characters for line numbers for sorting purposes.
When 80 characters is given as the limit for coding, it's not meant as a challenge to fill up the entire line. Typically most lines are 5
Re: Sense at last (Score:2)
Some cards were 72 characters wide, and I think the ASR33 also was that. I remember the noise and smell from an ASR 33. I might have a punched tape from one in my stashes too.
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:2)
Re: (Score:2)
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:2)
... so that if you dropped your deck ...
Not if, but when. Been there, done that, very glad I don't have to use punched cards anymore.
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: Sense at last (Score:2)
Nope 132 is not arbitary, it ties in with the fact the VT100 and later terminals had a 132 column mode. Anything emulating a VT102 (which is like everything) should cope with it.
Re: (Score:2)
That still isn't what arbitrary means.
VT102 choosing it is arbitrary. Being compatible with it is arbitrary.
You could easily build a computer with a different number of columns and it would work fine. It is not a natural limit. It is a chosen limit that could have been whatever they wanted, but what they chose was convenient to them. That's arbitrary.
What isn't arbitrary, for example, is the frequency range of an LED intended to be viewed by humans. Or other things that you would calculate after observing n
Re: (Score:2)
The computer might work fine, but no one would be able to sell you a line printer that would print it. 132 columns was the width of paper used by accountants and, in case you don't know it already its the bean-counters wot counts the beans
No one will sign of the payments for a line printer of any other size.
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)
Wow, you got away with this? Lines with 164 characters in them are not easy to read. I hope your printouts had lines or shading on them.
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: Sense at last (Score:2)
I use descriptive variables mostly except for index variables that often are 1 or 2 characters like i, j, k, i0, i1 etc. As there's often no need to have long variables everywhere.
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)
Another one who likes 3 space tabs, so many heretics around here... It might be because I like a space between the if and the bracket, so with 4 spaces multi-condition ifs line up nicely. And also because 4 is the correct number.
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)
Whyever not? If I want to share the code with some group, and they don't like tabs, I can easily use one of several tools to convert them into the appropriate number of spaces, but for me they are much more convenient. So much so that I normally convert leading spaces to tabs when I import code.
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:2)
3 space tabs are a crime against humanity. You don't work for HiThere do you, they seem to like 3 space tabs too.
Next you are going to tell me that your editor is set to insert spaces instead of tab characters.
Re: (Score:2)
I solved this once and for all by not indenting any code ever.
Re: (Score:2)
Smart move. I guess you could fix the line length issue by just not using line breaks too.
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)
Your other examples make sense, but I'm not convinced by this one. Why should textbooks need narrower columns than novels? It seems more plausible that textbooks have huge margins because it's expected that some non-trivial percentage of their users will want to make annotations.
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)
Re: (Score:2)
If you're writing excellent code and then spending time reformatting some of it, that is going to be wasted time because it was already clear.
That's the problem with the arbitrary limit; it takes time from the people doing things right, and doesn't actually make the bad code readable.
Re: (Score:2)
Actually, it is not arbitrary and 80 chars is already on the long side. There is a line-length limit on the human side. Make things longer and stuff becomes very hard to read. Sure, there can be occasional exceptions but that is something different.
Re: (Score:2)
Arbitrary limits that approximate a reasonable value can make total sense. If we took away age limits to drive a car and said we'll make individual decisions based on maturity that would be pure hell to enforce with any kind of consistency and there'd be massive attempts to game the system. It's not like you level up and gain any great insight the day you turn 16, but it's easily quantifiable and you don't need to get into any long arguments about every case. Same with a character limit, maybe it doesn't ha
Re: (Score:2)
it's a totally arbitrary value
Well actually it wasn't a totally arbitrary value at all. It was value purposefully selected for a very specific reason, one which was mentioned over and over again in TFS.
Re: (Score:2)
No, it's nonsense. The problem is all the tools out there that want shorter lines. I have maximized my window once and still been unable to fit all of one dev's lines in it. If I go to a code review tool where it shows side-by-side code, then the team that doesn't follow such limits routinely has me doing horizontal scrolls just to see the code. Is the 'git diff' readable? Can you see the whole line in the automated build error that shows up in email? I don't care what your tool can do, it has to work w
Re: (Score:2)
Now the big problem is those language fashions that demand huge lines. C++ without having a "using" statement, where you can go 80 lines just naming a function - fundamentally broken in my view.
Is there some C++ style guide that bans "using" (or the old-style version "typedef")? That's stupid.
Re: (Score:2)
where you can go 80 lines just naming a function
Literally never happens.
Most calls to a function happen within scope - namespace scope, class scope, function local scope. None of those require full qualification.
For the rest, if you're reaching deep into a namespace or nested class to get the proper function, then that is a problem with design.
Re: (Score:2)
Readability is exactly why the 80 character limit should be enforced. Keeping it there lets you easily have *lots* of terminals open and visible at the same time.
If the coder isn't smart enough to be able to be reading multiple terminals at once, replace the coder.
Re: (Score:2)
Re: (Score:2)
The 80 column limit was not arbitrary but based on ancient technology of 80 column punch cards and serial based terminals such as VT100. Remember that RAM was expensive so constraining resources was a useful thing to do.
However, in modern times, the 80 column limit is too restrictive so I agree with the change in emphasis.
While they are at it, do we really need tabs with 8 spaces ? I suspect tabs are used to save RAM and so is historical.
Re: (Score:2)
There is nothing wrong with removing the limits. I'm an older nerd, and I started coding with 72 character IBM punched cards, which were based on Hollerith cards invented to program semi-automated looms. Yes, the cards contained 80 characters, but the last 8 were reserved for auto-sequencing punch machines. Once you got your code right, you ran it through the sequencer which punched the last 8 characters. Then if you dropped the deck, you could run it through the sorter and it would sort them back into the
Re: (Score:2)
Oh come on. I have a composite CGA display on an old TV. I need 40 columns so I can read the text.
But seriously. 100 columns I feel is good enough for most coding. 80 columns on modern displays is just stupid. Back in the days of 80 column monitors. They were 12" - 14" displays were common, with 640x480 resolution, when Linux started. Now those size displays with modern High-Res LCD Screens are incredibly small.
I would had chosen 160 columns myself. (using the old VT220 compress font settings)
Re: (Score:2)
Personally I like about 160 as it's 1/3 of a super ultrawide at my preferred font size. But this is the problem: it's an editor-side issue.
Line length is a stylistic rule and those are designed to increase readability by normalizing the appearance of code. However this can't be done with line length because a given length will look different in different environments. Better not to enforce a limit and let the editor decide.
(YMMV for languages where line breaks actually have syntactic meaning)
Re: (Score:2)
semantic meaning, rather
Re: (Score:2)
I find 80 character lines a good rule, but like all rules, they can be broken.
But before you break it, think about it. Maybe your variable name simply too long. Maybe your long formula will benefit from an intermediate variable. Maybe your indentation level is too deep and you should write a function. And if you really don't see how you can improve your code, go ahead and write that long line.
Over the years, I relaxed many rules of my coding style. But only after I giving it careful consideration. Line leng