Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
spl020438yI'd say mostly because you might want multiple windows side by side, to compare etc.
I still print code sometimes if there is a problem to look at; usually landscape in a small font because lines are usually > 80 ! -
Grumpy28878yWith 3 windows side by side, like in KDiff3's merge mode, you'd need a limit of about 60. That looks strange in all other situations except viewing a 3-way diff.
-
I do have three buffers side by side in emacs, they go as far as 90 chars.
I don't want to need to maximize my gitk window to read your code either.
Linux kernel has 80 max, and indent size at 8 chars. The rationale is that if the limit gets uncomfortable, that's because you are too deep in number of indentation level, and should refactor. Keep functions sweet and small.
Plus the longer the line, the harder to jump to the next line without missing one, or without starting reading the same line again.
Agreed, it's easier to do in C than Java. -
I spent a day on this.
Command line everything were working. when invoked through deamon "Not working".
It turned out default shell is only 80 chars, had to change
ps aw
ps aww
to get it to work
Mystery of the day: Why do some devs still insist that code looks bad if it exceeds 80 chars/line? These days, nobody prints it anyway and a 15" monitor can easily display 120 chars even with the font scaled up to be visible to my old, lousy eyes.
With .NETish names, lines like "var myVar = ConfigurationManager.OpenMappedExeConfiguration((fileMap, ConfigurationUserLevel.None)" tend to look weird when broken into 80 char lines.
undefined