Comment by jajko | Hacker News Reader

Comment by jajko | Hacker News Reader

Parent Full thread

Not really. Obsessing over breaking lines after famous 80 chars in Eclipse was, is and will be idiotic to be polite. Surprisingly large amount of people were obsessed by this long after we got much bigger screens, if that was ever an argument (it wasn't for me). 2 spaces vs 4 spaces or tab. Cases like these were not that rare, even though now it seems better. That's not productive focus of one's (or team's) energy and a proper waste of money for employer/customer, it brings 0 added value to products apart form polishing ego of specific individual.

Folks who care about the craft obsess (well within realm of being realistic) more about architecture, good use of design patterns, using good modern toolset (but not bleeding edge), not building monolithic spaghetti monster that can't evolve much further, avoiding quick hacks that end up being hard to remove and work with over time and so on.

If you don't see a difference between those groups, I don't think you understood author's points.

I'd say avoiding long lines is one of the most important rules. I regularly have 2-3 files open side by side, I don't want to have to scroll sideways to read the code.

80 characters is a bit on the low end imo but I'd rather have the code be too vertical than too horizontal. Maybe 120-150 is a more reasonable limit. It's not difficult to stay within those bounds as long as you don't do deep nesting which I don't really want to see anyway because it's hardly ever necessary and it makes code more difficult to read.

Functional code is more chained and need more space often. Descriptive names are better; tends to be longer. Buy ultrawide.

80 is for aholes who like to use small laptop and then force it on everyone else. 120/150 is reasonable.

200 is great.

200 is entirely too fucking long, and I code on a 43” 4K. I try to stay under 90 in deference to others, and if it looks better breaking at 80, so be it.

200 allowed doesn't mean most lines will be. In general, 99% will be around 150 with a few places going high if it makes sense.

Yep.

And the laptop excuse is not even valid, I used a 11" MacBook Air for 10 years and even back then 80 always felt extremely limiting for me.

I just tested and: even when zooming +1 on VSCode and leaving the minimap open I can fit 140 chars without any horizontal scroll.

People demanding 80 columns always have some crazy setups, like an IDE where the editor is just a minuscule square in the centre, like an Osbourne 1 computer.

And 140 chars aren't enough for two files side by side with 80 chars. With a readable font size and a narrow font about 90 chars is a good limit on a 14" laptop screen. Coincidentally that same limit then allows for three files side by side on the average desktop screen - or a browser window at the side for reference.

If you can live with a single file on screen that's great, but the utility of two is far greater than having a chunk of the screen empty most of the time because of a few long lines.

If you need two files on the screen side by side, then it's time to use something bigger than the MacBook 11 with zoomed fonts from my example. :)

...unless you really want to prove grandparent's point.

If you do important work frequently on 14" screen and 2 files side-by-side (regardless of its resolution), then you are seriously self-limiting yourself and your efficiency, plus hurting your eyes which will inevitably bring regrets later. That's not how 'love for the craft' or ie efficiency looks like.

One reason I like longer lines, in those very few cases (way less than 1% of code lines) - it bundles logically several easy-to-read things, ie more complex 'if' or larger constructors. We talk about Java here just to be clear, for more compact languages those numbers can get lower significantly but same principles apply.

Doing overly smart complex one-liners just for the sake of it goes completely against what we write here, I've seen only (otherwise smart) juniors do those. Harder to debug, harder to read, simply a junior show-off move.

Try saying that again when you are 50 and your eyes no longer as good as they used to be. Back when I was 25 I loved the tiny fonts I could fit on my (then incredibly large) 19 inch monitor which I had pushed to the highest resolution. These days even with special computer glasses (magnification and optimized for computer distance) I can't make such tiny text.

Now get off my lawn you punks!

Crazy.

I am.

And that's why I said I use the zoom in VSCode in my previous message. My font is big as fuck compared to everyone else.

Also old. Also can not read the fonts my earlier self would use. Still do not understand the love for narrow columns.

I understand the age issue but you can always get a 42" display? LG C2/3/4 are amazing.

Reading vertically is much faster than reading horizontally, so I think 80 is a good soft limit. In some contexts it's hard to not go over it sometimes, e.g. in Java where it's not uncommon with very long type and method names.

Reporting as an Eclipse user of 20+ years, and a person who cares about the craft:

The choice for me is simple:

If I'm going to view the code I'm writing in a 80x24 terminal later on, I'll break that lines, and will try really hard to not get closer to 80 chars per line.

If that code is only going to be seen in Eclipse and only by me, I won't break that lines.

I omitted your other examples for brevity.

Having bigger screens doesn't make longer lines legit or valid. I may have anything between 4-9 terminals open on my 28" 2K screen anytime, and no, I don't want to see lines going from one side to another like spikes, even if I have written them.

I like 80 columns, I can tolerate 100 or 120. I get really annoyed with formatting standards, JS/TS in particular that waste a whole line for a closing brace. Standard aspect has screens more limited vertically than horizontally.

When dealing with tabular data, particularly test data, I find most formatting lacking. I want to be able to specify blocks that align on the decimal point. Especially when dealing with lists of dicts. This makes reading test fixtures much more intuitive than default indentation styles.

Has anyone seen a formatter where you can specify a block be formatted in that manner?

  [{'a':  3.89, 'b':  10},
   {'a': 12.3,  'b': 233}]

instead of

  [{'a': 3.89,
    'b': 10},
   {'a': 12.3,
    'b': 233}]

Preach!

Reply on news.ycombinator.com