SoylentNews is people
SoylentNews
from the depends-on-whether-you-code-using-emacs-or-vim? dept.
Are 80 Characters Per Line Still Reasonable In 2020?
[...] In case of the Linux kernel, that's of course [Linus Torvalds], who has recently shaken up the community with a mailing list response declaring an overly common, often even unwritten rule of code formatting as essentially obsolete: the 80-character line limitation. Considering the notoriety of his rants and crudeness, his response, which was initiated by a line break change in the submitted patch, seems downright diplomatic this time.
[Linus]' reasoning against a continuing enforcement of 80-char line limits is primarly the fact that screens are simply big enough today to comfortably fit longer lines, even with multiple terminals (or windows) next to each other. As he puts it, the only reason to stick to the limitation is using an actual VT100, which won't serve much use in kernel development anyway.
Allowing longer lines on the other hand would encourage the use of more verbose variable names and whitespace, which in turn would actually increase readability. Of course, all to a certain extent, and [Linus] obviously doesn't call for abolishing line breaks altogether. But he has a point; does it really make sense to stick to a decades old, nowadays rather arbitrary-seeming limitation in 2020?
The article then gives an overview of the history of how 80 columns became the de facto standard width. Though mentioned briefly in passing, it all really got started with the invention of the punched card dating back to 1804 when "Joseph Marie Jacquard demonstrated a mechanism to automate loom operation". The physical size of the punch card used in the 1890 United States Census was the same as US currency at that time. The cards were then known as "Hollerith cards" after the inventor Herman Hollerith. Later, IBM came to dominate the field.
As technology progressed, punch cards eventually gave way to computer terminals such at the IBM 3270 and "glass TTYs" like the DEC VT05 and Lear Siegler ADM-3A.
Computer languages were even designed around that common size. Both FORTRAN and COBOL had fixed line layouts with certain columns reserved for such things as sequence numbers, comment indicator, continuation marker, as well as the code itself.
Human factors play a role, too. A newspaper could, for example, have lines of text as long as the page is wide. It was found to be difficult to connect visually where the next line would start when one reached the end of a physical line. Hence multiple columns of text on a page. The same often holds for magazines, too.
Back to the question at hand.
I have personally used punch cards, FORTRAN, COBOL, and all of the computer terminals listed. I generally aim for 80-columns in the code I write, but I am flexible about it. Should I find that 90-100 columns better allows me to express and comprehend the code I've written, I'll err on the side of using more columns. A quick look through some code I've written revealed one case where I used 132 columns.
What about you? Hard and fast limit of 80 columns and not a single column more? 80-90? 100? Whatever it takes? Where and how do you draw the line?
(Score: -1, Flamebait) by Anonymous Coward on Saturday June 20 2020, @03:07AM (6 children)
I used it once. Why support legacy shit that nobody uses?
(Score: 1, Touché) by Anonymous Coward on Saturday June 20 2020, @03:18AM
Damn straight. Get rid of ASCII and Unicode and just use Emojis
(Score: 2, Interesting) by Ethanol-fueled on Saturday June 20 2020, @03:20AM (4 children)
Because, if you used a modern IDE like Eclipse or Visual Studio, you'd see that 75 percent of your monitor real-estate is filled up to the ass on the left and right by toolboxes, explorers, and other bloated toolbars, leaving you with only a tiny column in the middle to actually look at code.
Somewhat related, I'm working on a personal project using the Nano 33 BLE Sense board to use its sensors to automatically adjust the monitor to/from portrait/landscape orientation when the monitor is physically flipped. It will use its internal magnetometer, rather than the gyroscope, to measure position. The reason for that decision is because using gyros to get position requires a lot of ugly math and error corrections, and won't register change of state when the monitor is moved during power-down. That means using the magnetometer will require a 1-time zeroing in each position, and possibly again if the user intends for the monitor to be physically translated as well as rotated. It will communicate of course via bluetooth because fuck extra cables on a monitor stand, though it could also be done wired using serial. The form factor will be roughly like a small pack of gum and will be powered by a watch battery or two, using the board's low power mode to save juice when appropriate.
But since I'm a lazy fuck surely one of you now has enough information to do it yourself before I get it done.
(Score: 2) by JoeMerchant on Saturday June 20 2020, @03:24AM (3 children)
I hope you meant accelerometer... getting monitor orientation from a magnetometer would be needlessly challenging.
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Saturday June 20 2020, @04:49AM
Not really. It has a 3-axis magnetometer, so all he'd need to do is have it poll every so often for a change from strongly on one axis to strongly on another. But he'll want a fairly weak magnet to place on the stand do that with. One problem I noticed from a quick glance at the datasheet is that particular board's magentometer looks like it can easily be swamped by even a refrigerator magnet, as it looks to be designed for use as a compass or the like.
(Score: 2, Interesting) by Ethanol-fueled on Saturday June 20 2020, @04:53AM (1 child)
Not in this case, the magnetometer readings hold steady and differ with each position, I've already tried it. It's a 3-axis magnetometer that's very configurable with regard to gauss range and other parameters. If there are problems a combination of accelerometers+gyro+magnetometer could be used.
Accelerometers + gyro register only the rate of change, so you're only getting zeroes with the monitor still. You have to get position by integrating and fucking with error terms, and if you move the monitor with the system powered down, the movement won't register when the system is powered up (unless you want to do the flip event within the Arduino if even just as a physical button press). The magnetometer gives steady but easily differentiable values that change with position and not velocity. The calibration and flip events will be handled on the Windows system side using a background running application that hides in the notification area.
(Score: 3, Touché) by JoeMerchant on Saturday June 20 2020, @12:20PM
Are you on the space station?
Where I work, and where my products get used, accelerometers point down. On a dynamic platform like a small aircraft you'd want to add a gyro to keep track of dynamic rotations and integrate the accelerometer, but on a stable desktop there's no need for that.
Magnetometers get all kinds of screwy inside of commercial (steel frame) buildings, and cars, and the angle of declination changes pretty significantly as you move around the planet.
🌻🌻 [google.com]
(Score: 5, Insightful) by JoeMerchant on Saturday June 20 2020, @03:21AM (6 children)
Nothing wrong with how Linus expresses himself - abrasive is O.K. for somebody with his position/role.
80 character lines are needlessly restrictive, and have been ever since 1920x1080 monitors became a de-facto standard (and actually long before that too.)
It causes problems with grep, it causes problems with descriptive variable names, it causes problems with basic readability of code, and anybody who doesn't see the obviousness of that can go back to their punch card machines and wring their hands for a few more years about backward compatibility - the rest of us won't even miss you.
🌻🌻 [google.com]
(Score: 3, Insightful) by Anonymous Coward on Saturday June 20 2020, @05:01AM (3 children)
It is rather unnatural feeling to read stuff near the right side of a too-wide window. In my browser, I use an extension with window-resizing function to keep it at a sensible width most of the time.
Given that I use 19 pt font in my code editor (I do not have a spare set of eyes, do you?), keeping code at under 80 chars width is sensible for the same reason.
However, as Linus said, 80 is not a hard limit anymore, and a linebreak to split a mere 86 char line in two is indeed a silly one. 100 or 110 chars is no problem either, if the line is better left unbroken for some reason.
(Score: 0) by Anonymous Coward on Saturday June 20 2020, @12:17PM
Apparently I do, because I read screen wide texts all the time, and it works wonderfully for me. Maybe it's just you.
(Score: 1, Insightful) by Anonymous Coward on Saturday June 20 2020, @04:08PM
exactly my feeling as well, but an observation;
The closer to the hardware - the more preferance for the old short form.
Which makes sense to me because someone who might have to debug on actual equipment wouldn’t want the hassle
(Score: 2) by driverless on Sunday June 21 2020, @02:58AM
Going to 100, or a soft increase on 80, so 80 if possible but up to 100-110 if it would make the code look messy, is fine. However allowing infinite-length lines makes code really difficult to read, I'd rather have an excessively-complex expression on one line broken down into a few logical blocks over several lines than have to try and interpret a 300-character line that scrolls off the right of the monitor. Soft-80 is probably the best compromise between readability and displaying stuff appropriately.
(Score: 0) by Anonymous Coward on Saturday June 20 2020, @05:28PM (1 child)
yeah, i never have followed any stupid restriction of my char length. I base it on what's reasonable for my monitor. If the reader has a vastly different sized monitor, i don't really give a shit.
(Score: 3, Informative) by https on Saturday June 20 2020, @10:34PM
I really don't want a subordinate with this attitude ("works for me, wontfix") wasting other of my subordinates' time on a project. You erase value.
Offended and laughing about it.
(Score: 3, Interesting) by legont on Saturday June 20 2020, @03:24AM (12 children)
I also started with punch cards. Actually, with a four holes tape, but it was not productive for me.
This code width is good, trust me. It is a compromise all right, but as a target it is good. Does not have to be precise though.
"Wealth is the relentless enemy of understanding" - John Kenneth Galbraith.
(Score: 2, Insightful) by Anonymous Coward on Saturday June 20 2020, @03:35AM (6 children)
Long lines suck. Whether 80 chars ought to be the limit is debatable, but there is a reason newspapers do thin columns. Is it really necessary to have function names like eatYourCakeAndMaybeHaveItToo?
I'd much favor dropping ridiculous quantities of indent to two spaces.
(Score: 4, Interesting) by JoeMerchant on Saturday June 20 2020, @03:38AM (2 children)
Reading a newspaper column is very different from procedural code... quite often code concept align like a table, and laying it out as a table is 200% more readable than following some arbitrary line width rule that has nothing to do with the last two decades of reality.
🌻🌻 [google.com]
(Score: 3, Interesting) by zocalo on Saturday June 20 2020, @08:12AM (1 child)
For a data point I just pulled a bunch of random lines of text from the various tabs I currently have open that were long enough to wrap on their own and have a similar presentation to here - e.g. without massive sidebars full of other content - as that is going to be pretty close to what I consider comfortable to read; YMMV. There's still a bit of difference due to layout, what borders they do have, etc. but they're all in the range of 160-180 characters acrosss. This is on a 4K screen though, so the text is very clear (I have about 2x the effective real estate as my 1080p next to it), which is likely to play a significant part in that though.
For code, yeah, 80 needs to go. No one is printing out code on fan-fold dot matrix printers any more. Whatever works best for a given block of code within reason should be fine - it that's still 80, then so be it - so maybe push it up in the coding style guide to 132 or 160 (the next two commonly supported screen and dot matrix printer widths) and see how it works out?
UNIX? They're not even circumcised! Savages!
(Score: 0) by Anonymous Coward on Saturday June 20 2020, @10:02AM
Instead of the number of columns/characters.
The real problem here is making lines so long they either go off the end of the screen, or code so complex that deciphering it with a careful reading is difficult.
We already can compact code blocks, so being able to compact elements, but get rid of arbitrary line widths would go a long way to making development cleaner in all but the most badly maintained code.
Furthermore a good reason for the longer more verbose variable names, is not just for descriptiveness, but also to have a better chance of avoiding a keyword when language revision XY comes out and suddenly decides a bunch of new keywords were needed, one of which was the simple and descriptive variable name you use all over your code and just happened to slip into a few API/ABI calls, which now need to be altered to conform to the new language standards (difficult if not impossible to predict.)
(Score: 0) by Anonymous Coward on Saturday June 20 2020, @06:37AM (2 children)
Wide, long, hard.
Pick 2.
(Score: 3, Funny) by kazzie on Saturday June 20 2020, @09:07AM (1 child)
We don't want to know about your bedroom habits, thank you.
(Score: 0) by Anonymous Coward on Saturday June 20 2020, @12:16PM
Not to worry, he's just coding in bed.
(Score: 5, Insightful) by coolgopher on Saturday June 20 2020, @03:38AM
I like 80 or thereabouts. Too long lines and it gets harder to follow across line breaks (which is why even online news papers use a columnar format). Sticking with 80 is easier than finding The One True Optimised line width. And by default all my terminal windows open at 80 wide, and I get five of them next to each other, which is /almost/ enough for what I want for my development needs. Having different files open next to each other is gold. Yes, I also open multiple files within the same editor/window, but that fulfills a slightly different need (generally one involving copy/paste).
(Score: 0) by Anonymous Coward on Saturday June 20 2020, @03:48AM (1 child)
Amen !!!
This has been a bitch for decates. 80 columns and 24 lines are great frame work to work with. It presents all the information in size that is easy to scan and read. !32 columns, 256 columns or what ever thunk size you want, means the code is NOT all visible at the same time. Otherwise you will print change you font ot 3pt to just get it on the screen.
I worked on large project for almost 20yrs (1.5M lines of code and another 500k of assembler to support it... Our standard was 80 columns - even thought the system supported up to 192 columns. And if a routine took more than 2 pages to display (48 lines w/ meaningful comments), then it was too big and unstructured! Required programmer to rewrite it. We actually added that to the processor to kick an error and prevent check -in.
IT is time to think not in terms of how dense you can code... but how readable and structured, so looking at the source you actually SEE the code and functionality. I do not want to read and stroll right and left and try to see the whole code.
Try reading web pages, where they do not care about the line length let alone meaning structure. yeah yeah html is structured... then read obscure C code then. Just proves the point.
(Score: 2) by maxwell demon on Saturday June 20 2020, @05:10AM
Note that the stuff you get served is very likely not the stuff the developers are working on (if they are actually writing HTML directly, which is increasingly rare these days). The stuff served is optimized for minimal size (because the bytes your server sends cost you), and bad readability of the code which gets delivered to arbitrary visitors (including your competitors) may even be an explicit goal.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by Dr Spin on Saturday June 20 2020, @08:04PM (1 child)
Actually, with a four holes tape,
It was five hole tape - as used for telex upper case only and a shift system to switch between numbers and letters.
And it ruled the world for over 100 years. You cannot beat standards.
And people who won't comply with standards should go and die in a ditch.
You will never take my VT220 out of my cold dead hands (cos its an ANSI terminal emulation).
Warning: Opening your mouth may invalidate your brain!
(Score: 2) by Muad'Dave on Monday June 22 2020, @12:48PM
That 5 bit encoding, known as Baudot [wikipedia.org], is still used over the air in RTTY (radio teletype) [wikipedia.org] transmissions.
(Score: 4, Insightful) by shortscreen on Saturday June 20 2020, @03:50AM
My editor uses a 9x16 bitmap font and I set the window size to 1024x768. That fits 113 characters per row, which I would say is just right. It also leaves room on the screen to refer to more than one window at a time.
(Score: 1, Touché) by Anonymous Coward on Saturday June 20 2020, @03:53AM
But what is that pedantic ass in a code review to complain about now?
(Score: 2) by looorg on Saturday June 20 2020, @03:59AM (2 children)
I'm not strict about it anything, sometimes the lines get a bit longer then normal -- or longer then I like them to be and that is still ok. That said I'm still basically of the mindset that I prefer many shorter instructions, not necessarily one per line anymore, instead of having one giant line that does a lot of things. Perhaps it should be called asm-brain. But then some other languages and tasks seem to lend themselves to just creating these long lines of piped instructions one after another. They tend to become a bit of a mess imo. I would rather scroll up and down instead of left and right. Perhaps it's more about when you learned to program and then that just sticks with you. Also I'm not really big on long and informative variable names and comments, to much typing, since they only have to make sense to me so there is no need to have hundreds of chars per line.
(Score: 5, Insightful) by fishybell on Saturday June 20 2020, @04:09AM (1 child)
Don't forget about future you.
I can't say how many times I've ended up looking back at code 5 years later only to have to thoroughly deep dive it to understand what the variables are actually doing. Coding in a team has helped me with that: if junior devs can't read it, it may as well be unreadable.
(Score: 2) by looorg on Saturday June 20 2020, @04:13AM
I do admit that that is or have become an issue from time to time.
(Score: 5, Insightful) by fishybell on Saturday June 20 2020, @04:06AM (18 children)
Original diff that was rejected (which fails in the worst kinds of way):
Diff I would prefer:
The push for saving a few characters here and there makes so much code so unreadable. Yes, too wide of lines makes code unreadable, but not as a bad as arbitrarily lopping off one parameter. Also, what's wrong with longer variable names? Are the extra three characters at the end of "buffer" too much? When is coding really slowed down by typing speed vs. everything else that goes into it?
(Score: 2) by JoeMerchant on Saturday June 20 2020, @04:15AM (12 children)
Diff I would prefer:
-----
I can C clearly now, the brain has gone.
🌻🌻 [google.com]
(Score: 2) by JoeMerchant on Saturday June 20 2020, @04:17AM (11 children)
Wow, should have previewed...
Diff I would prefer:
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Saturday June 20 2020, @05:00AM
That is an interesting one I'll have to think about. That alignment is interesting. A part of me prefers the style of always having the final comma and having the first argument on its own line as well. But other than that, I'll have to give it some thought. Maybe align all of the type declaration? Hmm. The gears are churning.
(Score: 2) by maxwell demon on Saturday June 20 2020, @05:18AM (3 children)
I don't like the left-ragged types, nor the split-off commas or closing parenthesis.
What's wrong with the following?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 1, Funny) by Anonymous Coward on Saturday June 20 2020, @06:40AM (1 child)
I get the impression of violinists contrasting techniques on the deck of the Titanic.
(Score: 2) by maxwell demon on Saturday June 20 2020, @11:03AM
I don't see the set of languages with C-like function declarations to be sinking any time soon.
Languages with mostly this style of declaration include
Languages with function declaration similar to Pascal-style (basically C style with order of type and name reversed) include
These lists are not claimed to be anywhere near complete. Note that I omitted languages that are mostly or completely obsolete.
Indeed, I expect the majority of new languages, whenever they include mandatory or optional static typing, to roughly follow either a C style or a Pascal style function declaration (the third option would be a Fortran style declaration, but I think that one has fallen out of favour a long time ago).
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by JoeMerchant on Saturday June 20 2020, @12:10PM
Matter of preference - I prefer the type to be closer to the variable it applies to.
The split-off commas are an acquired taste which can be more palatable in larger table like structures - particularly sparse ones where they help identify a pattern that's not 100% consistent.
Spaces after the parenthesis: I like to alternate those, makes it easier to identify matching open and closes if they have matching space or no space. I generally start with a space ( makes it easier to read the enclosed text (but it's a small thing) ).
🌻🌻 [google.com]
(Score: 2) by bart9h on Saturday June 20 2020, @11:19AM (2 children)
I like to think the * as part of the type, so I prefer
(Score: 2) by JoeMerchant on Saturday June 20 2020, @12:13PM
Fair point, I'm just stuck in my ways with the * on the variable. Drove me nuts when &references started becoming popular, at least the editors in IDEs mark them as distinct from variables passed by value.
🌻🌻 [google.com]
(Score: 4, Informative) by acid andy on Saturday June 20 2020, @03:06PM
Watch that doesn't catch you out (in C and C++).
//You may think b's a pointer to an int. It's not. It's just an int.
int* a = 0, b = 0;
//b is a pointer to an int here.
int *a = 0, *b = 0;
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 2) by Thexalon on Saturday June 20 2020, @09:17PM (1 child)
I have a different preference for the extra arg or two, which often runs afoul of the code style police.
I guess you could call this "right-justify".
The point of this is to reduce my eye movement when reading: I'm already on the right side of the line by the time I know that additional arguments are coming, so it's right there to finish the list.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by JoeMerchant on Saturday June 20 2020, @09:31PM
I used to stick with the single line most of the time, but I've taken to the vertical list lately, particularly for stuff like:
I also like to line up open and close parenthesis / brackets vertically, like:
but as they say, it's guidelines more than rules. I will say that this:
drives me up the damn wall, particularly when it's non-trivial stuff in the function. When I see code like that in my projects I know it's something that I've copy pasted in and haven't really reviewed yet. After review it would look more like:
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Monday June 22 2020, @01:33AM
If you like your commas aligned so much, put them in front.
-ssize_t __kernel_write(struct file *file, const void *buf, size_t count, loff_t *pos)
+ssize_t __kernel_write(struct file *file
+ ,const void *buffer
+ ,size_t count
+ ,loff_t *position
+ )
Easier to check for missing commas. Even if the line extends off the screen...
Heck if you want even more stuff aligned:
-ssize_t __kernel_write(struct file *file, const void *buf, size_t count, loff_t *pos)
+ssize_t __kernel_write
+ (struct file *file
+ ,const void *buffer
+ ,size_t count
+ ,loff_t *position
+ )
(Score: 1, Interesting) by Anonymous Coward on Saturday June 20 2020, @04:58AM (1 child)
I don't understand the value of placing each parameter on its own line. People generally understand what buf and pos are, just like i and j are understood as counters in loops. In other cases when the variable's purpose is less obvious, I'd be all for avoiding abbreviations, though I don't think it's necessary in that instance. Extending a single function call across several lines reduces the amount of code visible on the screen at any particular time, which actually makes code less readable. If I want to understand what a block of code does, it's easier if I can see more of the block of code at once. Needlessly long function calls make that more difficult. The original function call with everything on one line is just fine with me. But yes, use more descriptive variable names when it's less obvious what the variables do.
I like the use of wide tabs for indenting code, something that Linus also mentions in his post. I prefer to just press tab once for each level of indentation. It's wide enough to make it readable. Plus it's quicker than having to press the space bar many times to achieve the same indentation, though some editors do this automatically. While I'm on the subject of indentation, the programmer should be able to decide how much indentation is needed for their particular use case. Indentation should not be used by compilers or interpreters to delineate the beginning and end of control structures. Python's use of indentation to define blocks of code is an absolute abomination.
(Score: 0) by Anonymous Coward on Sunday June 21 2020, @02:57AM
A lot of these conventions date back to when people exchanged diffs through mail and centralized systems like CVS. They make the code changes much cleaner while also making it easier to parse in your head. For example:
The closing brace aligned with the if statement shows what your closing scope is. Each parameter on its own line makes it more obvious what types and variables you are dealing with while making the actual changes easier to spot in the diff. And try parsing something like that in your head when the declarations are more complicated "int const * const x, int * const y, int const * z" or includes structs or other complicated types. Once you get the variables in your head, you don't really have to refer back to them; and when you do because there are too many or you lost your source reference it is easier to spot the one you are looking for when it is spread out rather than in a bunch so you can quickly get back to what you were doing.
(Score: 2) by coolgopher on Saturday June 20 2020, @05:09AM
Nothing at all wrong with the original in my view (even if I'm largely in the 80 camp). All arguments have sensible names (i.e. easy to understand, and not too long), and with only four of them it's easier to read on the one line with the added bonus of easy "grep"ability. Besides, "buf" and "pos" are as canonical as "i" in a for loop.
(Score: 2) by jb on Saturday June 20 2020, @08:53AM (1 child)
Why not just put the return type on a line of its own, i.e.:
Not only does that fit on the screen more easily, but if applied consistently across your code base, it also gives you the benefit of being able to find any function definition quickly with a simple `find . -type '*.c' | xargs grep ^name_of_function`.
(Score: 0) by Anonymous Coward on Monday June 22 2020, @11:01PM
Perhaps you should look into K&R, as opposed to ANSI, style.
(Score: 2, Funny) by Anonymous Coward on Saturday June 20 2020, @04:53AM (4 children)
It was used by millions of programmers on the Apple II and Commodore 64. If you need more columns than that, your code is too complex, and you need to refactor it. I was going to say a limit of 32 columns like on the Vic 20 is best, but we shouldn't let ourselves be held back by ancient standards.
(Score: 2, Funny) by Anonymous Coward on Saturday June 20 2020, @06:42AM (1 child)
140 char limit and you can pretend your on Twitter every time you newline. Famous as fuck.
(Score: 1) by tedd on Sunday June 21 2020, @12:42AM
+1 for true old Twitter, not 280 new, fake Twitter.
(Score: 4, Touché) by PiMuNu on Saturday June 20 2020, @08:54AM
40 cols is ez if u use shrt var nms.
bttr:
40 x1 x2 x3 x3 x4 x5 x6 x7 x8 x9.
but hrd to rd.
(Score: 2) by JoeMerchant on Saturday June 20 2020, @12:26PM
your variable names might be descriptive enough.
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Saturday June 20 2020, @05:42AM
I'm using a 20 point font for coding these days. My screen is big too, so going over 80 isn't a problem, but going over 90 is because the text pane is not the only thing I'm looking at.
(Score: 4, Insightful) by Anonymous Coward on Saturday June 20 2020, @06:06AM (2 children)
I think there's a human interface factor at work here.
There may also be a typewriter factor in here somewhere. How many columns wide is the typical typewriter? About 80, I think.
I haven't seen anyone mention printers yet. Source code that cannot be printed cannot be passed around in meetings.
So I think it needs to be short enough to be printed in landscape mode and still be big enough for older people to read easily.
(Score: 4, Touché) by Dr Spin on Saturday June 20 2020, @07:32AM
Source code that cannot be printed cannot be passed around in meetings.
Source code passed around in meetings?
Next meeting: remember to pass the Worcestershire source, and avoid the code of political correctness.
Warning: Opening your mouth may invalidate your brain!
(Score: 3, Informative) by JoeMerchant on Saturday June 20 2020, @12:30PM
Good, last time I passed around source code on paper the year started with 19.
Anybody been in a conference room without a 30"+ monitor in the last 10 years? Mostly we do screen-shared remote meetings now.
Any code refactoring we've ever attempted to do live in a meeting quickly filled a paper page with red-ink that became illegible/incomprehensible. Showing the diff live on a screen works much better, and easier if you aren't artificially bound to an 8.5" wide display format.
🌻🌻 [google.com]
(Score: 2) by turgid on Saturday June 20 2020, @09:56AM (6 children)
I have the misfortune to work on a lot of Java code in Eclipse. Some of the lines of code are 350+ characters long. It drives me mad. When I write C I use vim and I like to have three xterms side by side so I can see my code, my unit tests and my refactoring.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by bart9h on Saturday June 20 2020, @11:23AM (1 child)
Why don't you write Java in Vim too?
Even in cases where I can't set it up to do my coding completely on the terminal, and am forced to use an IDE for some reason, I edit in Vim and alt-tab to the IDE.
(Score: 2) by turgid on Saturday June 20 2020, @11:46AM
I do when I can, but for my paid employment, the development environment is heavily integrated with Eclipse. The amount of code I write is relatively small there at the moment. When I need to write something from scratch, I have scripts for writing Java boiler plate which I edit in vim, get working and then integrate with the main project. It saves hours.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by JoeMerchant on Saturday June 20 2020, @12:34PM (3 children)
I thought it was only Python that got bent about whitespace...
When your line of code is getting out of hand \
there's usually something that you can do about that.
🌻🌻 [google.com]
(Score: 3, Funny) by turgid on Saturday June 20 2020, @12:37PM (2 children)
We have double monitors. I use one for the Windows stuff and the other for the Linux development work. Some people have their X desktop spread across both monitors, and their Eclipse window full screen...
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Insightful) by JoeMerchant on Saturday June 20 2020, @02:46PM (1 child)
I've always leaned toward long lines but splitting across monitors is ridiculous.
🌻🌻 [google.com]
(Score: 1, Funny) by Anonymous Coward on Monday June 22 2020, @06:04PM
It helps to add a few extra spaces around the 150 character mark. So the gap doesn't spit a word in two.
</sarcasm>
(Score: 3, Interesting) by Common Joe on Saturday June 20 2020, @10:15AM (15 children)
I know this opinion runs counter to most people, but I prefer longer lines for two reasons.
The first is that every time an indent is made, you lose 4 characters. In Python, you indent for classes and then again for methods. With 80 characters, that's 10% of your space gone (72 characters left). Have a simple method with an outer loop and an inner loop with an if statement in the middle? That's 5 * 4 = 20 characters gone. If you use long variables names (for clarity and readability), then things get awkward really quick.
The second reason is that it would be nice to have IDEs auto wrap code and comments to the size of my window. There's definitely an argument to be made for keeping lines of code as short as possible. But comments? That should be autowrapped to the size my window. Manually putting in enter marks is awful. Some IDEs have auto-format which I hate because then it messes up the patterns I purposely put into the code which made it readable in the first place. I agree with auto-format about 98% - 99% of the time, but the other 1% - 2%? I'd prefer to keep my code and comments formatted that way for readability reasons.
That's my two cents (on an html-favorable site that lets the user decide how many characters per line they want.)
(Score: 2, Disagree) by maxwell demon on Saturday June 20 2020, @11:10AM (5 children)
Only if you insist on using 4 space indents. I never understood why people want this; I think it is not only ugly, but reduces readability compared to 2-space indents. With 2 spaces, you clearly see the indent, but still can have both line beginnings at eye focus at the same time.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 4, Touché) by Anonymous Coward on Saturday June 20 2020, @11:27AM (4 children)
If only somebody would come up with some abstract character which represented a level of indentation. Then one could adjust the width of the display layer based on individual preferences.
(Score: 2) by Common Joe on Saturday June 20 2020, @11:32AM (1 child)
I'm all for this for the reason you gave. Unfortunately, it is not the standard that most people want and I am therefore forced to use spaces when I code. I picked on Python in my earlier comment because using 4 spaces (not a tab) is actually part of the Python standard.
(Score: 0) by Anonymous Coward on Saturday June 20 2020, @12:26PM
I like 3 blanks, 4 isover kill.
I also like no more than 4 insets pre line. If you get there, then create a meaningful function blocks and pull the rest into there. Then there are few lines per thought, more high level coding (actual pseudo-code can run!) with meaningful names.
Hell many decades ago, I class project was to change a 20-line BASIC function into Assembler (PDP-11 - the "root" of C). I just did not get my head around that problem, so 1hr before class looked up the MACRO language for the ASM. I wrote a "print", "if", "for", "next" and other BASIC functions in MACROs as needed. Copied and Pasted the BASIC routine in and sent to "compile" and run. Turned that in about 3 mins before class and apologized to the instructor for the number of "pages", he was also my college counselor, and headed to class for the final day. The instructor showed up to class 10 minutes late with a stack of papers and handed out the my solution to class. He copied photo copied my answer and handed it out, then went thought my solution and spend the next hour talking about future of computing and being able to slide between thought patterns and keep ideas tight and clean to present information best for next person to read, see and understand..
PS: As a class we constantly tried to give the tightest code option for the problem. We use number of bytes of ASM to be our "Dutch-Auction". I won or tried many times. But that one, I came in at ~1200 bytes vs ~130 bytes for the "best" one. Learned that day, small tight code is not always the "best" solution.
(Score: 2) by JoeMerchant on Saturday June 20 2020, @12:36PM
Heretic! at least you didn't say the name of the beast.
Nothing worse than that format method being ported from one system to another (which happens all the time).
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Monday June 22 2020, @01:43AM
(Score: 3, Insightful) by stormwyrm on Saturday June 20 2020, @11:21AM (8 children)
I have rarely ever indented more than five levels, including the indent for classes and methods. If your indents are getting deeper than that, that's a warning sign that shit's approaching an unacceptably high level of local complexity and some refactoring is probably in order. Deep levels of indentation are very rarely so irreducible: in many cases some of the deeply-nested parts are actually important enough they really deserve their own names as functions/methods in their own right. Also, if you find yourself often using in complex ways variables whose purpose is so complex that you cannot come up with suitable names for them that are at the same time terse and self-explanatory, it then that's another warning sign that some rethinking is probably warranted.
Numquam ponenda est pluralitas sine necessitate.
(Score: 3, Insightful) by Common Joe on Saturday June 20 2020, @11:49AM (7 children)
I agree with you in that indenting more than five levels should be rare, but it's hardly unheard of.
By breaking things apart like you suggest, we occasionally lose readability. If we have a very linear computation with multiple input variables used throughout, then by breaking it apart into objects or other subroutines, you lose the ability to see everything in a single view. Yes, it may mean scrolling a little bit, but there is a flip side. I've seen one line subroutines -- as in it has a single if if statement that should have been just put directly put into the method. But I also understand that sometimes you want to read programs on a more abstract level, so one level can help you abstract thought into another level.
I'm also not saying that a long piece of code is correct either. Often times, it is very justified to break it apart for readability and reuseability. It's very dependent on the situation. My big beef on this front is too many people reciting these "rules" without understanding that it's readability that we're after, not "following rules". Following standards is good... until it isn't.
And some things just have no nice way of being programmed. It can be ugly any which way you do it.
Finally, I find too many variables names are too terse. People are afraid to have multi-word variables. They'd rather make an acronym that is only three letters long which I come across later and wonder what it means. (And good luck finding documentation or comments on it.) I often find multi-word variables help readability. A common opinion I receive is that people like reading my methods, but hate writing my variables names. I find that pretty amusing.
(Score: 5, Insightful) by stormwyrm on Saturday June 20 2020, @01:03PM (2 children)
Numquam ponenda est pluralitas sine necessitate.
(Score: 2) by JoeMerchant on Saturday June 20 2020, @09:16PM (1 child)
Some of us are more human than others.
Most of us forget how we did things just a few years ago and even our own cleverness can be completely opaque if it isn't illuminated somehow.
🌻🌻 [google.com]
(Score: 2, Insightful) by Anonymous Coward on Sunday June 21 2020, @02:13AM
(Score: 4, Funny) by acid andy on Sunday June 21 2020, @10:48AM (3 children)
Yeah code that's very heavily broken into small functions and lots of classes may make it easier to quickly get a high level understanding of it, but it can quickly become very irritating once you have to step through it all just to find whereabouts you need to insert a bug fix or add a feature, unless you wrote it all yourself, that is.
It's become a running joke for example that a lot of enterprise Java code has far too many layers of abstraction chasing too little functionality.
I hate to link to the Other Site (oh forgive me!), but this was posted before ours existed. Someone posted a hilarious enterprise Java version [slashdot.org] of a BASIC one line maze program, which illustrates the issue beautifully!
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 2) by Common Joe on Sunday June 21 2020, @06:39PM (2 children)
I hadn't seen this before. That was hilarious. Thank you for the laugh. I needed that.
And thank you for posting a link that illustrated so beautifully what I was trying to say.
(Score: 2) by acid andy on Sunday June 21 2020, @08:05PM
You're welcome. It was one of the funniest code jokes I'd seen in a long time as well. It was lucky I could remember enough about it to find it in duckduckgo. In the comments someone said it came from reddit.
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 1, Funny) by Anonymous Coward on Monday June 22 2020, @01:49AM
See also: http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html [ariel.com.au]
(Score: 5, Interesting) by Rosco P. Coltrane on Saturday June 20 2020, @10:18AM
But it has one redeeming feature: if you're forced to fit your code in it, you start thinking hard about readability, descriptive variable names that are short enough to be used nimbly, and expressions that are concise yet efficient.
In short, the arbitrary restriction forces you to write cleaner, more maintainable code.
(Score: 0) by Anonymous Coward on Saturday June 20 2020, @11:22AM (2 children)
The 80-column format is a common denominator of screen formats for all devices. 40 column looks pixelated even on a small screen, 120 is hardly readable even on 15-inch display. So it's more a viewing compatibility thing for me than a strict requirement.
I write e-mails with 80-column mode and it is really nice for readability on all devices - I can read it horizontally, or vertically, when I use PDA like a book. It can be viewed in a smartphone or a book reader too.
The problem with wide lines is that you don't know what font programmer has and how the code will be shown. I like my "gut-like" 4096x1536 display set, but text good looking there (a format of larger newspaper) looks awful even on "HD" displays.
When coding, I don't necessarily stick to 80column, but I prefer it.
(Score: 2) by bart9h on Saturday June 20 2020, @11:27AM (1 child)
You must be almost blind.
My vision have worsened considerably in the recent years, so I'm using a stupdily huge font size for the terminal, and it still has 141 columns on a 15" screen.
(Score: 1, Insightful) by Anonymous Coward on Saturday June 20 2020, @12:45PM
Probably you're operating full-screen. In a full-screen, a 140 column is good if a font is good. I was operating this mode for decades in Lotus spreadsheet (14-inch screen) until I met poor Linux fonts in which it was just impossible as everything was so thin that it was unreadable. The white bleed caused by flat screens has also important role to make everything but serifs blurry. Fortunately, modesetting can be patched to use different font and not switch back.
About full-screen - Modern applications are written with no respect to user's memory or CPU, so full-screen applications are more and more common, rendering machines single-task again.
Meanwhile, I have a favorite tmux set-up which is a quad-80column on a 20-inch screen.
And I found that it is impossible for me to reliably read console wider than 80-columns on my PDA, which is around 5.5-inch.
(Score: 0) by Anonymous Coward on Saturday June 20 2020, @06:16PM
I generally try to avoid code going past 80 cols, but if it does, it does, and I won't bother lining it up all fancy-like on a new line.
I also use a tab width of 4. Considered dropping it to 2, but it just makes blocks harder to decipher at a glance.
(Score: 1) by bloodnok on Saturday June 20 2020, @06:19PM (3 children)
I think a better way to look at this is what is the advantage of longer line lengths?
I try to write within 80 columns but I'm not obsessive about it. If a statement cannot be reasonably formatted to fit in 80 columns, I let it it go over.
The only consideration should be: is the code readable? And if you're working in a team that has to mean is it consistent with the code that has gone before.
The times that I find long lines irritating are when there is more indentation than code, or when I cannot read a line without having to scroll sideways, or expand the window so much that I can't have multiple windows open side by side.
80 columns is, these days, an arbitrary limit. But so is any other limit. For me, 80-columns works just fine and other developers seem to have no problems reading my code.
Allowing longer lines as the norm just means that you've moved the line-wrapping problem to the right: it doesn't, in itself, solve anything. Coding is a discipline. Making your code readable and consistent is an act of discipline and a sign of respect to your colleagues who may have to read and fix it.
In the past I've had disagreements with other developers about this. They would usually show me a section of their code which "required" more than 80 columns. I have always been able to reformat such code to make it fit, and be, to me at least, more readable. And at that point I always gave up the fight because the piece of code that I'd modified was now the only part of their code that I could easily read. Making one part carefully and thoughtfully structured would provide such a contrast with the rest of their code that the whole thing looked like crap.
In my projects I will continue to require 80 columns as an advisory limit. I believe there has to be a limit and 80 columns allows me to use 2 editor windows side by side on my laptop. Paradoxically, allowing wider lines forces me into a mode of working which is much more like the VT-100 days as I have to either give up the utility of multiple windows, or give up on seeing whole lines of code.
(Score: 2) by JoeMerchant on Saturday June 20 2020, @09:18PM (2 children)
For me, it's patterns. When the code is doing a bunch of nearly redundant stuff, like hooking up properties to UI elements, or somesuch. If each line can represent one of the nearly identical steps, that table of code is much easier to read than two or three lines doing each step over and over. Variations in the pattern, intentional or unintentional, show up much faster in table form.
🌻🌻 [google.com]
(Score: 2) by JoeMerchant on Saturday June 20 2020, @09:23PM (1 child)
as opposed to:
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Saturday June 20 2020, @11:32PM
Just put a blank line in between the groups of related statements and there is no readability problem
(Score: 2) by cosurgi on Sunday June 21 2020, @01:11PM
For yade[1,2] development we configured 160 chars in .clang-format profile. In my private ~/.clang-format I use 210 chars.
[1] https://yade-dem.org/doc/ [yade-dem.org]
[2] https://gitlab.com/yade-dev/trunk [gitlab.com]
#
#\ @ ? [adom.de] Colonize Mars [kozicki.pl]
#