Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is the 80 character line limit still relevant? (2008)

richarddingwall.name

Post reply on HN
Print view View original

61–70 of 180 posts

Re: Is the 80 character line limit still relevant? (2008)

#61

Post by xadren »

I largely prefer an 80 column limit. On my external monitors with no file tree open, I perhaps could utilise more columns comfortably, but that really falls apart if I need to work on my laptop's screen.

The side effect of this that I don't particularly love is having to split a function's arguments on to multiple lines. Usually if I'm at that point though, I'll probably end up having to split those arguments up event at a ~100 character column limit.

To me, splitting the arguments is the preferable of the two situations. I always want to be able to see the whole line.

Re: Is the 80 character line limit still relevant? (2008)

#62

Post by Tostino »

jvanderbot wrote: post #38
necovek wrote: post #35

Earlier quoted context omitted.

Consistency makes it easier to compare apples to apples and oranges to oranges. Just like you don't want to allow both underscore_split, camelCase and TitleCase names in a single JSON object (or even different JSON objects returned by the same API), you might want more consistency overall to exactly avoid people's editors rewriting code someone else did (eg. you edit a module and your editor reformats the entire file…

Well I just want to fix the bug or write the feature and move on, but some want other things from their code.

That's the thing, without a standard formatter, a lot of IDEs use whatever their rules are. You can end up playing tennis because you just want to get that bug or feature done, you modify a couple lines of code in file X, Y, and Z, and now each of those files got reformatted by your IDE.

Re: Is the 80 character line limit still relevant? (2008)

#63

Post by swatcoder »

jvanderbot wrote: post #38
necovek wrote: post #35

Earlier quoted context omitted.

Consistency makes it easier to compare apples to apples and oranges to oranges. Just like you don't want to allow both underscore_split, camelCase and TitleCase names in a single JSON object (or even different JSON objects returned by the same API), you might want more consistency overall to exactly avoid people's editors rewriting code someone else did (eg. you edit a module and your editor reformats the entire file…

Well I just want to fix the bug or write the feature and move on, but some want other things from their code.

Yours is a good attitude in an org with thousands of engineers, where every change gets mediated through some process tool simply to avoid chaos. You'll be messing up the system if you step out of your lane, and you statistically don't even care about some particular project's health and future anyway.

It's not a great one in smaller teams, which benefit from everybody quietly sweeping up whatever bit of the mess they run across. Not to say that justifies the petty and sometimes passive aggressive "tennis" that can happen in that world; that's just unprofessional ego-feeding behavior.

Re: Is the 80 character line limit still relevant? (2008)

#64

Post by dqh »

echelon wrote: post #58
dqh wrote: post #57

An 80 character limit is difficult to stay within when using highly descriptive variable names, and I think the benefits of highly descriptive variable names outweigh other considerations.

It's not impossible if you're using an indent of two spaces and not doing a lot of nesting. I think 100 characters would be a better limit, though.

Yes, not impossible, but in my opinion requiring a waste of energy.

Re: Is the 80 character line limit still relevant? (2008)

#65

Post by lcnPylGDnU4H9OF »

PeterWhittaker wrote: post #28

> formatting tennis That's a paddling. Seriously, professionals do this? If someone else wrote it and it does what it is supposed to do, it is not, NOT (no apologies for shouty emphasis), my job to change that. (I hate tabs, but will never :retab someone else's code.) My job is either/both to fix bugs and add new capabilities, not to be precious about, well, anything. I would have serious reservations about any team…

Since we’re already on a Holy War About Arbitrary Things topic (and at the risk of igniting the whitespace wars anew), do you mind expanding on this?

> I hate tabs

This opinion seems common but I haven’t seen a practical argument against tabs among practical arguments (for an admittedly niche situation) in favor of tabs. This seems an appropriate place to ask about it.

Re: Is the 80 character line limit still relevant? (2008)

#66

Post by malfist »

eikenberry wrote: post #56
bigstrat2003 wrote: post #49

80 characters is way, way too short. I think 120 is a decent spot for today's displays, although I don't mind even longer than that either.

IMO 120 is the extreme limit but a good limit. Anything higher than 120 is to long and, personally, I'd ask for that to be fixed in a code review.

120 is way too small. IMO 180 is a good limit. We're not on 800x600 screens anymore

Re: Is the 80 character line limit still relevant? (2008)

#67

Post by DeliriousDog »

rusk wrote: post #13

65-80 for readability however once you introduce indentation this naturally increases. I always felt that shorter lines were a good way to encourage less nested code. Alas after all these years the consensus is against me.

Completely agree on limiting yourself reducing the nesting of code.

There is more difficulty working with code such as

if x { //... } else { //... }

Than code like

if x { // returns from this block } // execution continues

In some legacy code I sometimes encounter very long chains of checks which nest 4-8 layers, which becomes very difficult to maintain a mental model of where you are in execution at any point. I try to refactor into the second pattern from above when possible.

Re: Is the 80 character line limit still relevant? (2008)

#68

Post by qingcharles »

eikenberry wrote: post #56
bigstrat2003 wrote: post #49

80 characters is way, way too short. I think 120 is a decent spot for today's displays, although I don't mind even longer than that either.

IMO 120 is the extreme limit but a good limit. Anything higher than 120 is to long and, personally, I'd ask for that to be fixed in a code review.

I just bought an ultrawide, and I just checked to see how wide my lines are in my code editor. 350 characters.

When I'm coding for myself, I use all of that at times. I love that there are some things I no longer have to break onto multiple lines any longer.

Also, if you have a ton of nested loops etc, then you don't end up with that problem where you can only see the first few characters of the deepest lines.

Re: Is the 80 character line limit still relevant? (2008)

#70

Post by lcuff »

>at a comfortable 10 point font size.

How lovely for you. As someone with significantly impaired vision, even when corrected, I have my font size set to 18, thank you very much. A coding standard that assumes a 10 point font size would violate the Americans with Disabilities Act's 'reasonable accommodation' mandate. I wasn't pushy enough to act on it, but it sure pissed me off when my fellow team members blew off my complaints about how we formatted our code. (Including two space indents...grrrr.) My worse than 20/200 vision (Can't see the big E on an eye chart) lets me see code, but legally, I'm blind in one eye.

I admit, it's a classic 'no perfect solution' scenario, because I like very long variable and function names. I write tiny functions (5-10 lines) because they only need one or two levels of indent. Some programmers I've worked with really dislike such small functions.

Post reply on HN