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.
Instead of agreeing apriori on a standard format for all files forever, it's better to disable formatting in your IDE (except auto-indent which should follow their format). That's what mine does anyway.
No it's not, it's perfect. You want to be able to do side-by-side diffs on your laptop using a normal sized (not tiny) font. You want to be able to paste snippets into design documents and emails and blogs without accidental wrapping or truncating or scrolling. 80 is nicely legible. It works really well.
Actually no I don’t want to be able to work like that on a laptop monitor. I’d rather optimize my full screen real estate. There in lies the conflict.
Since in most cases, most lines don't even reach 80 characters, or they're long enough to still wrap at 120, there's not a lot of optimization going on.
Going from 80 to 120 will net you, what -- an extra 2 or 4 lines in your viewport?
It's not worth the optimization when you lose so much for the reasons I described.
Just because some people like to have a single pane of text cover their entire 16:9 display doesn’t mean I should have to. I find very vertical text much easier to follow. Wide lines are usually wide due to nesting and chaining, either of blocks or of inline expressions. Both are a thing which should not be. Concisely and clearly define one concept or abstraction. Then, use it in the next definition. This isn’t hard!…
It's hard if you don't know how to do it... and lots of people don't know how to do it.
I mean, spelling the word “CAT” is hard if you don’t know how to do it, but as spelling goes, it’s pretty easy.
It’s true that some people are illiterate and never learned to spell. That doesn’t mean it’s hard, it just means they never learned how.
I agree with you that writing readable and aesthetically pleasing code is more art than science (that can be expressed with deterministic rules), I still find some of the rules and rule-checkers beneficial (though I dislike strict formatters). As such, 80 is as good a limit as any, and makes you think carefully about avoiding deep nesting of blocks, which is usually a good idea anyway. It also allows putting many win…
I have to push back here a little bit. It really depends. I mainly use Scala, and I think the majority of Scala code would be far less readable if forced to 80 columns, than if it were a larger number (or simply unconstrained). My WFH monitor is an Apple Thunderbolt Display, which is woefully out-of-date now. Even on this display, and even though I use a much larger font than most people (16pt Hasklig), and even with…
Unfortunately, while the monitor on my desk has gotten bigger, I've got this screen that I hold in my hand that's smaller than any desk monitor, and it's in portrait, not landscape mode, so while I don't write code on it, I do read code on it, so now, ideally, we'd accommodate that use case as well.
Note that when we talk about line length limits, we're actually conflating two separate concepts: 1) The maximum width of our viewports 2) How long we want our lines to be WRT the second concept, the general rule of typography is that a line should be 60-80 characters long. But, crucially, this is not counting indentation; a "line" here begins at the start of the text, not at the start of the margin. In the modern da…
Is there a single formatter capable enough for this?
Any formatter that already wraps on line length is capable enough for this, it's just a matter of taking the existing line length check and adding a single new conditional.
What kind of monitors does your team use? I view diffs side-by-side all the time with much wider lines than 80 chars, but I have 27" monitors, which are not unusual these days.
All of my main external displays are 27". The diffs fit perfectly on them with the 80 character limit
You must have your text size set to 18pt or something, because I can easily fit 3-4 columns of 80-char text on my 27" monitors.
I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions. I think an autoformatter with the config checked into git is a nice way around this.
> I agree this is terrible primarily because it muddles up any git-blame based workflow for debugging regressions. ...it occurs to me, this feels like you're conforming to the tool instead of the other way around. Is there a reason git blame doesn't have an "ignore whitespace" option? Is it harder than it seems?
It’s more than white space, autoformatters can change a lot, notable will often change line numbers by introducing or removing breaks