WHEREAS,

[aha@swiss.social]

@xahteiwi It makes sense if you only look at a single file. But line lengths beyond 100-120 characters (depends on the program you're using) start getting problematic if you like reviewing PRs side-by-side or if you want to have tests open simultaneously. If there were wider screens, I'd immediately buy one.

[puck@mastodon.nz]

@xahteiwi I want 4:3 screens again. I don't watch movies at work. 2x 16:9 screens side by side are too wide.

[gabe@mendeddrum.org]

@xahteiwi I have no strong opinions on values between 81 and 125, but more than that gets too wide to comfortably read and thus to readily understand.

Specifically:
* Backtracking a long way makes it harder to move directly to the next line, causing a context switch;
* Scanning down the beginnings of wrapped lines to see if there's anything important is faster than having to read an entire long one to find anything embedded along the way;
* If your statements are very long, reconsider them - they're not just a lot to read, they're a lot to hold in your head at once;
* But what if my teletype is a line printer???

(Edit: autocorrecto)

[hamatti@mastodon.world]

@xahteiwi I prefer rougly 80 characters both for code and prose on screen. Not as a hard rule but as a goal.

It's more readable when lines are shorter and it's easier to follow.

[xahteiwi@mastodon.social]

@hamatti Do you stand by the "more readable" assertion even if we're talking about decorators?

[haraldki@nrw.social]

@xahteiwi The point of a wide screen is not to give you wide code lines, but to have two windows with lines limited to 80 chars next to each other easily.

Have you ever read an old fashioned newspaper. The small columns had no technical necessity. They are just quicker to read without losing the current line.

[xahteiwi@mastodon.social]

@HaraldKi As asked elsewhere in this thread: do you find a hard 80-character line limit beneficial in conjunction with decorators?

[xahteiwi@mastodon.social]

@gotofritz Is your opening question about my statement, or yours?

[xahteiwi@mastodon.social]

@gabe Okay, would you agree with me that to be easily readable, method signatures should either define all arguments on one line, or one argument per line — whereas something like three lines, each specifying a different number of args, is really hard to read?

And if so, what are your thoughts on decorators?

[gabe@mendeddrum.org]

@xahteiwi
My rule of thumb is that all arguments should fit on one line* (not necessarily the one holding the method name), otherwise you probably want an Options object** or a different abstraction / encapsulation design.

For decorators, the limit is strictly two***, and loosely zero.

* That assumes reasonable names. The limit for single-letter arguments is zero, unless it's the only one, then there *might* be a case for exactly one such.

** Initialiser lists or chained setters or whatever are not the same as function call args. As option values, they're the protagonists of the statement, so you're only thinking about what properties or behaviours are being requested. As function args, the function is the main character, so you're putting each arg into the context of how it's getting transmogrified, which means holding and building more state in your head at once.

*** In python specifically, one decorator can turn a free function into an instance of some (dynamically derived) class with a particular method, which can be really helpful. That's one. Then I grudgingly allow one extra for common conveniences like memoization; it's easy to hold them wrong, but they're not confusing. Stacking more than two adds too much action at a distance, and using them as a weird way to pass arguments in an automagic context object is how "poorly considered API" is spelled in Java.

[xahteiwi@mastodon.social]

@gabe

"For decorators, the limit is strictly two***, and loosely zero."

Okay, so the likes of Django and Click are just Doing It Wrong, in your opinion?

[gabe@mendeddrum.org]

@xahteiwi I'm too old to declare that others are Wrong*.

Django picked a design pattern: interpreting directory and file structure interchangeably as the class structure, then elevating that to "the class is the instance!" because everything is (expected to be) a singleton, and then having to inject constructor options via decorators are definitely Choices.

Can things be achieved with it? Of course. It's just code, the compiler can figure it out.

Are there use-cases where it's really helpful? Of course, those first two circles won't draw themselves.

Does it stay maintainable over time, as applications and their complexity expand? Nothing ever just stays maintainable, but these particular patterns pile up poorly and are impossible to ever really refactor, so they make future development and maintenance ever harder over time - at best, they don't help.

But if you only ever want olympic rings, not an owl, it won't make much difference.

But then, neither will the line length.

* Even when they are.

[haraldki@nrw.social]

@xahteiwi

If you prefer

@Ignore @Test @WithTimeOut(11) @WithParams("da", "do") def testTheHell():
pass

they look ugly. But
@Ignore
@Test
@WithTimeOut(11)
@WithParams("da", "do")
def testTheHell():
pass

looks reasonable to me.

That said I like to add: decorators look nice at times, but thinking a bit harder usually helps to avoid them. Favorite example @Test to mark tests in junit. In olden times they used a naming convention for the test methods and it worked just fine.

[cazabon@mindly.social]

@xahteiwi

I like a little wider than a traditional 80-char screen, but in my experience going too wide hurts readability rather than helping it - basically if your eyes have to move more than a couple of times to read to the end of the line.

My personal preference is 96 (rather than black's 88).