Am I the only one that dislikes linting?
Btw, you don't have to respond with the talking points I've heard all my life on why it's supposedly great, I've obviously heard them and think they're bogus.
I just find it strange that I'm the only one.
Btw, you don't have to respond with the talking points I've heard all my life on why it's supposedly great, I've obviously heard them and think they're bogus.
I just find it strange that I'm the only one.
In my experience a little hand crafting tweaks to formatting go a long way to increasing understandability.
It feels like a lot of people are having issues with bikeshedding and they're using enforced autoformatters to impose their will and stifle debate they may not like.
Not arguing about style is nice, but having to resort to this brutalist architecture style of code formatting doesn't seem great to me. "Its just holding people, who CARES what the building looks like!"
Also thing like line-length limits. I'm with Linus on this one, enforce line-length limits causes a lot of problems, like breaking context in greps. And an autoformatter that breaks at a certain number of characters is never going to be able to understand the context to break it intelligently.
Are people using editors that don't display long lines wrapping properly? Do people think everybody uses the same resolution, the same window size, the same columns per terminal, etc?
almost every rule has an exception where understandability could be improved by violating the rule, ex. line length. code format is huge for understandability/readability, which makes it worth paying attention to while you're writing.
in my experience the loudest advocates for code formatters are the ones who write really complicated code; which makes sense that they just hammer on code until it works without being able to reduce and simplify their logic and naming.
As a freelance/contractor, my environments change, often daily/weekly.
I routinely switch between Java, PHP, Vue, React and some other tools. Doesn't matter WHAT I do, I end up having some stupid red squiggles telling me I can't use "double-quotes" or that I can't use 'single-quotes', depending on context. Multiple languages and 'community standards' conflict with each other, and I'm always constantly having to double check things and 'clean up' stuff.
And... conforming to all of these various 'standards' has not increased the speed of development, nor the robustness, nor the client satisfaction. It does mean that some people who place a high value on standards and listing and visual style are placated.
Increase of automated testing and documentation have more value - long term and short term. And I understand it's not an 'either/or', but visual style and 'linting' standards are low-hanging fruit that are immediately visible, so tend to get more attention (and ongoing).
And then in group discussions, I end up being the person who is apparently "AGAINST CODE STANDARDS". I'm not terribly against them, but in the projects I end up being involved in, it's lower value.
I've got project one which insisted - the point of blocking PRs - that "Yoda style" for null checks was mandatory. Guess what? Another project I'm on, Yoda-style is prohibited, because "it's confusing". Every keystroke I'm having to wonder/worry about what context am I in, and always battling stupid red squiggles.
If you spend 40+ hrs/week using one and one one tech platform where you can have one standard to follow and adhere to - great. I switch platforms, teams and projects regularly, and it's soured me on the huge importance some people place on linting.
This times a million. It doesn't help that the advocates of linting are so dogmatic about the whole idea (as demonstrated so colorfully in this thread and this sub-thread in particular). I mean, I understand why. Linting is an all or nothing type of thing. But I'm still going to remember the lint-advocate as a developer too concerned with the wrong things.
As someone in the former group, I completely agree that these sorts of things bring little value; the fact that the code works is the most important, regardless of how it looks. If your coworkers are writing code that's not working or misleading, talk to them about it.
I've got project one which insisted - the point of blocking PRs - that "Yoda style" for null checks was mandatory. Guess what? Another project I'm on, Yoda-style is prohibited, because "it's confusing". Every keystroke I'm having to wonder/worry about what context am I in, and always battling stupid red squiggles.
That sort of insignificant minutiae really irritates me. It shouldn't matter at all, yet some people love to make mountains out of molehills. (I personally use the "if(ptr)" style because it's the simplest, but I wouldn't care if my coworkers used "if(NULL != ptr)", "if(ptr != NULL)", "if(ptr != 0)", or "if(0 != ptr)"; they're all equivalent, and anyone who doesn't know that, doesn't know the language. "if((NULL != ptr ) == true)" will cause me to raise a comment, however, although not a blocking one.)
"It means we don't have to argue about style"
Well... for the most part, I wasn't arguing about your style in the first place. You're trying to get stuff done your way under the guise of "let's all stop fighting and just get along". I didn't start the fight.
"It makes things easier to read"
If it's harder for me (and some others) to write it that way, it's because it's not natural/default, and, actually, it might actually be harder for me (and some others) to read as well.
I routinely work with folks who like to 'omit' 'unnecessary' lines - omitting a curly brace block in a one-line if is a regular example.
if (foo) {
bar
}
if (foo) bar
if (foo)
bar
Hyper-concern of linting is in my top 10 red flags of an engineer that is likely unable to prioritize without significant and continuous direction from a PM. It definitely does not mean that are not a skilled developer. Often it does indicate they are quite good. But it also indicates they can not be left alone too long without supervision.
Had a Java PR blocked because I'd used "Integer" instead of "int" and "the compiler's going to have to do more work autoboxing".
There was some other feedback on the diffs too. While technically 'correct', the use case for the code is a 10-15 second process that is run around 200 times per week for one specific client on one server (not clustered, just housing that client and maybe a dozen others). This Integer is housing a sequence counter that may go up to 10 in some cases so... we may be saving a fraction of a second 200 times per week, based on this PR change.
MEANWHILE... the 'in house' team - who reviews themselves - somehow manages to push code in to the main develop branch which, once it's pulled down, results in a system where the initial "dashboard" screen is literally broken after login. That will get pushed to the 'testing' server where 15-20 people do routine 'testing' for various client work, meaning... one bad push puts 30+ people out of commission for hours. This has happened 5 times I'm aware of this year.
But... int/Integer merits holding up a PR.
See its the opposite for me. If I cant trust you with something as dead simple as "npm run lint:fix", how can I trust you to respect any of our more important policies? It's completely disrespectful to the whole team.
That’s not really that beneficial, and I can understand why you may dislike this sort of thing.
I think the real benefits come when... - you can enforce a very consistent style, more than a typical linter - you start adding custom linters for things that matter in your codebase
The second point here I’ve used to help move Python 2 to Python 3, move from one library to another by showing linter warnings for importing the old one, enforce new call patterns that might be tricky to enforce in code (like always calling function A before B). It’s less about “linting” and more about flexible static analysis and warnings, and while there will always be other ways to implement those it’s another tool that can be useful to have in your team’s toolbox.
Because some things are better expressed in different rules.
That's why some syntax is optional in the first place, that's the reason it was made that way. The flexibility is a very intentional feature. It wasn't an accident.
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.
Not following optional syntax like having a space after a comma or a space before a parenthesis is not a software bug. It's a waste of time. The compiler doesn't care and I don't either.
Instead it becomes a literal Blocking Issue most of the time. So instead of working on the actual blocking issues of the code base, you spend time doing "you did this here because of some context I don't understand and I'm not allowing it" You can't commit your code without conforming to it.
Also because linters are dumb. They "spot" things that are perfectly fine as supposed bugs (because they don't actually know types or logic, they're just dumb syntax checkers) and you have to work around them to satiate them with the possibility of introducing new bugs to prevent some tripwire system from false positives.
Compiler writers and language designers are the only people I've found who agree with me.
It's fine for protecting against profound levels of incompetence but I don't do that and you probably don't either.
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'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
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.
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.
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
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.
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.
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.
> 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
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".
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.
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...
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.
many things "highlighted as you type" aren't "bugs".
let greeting = "Hello " + user.name;
but... I might be making a change to it a few minutes later... but I've got some damn visual shit flashing in my eyes that "USE A CONST"
concat strings? PREFER TEMPLATE!!!
OK, ESlint, have it your way, please auto-correct that...
`Hello ${ user.name}`;
And... this is just one set of 'best practices' to learn - change per language/framework/team multiple times (sometimes in the same week) and it's... difficult.
Yes, I'm an old-fogey. I have close to 30 years of muscle memory of using string concat and double quotes. "auto-fixing as I type" brings a huge interruption of flow, and THESE ARE NOT BUGS. They are style choices someone else is imposing on me. It doesn't make the code less buggy. It doesn't make the client any happier. If someone else coming in to the code is genuinely confused, confounded or severely impeded by
let greeting = "Hello " + user.name;
Goodness help folks when new management comes in and demands a new 'better' style.
Again, an issue with switching between projects/styles, for me - one client/project insists on "const" in JS. Another client/project is supporting a product on IE9 for a client of theirs, but doesn't use any build tool for some of that JS, so we're not even supposed to use "let" or anything else "new" for some of that project. Mentally switching between those two worlds is like jumping between 2019 and 2009 every few days.
Realistically, could we introduce a transpiler? Technically yes, but operationally? It's a Frankenstein project that has so many larger issues that's low on the list for people (sections of the functionality are being migrated over to react altogether, and throwing 'more tools' in to the mix on legacy stuff is not desired).
I'd always argue for using it that way, which is very reasonable to me.
(A bit weird to have 30 years of muscle memory writing `let`, btw :) )
They use the excuse of the linter sometimes highlighting potential bugs to impose their preferred formatting style wholesale over everyone. And it's purely an exercise of power of one person over others -- the computer doesn't care about your style.
And it's not enough, some people will ask you to move sections of code around and start arguing about naming once they have no inconsistent white spaces to complain about -- that's how you know it's not the linter or formatter that they want, they want to control people.
Bad linters are expensive. They add complexity to workflows and pipelines, slow down iteration speed, and create a nitpicky culture where most discussions miss the point. Multiply this by a whole engineering team, yikes.
Yet there are some good (parts of) linters, such as catching actual issues rather than preferences. If we bet on linters, they should increase our value multifold to be worth it.
You're right, I much prefer de-linting, but to each their own.
(it's probably just an artifact of ancient unix history that these tools are called "linters" instead of "delinters", because they preferred vry shrt nms bck thn)
Care to explain why you dislike it?