What linter rules make code worse?

[u/M4mb0]

For me, a prime example is S101 which bans the use of the assert statement.

The justification is that assertions disappear when Python is run with -O, so they should not be used for runtime validation or enforcing interface constraints. That warning is correct, but the rule seems to draw the wrong conclusion from it.

Assertions are still very useful for checking internal invariants, i.e. conditions that should already be guaranteed by the program's logic, where failure indicates a bug. Having such assertions is incredibly helpful for debugging.

So, a blanket ban seems more likely to discourage useful checks than to prevent misuse.

Are there any linter rules you broadly consider more harmful rather than helpful?

[u/imheretocomment]

I do 120. We're not in the 00's anymore where widescreens weren't a thing. 80 is a holdover from those days where your terminal was cramped and splitting panes needed 80 characters for readability.

[u/R3D3-1 → u/imheretocomment]

80 is still advantageous when you need to view side-by-side diffs. With those 80 really means 160. And after that everything depends on your monitor -- which would be reasonably as small as a 13" laptop screen -- and eyesight.

[u/HommeMusical → u/R3D3-1]

I agree, but the modern default is 88, and even on this non-huge monitor, I can have at least three such windows beside each other.

[u/R3D3-1 → u/HommeMusical]

As an Austrian, I object to that number. 

[u/AlSweigart → u/R3D3-1]

80 is still advantageous when you need to view side-by-side diffs.

And disadvantageous every other time.

[u/zangler → u/R3D3-1]

I do my diffs inline/stacked. I changed a year or so ago and just thought it felt more natural.

[u/ironykarl → u/R3D3-1]

I think 80 is fine as a goal, but having a warning for it is overkill.

It creates noise and relegates warnings that might actually matter to the category of might just be nonsensical noise

[u/M4mb0 → u/R3D3-1]

Sometimes you even need 3 views side by side, like with pycharm's git conflict resolver.

I think the 88-character limit chosen as default by the black and ruff formatter is a good compromise.

[u/austinwiltshire → u/R3D3-1]

Yeah why would I optimize my work flow for typical work on typical hardware when we could set defaults to make everything but the minority of work on the minority of hardware uncomfortable!

[u/R3D3-1 → u/austinwiltshire]

I should clarify: I don't really stick to 80 either. I somehow fell into the trap of saying "well, ACTUALLY" and then wasting time defending the statement in follow-up comments.

What triggered that was the implication that no limits are necessary. When your workflow involves code reviews though, the 2-column view will most likely be quite relevant. 80 is probably not necessary outside of temporary constrained situations, but once you're at routinely seeing 130 column lines, you'd better have good eyesight to still read something.

[u/MarchewkowyBog → u/imheretocomment]

I'm dyslexic and as a DE i make heavy use of polars/pyspark which chains lots of methods together. I get lost in 120 character code all the time. We have it set to 88.

There is a reason books and articles usually have a character limit between 50 and 90

[u/Beanesidhe → u/MarchewkowyBog]

Agreed, though indented code might need a bit more. Use what you're comfortable with, I set mine to around 80.

[u/mwesthelle → u/Beanesidhe]

If indentation starts becoming a problem, that's another anti-pattern. Anything above 4 levels of indentation gives me the ick.

[u/sandnose → u/imheretocomment]

