Hacker News Reader

So are you saying sometimes you want to initialise a variable without ever doing anything with it afterwards? That that's not the result of a typo down in your code in the vast majority of cases?

I mean, I'll be the first to agree that blocking your development in the heat of it over some stylistic issue like quote styles is counter-productive, but if those rules are turned off and the rest help you catch actual bugs (and it's hard to argue that it does not), then that's surely a plus?

(Also, why wouldn't linters know types?)

It hasn't been my experience. I have had to deal with linters probably about 15,000 or so hours of my work life (luckily that's only about a third). It's been probably between 99.4% and 99.8% just acrobatic dog tricks to satisfy the linter.

It's not like I'm some grumpy malcontent that hasn't given it a go.

If you want to use it go ahead, I just thought I'd be standing in a larger crowd

Not sure what these “dog tricks” you speak of are. Have the linters you’ve worked with had ”—fix” options such that you don’t need to do anything besides save the file?

Aside, it’s funny that you dismiss linters as being for “type A folks who must have everything in its right place”, but your concerns seem to be that you want things in their right place and the linters won’t let you. The folks who use linters have decided worrying about it isn’t worth it and just let the linter do its thing, which is less “Type A” than how you describe yourself.

That wasn't me. It's a nice visual but I think it's mostly for fun.

I'd say it's mostly hammers on porcelain. A coder carefully creates something (porcelain) and then the hammer comes around and insists it has to be a perfectly shaped commodity thing.

Same reason and emotion I guess behind both.

Oh, misread authors I guess.

In my case, 99% of the time I’m fine with what the linter spits out. In cases where I want a particular structure I just wrap ignore directives around the section and move on with my life

we probably just code different things for a living. It's a big world. I'm sure they're useful in your job.

Could it be that the problem with the linters you've experienced was that they were just configured far too strictly about things that don't matter too much, rather than linting itself being the problem?

I've got my linters set up pretty loosely, but the things that are enabled have definitely helped me detect bugs earlier and quicker, and I really don't see how anyone could be against that.

well sure. There aren't bad tools just bad practitioners, sure. Certain tools give more affordance to certain use cases and maybe that's the issue.

For instance something where I am the culprit would be in PHP. I like PHP. I think it's a convenient and powerful language. Someone could take my linter arguments and weaponize them against PHP because it's too easy to do terrible things with it. Then I'd be the one on the other side of the argument all of a sudden, standing in defence of this easy to use language with handy powerful abstractions that can trash a system in a few keystrokes.

I think the difference is when we can come to an agreement that say, PHP is a very powerful tool in competent hands and a very dangerous tool for the foolish.

Going back to the topic at hand, I think the foolish side of linting is the dominant application I see in the wild. I used to use a barrage of proto-linting static analysis tools in my CVS scripts during the wild C days because pointer logic and memory management was notoriously tricky and gcc 2.x was notoriously forgiving. These tools could save days of debugging, really, yes, days.

If we can do that for say python it'd be great. Something saying "Oh I see you are doing a list[1:] in a tight loop, have you thought about collections.dequeue? it may be a better option" - those things are things I do actually forget about and would find helpful.

It'd have to be voluntary though. Prod me a bit but then let me dig my own grave if it's a mistake. That's what the power of computing is also about.

Yep, I can definitely agree there.

That said, I'd argue against strict stylistic rules, not against linters in general. For example, the common Javascript linter (ESLint) has a setup wizard that allows you to choose whether you just want to check for bugs, or also enforce style conventions, and will enable a predefined set of rules depending on your choice. The bug-spotter is the one that's preselected. This is a very reasonable approach to me.

I will agree with you that shitty linters are shitty.

> Maybe you want multiple spaces to vertically align code in a complex set of logic. Maybe you want to express things on multiple lines to break them up. Maybe you have deep nesting so you want to go from 4 spaces to 2. Maybe you want no braces in a single line if statement except in certain cases. This could go for pages. Poof! All gone. You can't do any of it anymore.

