I started a new project at work last week and they have Prettier settings defined so I did my due diligence and made sure I’ve been formatting new source code files accordingly.
One thing I noticed in doing so is that the settings cutoff limit for wrapping was set at 120. This threw me off a little because 20-some-odd years ago, when I was learning C in school, it was drilled into me that this should be 80. And since then I’ve (loosely) been trying to stick to that.
So I was wondering, does anyone else stick to a number?
I’ve worked in some codebases that have various rules like this (line limits, linting), but I don’t value them much outside of keeping a shared workspace clean and consistent.
For my own code, or code with only a few authors, I tend to eyeball things like this depending on context. Sometimes things get wild when you’re editing code with a bunch of horizontal space that’s taken up by an assistant editor / inspector and all of your lines with long identifiers get wrapped. (CNLabelContactRelationYoungerCousinMothersSiblingsDaughterOrFathersSistersDaughter or whatever).
I’ll keep comments limited to column 80, but I’ll let other lines run longer, up to 120. 80 can be rough when dealing with functions having more than one or two parameters with types.
What’s your rationale there? One thing I find interesting in recent updates for editors like Xcode is that documentation comments aren’t rendered using a monospace font. (I think there was an Adobe MAX demo in that vein a few years back as well.)
One documentation project I spent a few years on used grammar-based (or prose-based) line breaks. The style generated some pretty readable diffs in scenarios where we had lots of group code reviews and discussions.
I use a monospace for everything, including comments. Block comments in particular I keep within 80 because it keeps things easier to read for large amounts of text. The 120 is usually a line here or line there, so when it goes past 80, its generally infrequently. I find keeping things within 80 is the most readable simply because it means less horizontal scanning.
I have a column 80 ruler line visible in my code editor as a guide. I’m not sure how it would work for proportional fonts, but if was a average or 80 w’s or whatever, it would think it’d work just as well.
Just saw this today, which is related (though targeting Dart, not JS). Excerpt from The Hardest Program I’ve Ever Written:
At this point, you’re probably thinking, “Wait. What’s so hard about formatting?” After you’ve parsed, can’t you just walk the AST and pretty-print it with some whitespace?
If every statement fit within the column limit of the page, yup. It’s a piece of cake. (I think that’s what gofmt does.) But our formatter also keeps your code within the line length limit. That means adding line breaks (or “splits” as the formatter calls them), and determining the best place to add those is famously hard.
Something that came up recently from Linus Torvalds:
… But no, 80-column terminals in 2020 isn’t “reasonable” any more as far as I’m concerned. People commonly used 132-column terminals even back in the 80’s, for chrissake, don’t try to make 80 columns some immovable standard.
If you choose to use a 80-column terminal, you can live with the line wrapping. It’s just that simple.