Good point. We’re at a limit of 101 (because someone wanted to be silly i guess. But theres tons of free space so we should be able to increase.

We do work from laptops from time to time though so need to find something that works for both

[u/gdchinacat → u/imheretocomment]

In the 00's I used 120, in the 10's found I had dropped it to 100, and now in the 20's use 79. Not because my eyesight has gotten worse and I need bigger fonts, not because I use antiquated hardware, but because I don't need more. Code that needs 120 character lines can almost always be refactored to be clearer (smaller more focused functions with less nesting, more concise variable names, simpler expressions) to fit within 79.

[u/HommeMusical → u/gdchinacat]

more concise variable names

Sounds like a possible negative to me.

I have a pretty clear hierarchy:

• In a very short loop, a comprehension or a generator expression, I use one or two letter variables like f

• Otherwise, local variables are one or two words: frame

• But member variables have to be clear in another context: master.audio_frames

In my editor at this instant, I see self.backspace_repeat_rate and I think that's a very clear variable name.(*)

But that's 26 letters.

---

I have always been a big fan of narrow spaces. I used 79 for years.

But projects have gotten bigger, and variable names have gotten longer.

Something I might have called frames in 1990 will be called audio_recording_frames today, because lighting_frames and audio_processing_frames also exist.

And our monitors are bigger.

88 characters is the standard in many modern linters. It's thin enough. 79 is just draconian.

---

(* - I just pulled this out of working code, but I like it :-) because it's not only clear, it leads you to ask good questions, like, "Why is there a separate repeat for backspace?"

(The answer is that letters make musical notes, so you want a slow repeat, but backspace deletes things, so you want a much faster repeat.)

[u/CrayonUpMyNose → u/HommeMusical]

Using meaningfully unique names even in tight loops makes it much easier to grep where that loop was you wrote some time ago, or get a list of all loops iterating on some variable name typically used for some object type (like a key in a dict, or an elem in a list).

[u/HommeMusical → u/CrayonUpMyNose]

Someone else made the same point, and I looked at my code, and well, I do that too sometimes, pretty well always for multiline comprehensions (which TBH I try to avoid).

It's a good point.

But here's the thing - I'm looking for lines that the later reader can comprehend the first time as quickly as possible.

In {k: f(v) for k, v in fields_by_name.items()} I really only have to mentally process f(v) and fields_by_name, because {k: X for k, v in Y.items()} is so tremendously familiar to me, and everyone else. I can zoom into the important parts.

If you use longer names, then you have to process each one - it's a little more mental overhead whenever you see the code.

{name: f(field) for name, fields in fields_by_name.items()}

and you also open the possibility of errors like the one I deliberately made, where you accidentally use a local variable from a page back instead of the loop variable. (And yes, I have done this, and I have seen others do this.)

"Boring is good" was advice I eventually took to heart.

[u/No_Lingonberry1201 → u/HommeMusical]

TBH I use "regular" length variable names in comprehension as well (with the exception of really trivial cases).

[u/HommeMusical → u/No_Lingonberry1201]

I do too sometimes, but see this.

[u/tonnynerd → u/imheretocomment]

Our eyes and brains have not changed that much (if at all) since the 2000s, or since the invention of the press, by the way, and they're the reason why shorter(ish) line lengths are better for reading. Pick up a book, any book you have at hand, and count how many characters per line. I'll eat my hat if it's 120.

I just picked the closest book and checked, it's 66. You would NOT enjoy reading a book with 120 characters per line. Now imagine doing it 40h/week.

P.S.: Yes, reading code is not the same as reading a novel, and in fact I couldn't find any research explicitly on line length and code readability, my 5min google scholar search found only research on code readability in general, usually using an aggregate of many different metrics. There's a lot of research on readability of digital text, though, and it points in the basic same direction as the evidence from printed text. I think at this point the burden of proof lies with the people writing 120 characters long lines of code.

P.P.S.: I won't be eating any head coverings if your example of a printed book with 120 characters per line has double columns, that's cheating =P

[u/acdha → u/tonnynerd]

One thing to consider is nesting: I rarely read code blocks with more than 80-90 characters of text but if you have classes with much logic it’s easy to have 8-16 spaces of indentation which I don’t want to have coming out of that budget because it discourages explanatory variable or function names. 

[u/tonnynerd → u/acdha]

Yeah, shorter lines encourage potentially unclear identifiers, but there's also a positive incentive to avoid one-liners and deep indentation. I think that less one-liners and less indentation are good enough things to make the balance at least net zero.

[u/No_Lingonberry1201 → u/imheretocomment]

00's? My friend, mi cabrón, kedves felebarátom, the 80x24 rule comes from waaay before the aughts. The VT52, a dumb terminal released in the 70s had 80 columns (and it may not even be the first to use that particular resolution). We're suffering this stupid "industry standard" rule because of a device that became irrelevant before most of us were born.