Literally none of these should be flagged by a linter IMO, except maybe the braceless if[1]. If those checks are present I would disable them. Those sound more like a code-styling tool, and is particularly egregious because every single thing you mentioned could be automatically changed by a code formatter!

Examples of things a good linter will pick up on: Unused variables, dead code, use before initialization.

The most absurd case of a linter helping was when fixing an unused variable lint warning actually allowed me to speed up a program by almost a factor of 100 (it precomputed a value and then called the version of the function that didn't use the precomputed value in a tight loop).

[edit]

Do you disable warnings in compiled languages? Note that linters for non-compiled languages are used at least partly to catch things that would be warnings or errors in a compiled language.

1: No braces in an if statement should probably be flagged when the THEN clause is on a separate line because it's a future bug waiting to happen, but I can see the argument for allowing it when it's a single-line statement. OTOH if (foo) {bar();} is only 2 characters longer and 4 if you put whitespace between the braces

> If those checks are present I would disable them.

The purpose of linters on a team - so I've been told - is so that no one has to argue about formatting anymore.

So now we just get to argue about what rules we can enable/disable?

Even though it's perfectly legal to disable linting for lines or files, most of the time when I do it, it's flagged by someone in review, and there's some discussion and I'm forced to rewrite and remove my disable and go back to whatever the linter was forcing. "These rules are there for a reason, and were put together by people with more experience and smarter than us - we shouldn't go disabling things whenever we want just because we don't like them or think we know better". (amalgamation of multiple comments from people stopping me disabling lint checks in specific situations).

This doesn't happen every time, but enough that the occasional 'disable' isn't something I can just do without worrying it will end in multiple hour discussions. Which is probably what people want - unquestioning conformity to "the one true way".

> The purpose of linters on a team - so I've been told - is so that no one has to argue about formatting anymore.

Code formatting is just one feature a linter may have (e.g. shellcheck[1] and pyflakes[2] are definitely linters but don't have code formatting checks).

I disable all the formatting checks in my linters because if I want to enforce a formatting standard, a code reformatter is probably a better way to do it.

1: https://www.shellcheck.net/

2: https://pypi.org/project/pyflakes/

> The purpose of linters on a team - so I've been told - is so that no one has to argue about formatting anymore.

People who argue this are, I believe, missing the forest for the trees. A short on-the-spot version of something I've had in mind for a long time:

almost everyone has a slightly different style that they fall into and the individual styles arent necessarily difficult to understand

AT LEAST WHEN USED ON THEIR OWN, AND NOT MIXED WITH OTHER STYLES.

Your Brain Adapts To A Given One, When Reading That Style. It May Still Feel Like Stuttering, But Once Adapted It's Fully Readable.

Evensomeonewithareallybizarrestylecanbereadwithalittleefforttofigureoutwhatthatstyleis.

The problemcomeswhen You have MULTIPLE people OnA team, and THE SYLES getallmixedupsoittakes a lot moreefforttofigureoutwhatTHEFUCKisgoingon.

Linting is all about picking a style and sticking with it so the code doesn't end up with multiple personality disorder.

> Even though it's perfectly legal to disable linting for lines or files, most of the time when I do it, it's flagged by someone in review, and there's some discussion and I'm forced to rewrite and remove my disable and go back to whatever the linter was forcing. "These rules are there for a reason, and were put together by people with more experience and smarter than us - we shouldn't go disabling things whenever we want just because we don't like them or think we know better". (amalgamation of multiple comments from people stopping me disabling lint checks in specific situations).

When this happens, I think it should open a wider team conversation about whether that particular rule is actually worthwhile, or whether it goes against what your team wants and should be altered/disabled. Unfortunately, I have encountered a couple rules where the linter wasn't configurable enough to get what we wanted as a team, so there's definitely reason to allow per-instance disabling...

> It's fine for protecting against profound levels of incompetence but I don't do that and you probably don't either.

Everybody starts at a profound level of incompetence. If you want a junior to be able to make a contribution and you don't want to spend half of the pull request discussing mundane aspects of their code style, then linters and formatters improve the situation somewhat.