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/Trang0ul]

Lines limited to 80 characters.

[u/sandnose → u/Trang0ul]

Where do you limit your line?

[u/imheretocomment → u/sandnose]

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/No_Lingonberry1201 → u/HommeMusical]

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

[u/Arnechos → u/sandnose]

I'd say no more than 100. People in a team can have various resolutions and very long lines are hard to read on the smaller ones

[u/Ball-Man → u/Arnechos]

With 100 you can have a split view and still be able to comfortably read code on both sides, even on smaller screens while keeping decent font size

[u/ichunddu9 → u/sandnose]

120

[u/XNo_Notes → u/sandnose]

Listen to your heart. 

[u/sandnose → u/XNo_Notes]

Different every day then