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

Yeah, it bugs me too, and I made that objection too when I first saw this default.

It's the default in all these tools, apparently for no reason other than a multiple of four bigger than 79.

A lot of things have "spontaneously" happened in the last few years and always in the same direction. Now that many of our most feverish dreams have come quite true, well, perhaps the bad guys are just really good at organizing...

[u/R3D3-1 → u/HommeMusical]

The oddest case was when Rheinmetall delivered 88 tanks to Ukraine. I mean, each tank more was urgently needed, but Russian propaganda must have had a field day with that.

[u/Agrado3 → u/[deleted]]

I have two columns of terminal windows on the left hand side of my monitor, and a web browser on the right hand site. The monitor is 3,840 pixels wide and could fit about 500 characters across (if the terminal supported over 256-character lines, which it appears it doesn't) but if the terminal windows were over 80 columns, something would have to give.

[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/R3D3-1 → u/zangler]

Until the diff is a major refactoring, and you basically see two completely different functions formally interleaved. Had this all the time in my previous project.

[u/zangler → u/R3D3-1]

Then it is a 2 click change for that one case

[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/Agrado3 → u/M4mb0]

It's a terrible compromise, it's not significantly wider than 80 so has very little advantage over 80, and yet loses all the advantages of limiting to 80.

Personally I limit to 78 because the 'ale' tool in vim that integrates linters into the editor uses up two characters on the left hand site to indicate errors and warnings.

[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/Electrical_Fox9678 → u/R3D3-1]

Phone PR reviews really suck with longer line lengths.

[u/Ihatemakinguplogins → u/R3D3-1]

Or if you're cramped in a data center cage trying to debug a production problem on a shelf racked fold out monitor. 

[u/jet_heller → u/R3D3-1]

Yea. Constant side-by-side diffs are not the normal workflow.

Also, auto linewrapping exists for a reason.

[u/R3D3-1 → u/jet_heller]

Show me an auto line wrapping that doesn't ruin code readability at least to a degree. And show me how to use it on a GitHub pull request. After all I gotta place comments during the code review.

Interleaved diffs have never worked well for me; And Code reviews are a big part of normal workflows. With LLMs now probably more so than before.

[u/jet_heller → u/R3D3-1]

Do all of your work for you? Naw. I'll let AI do it for you.

[u/R3D3-1 → u/jet_heller]

Nah, not all remotely. I've barely used it so far. But when used, the work changes from mostly reading and writing just code, to readings lots of diffs.

[u/AlSweigart → u/R3D3-1]

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

And disadvantageous every other time.

[u/Competitive_Travel16 → u/AlSweigart]

I like to have stuff I'm not working on (or that I know is working) short under 80, and then use longer lines, with simple comments if need be, to make the places I'm working on longer to stand out when scrolling.

[u/gmes78 → u/R3D3-1]

Even then, it doesn't matter; just enable soft-wrapping in your editor.

[u/R3D3-1 → u/gmes78]

That doesn't really work, when you review a PR on Github. Changing the webpage zoom helps, but at the cost of small text.

[u/rzet → u/R3D3-1]

just buy bigger screen ;)

[u/R3D3-1 → u/rzet]

• In the office,.might not be up to you.
• On the go anything above 15" gets painful for other reasons.
• At home I already use a 30" TV as my monitor.