Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Super Linter: one linter to rule them all

github.blog

Post reply on HN
Print view View original

321–330 of 360 posts

Re: GitHub Super Linter: one linter to rule them all

#321

Post by lowercased »

Izkata wrote: post #294
lowercased wrote: post #193

Earlier quoted context omitted.

> What do you dislike about bugs being highlighted as you type many things "highlighted as you type" aren't "bugs". let greeting = "Hello " + user.name; Auto-fixing immediately flags this with "DAMN YOU USE A CONST!!!!" (multiple red squiggles that I have to hover and review). 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" conca…

The funniest part about that particular example is that it's highly likely you're using babel to support old browsers, and the compiled version just switches it back to string concatenation.

In the example above, I believe that's the case.

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).

Re: GitHub Super Linter: one linter to rule them all

#322

Post by davedx »

xondono wrote: post #317
ergothus wrote: post #270

Earlier quoted context omitted.

> Consistent style is more important than each block of code being perfectly pretty "Pretty", yes, but we're literally talking about using language to communicate. Consistency taken to extremes is harmful to communication. I don't understand the worship that people have for consistency. STUPID inconsistencies are bad, yes, and yes, there are certainly arguments that about subjective matters that are a waste of time.…

I’d agree that 100% consistency is harmful to communication, but the primary communication happening in programming is with a computer. Even when it comes to other developers looking at your code, their internal process is “let me simulate what the computer understands”. Unless you are enforcing weird autoformat choices, everything should look pretty enough.

> the primary communication happening in programming is with a computer

Working in a team with 15 people on the same code base I disagree with this. Count the computer as one teammate

Re: GitHub Super Linter: one linter to rule them all

#323

Post by lowercased »

userbinator wrote: post #265
musingsole wrote: post #186

Earlier quoted context omitted.

> It does mean that some people who place a high value on standards and listing and visual style are placated. 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…

I think it's mainly the difference between result- and process-oriented personalities, with the latter being advocates of linting and other "formalities", and the former opposing it. 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 mi…

The justifications I've had over the years:

"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
    }
ends up as

    if (foo) bar
or

    if (foo)
      bar
Honestly I can't remember which. Had 'feedback' from people removing my braces saying "these are unnecessary". But now there's two styles I have to be able to read/write, and... there's almost never a time when one line without braces is sufficient forever - whenever I need logging or another piece of code in the block - bam - now I have to add braces, and that whole area of the code looks more 'different' than it used to.

Re: GitHub Super Linter: one linter to rule them all

#324

Post by lowercased »

dodobirdlord wrote: post #296
musingsole wrote: post #186

Earlier quoted context omitted.

> It does mean that some people who place a high value on standards and listing and visual style are placated. 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…

Honestly, I cannot imagine a larger waste of my time than a colleague critiquing code format in a code review. And of the colleague's time. For this complaint of no value whatsoever, they have stalled the merge by whatever the average latency of their code review is. At the very least I have to wait for them to look at it again to see my response that I will not accept the style suggestion.

I'm working with a consulting team of around 8 that was brought in to augment an enterprise team.

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.

Re: GitHub Super Linter: one linter to rule them all

#325

Post by Can_Not »

musingsole wrote: post #186
lowercased wrote: post #182

Earlier quoted context omitted.

You're not the only one. 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 c…

> It does mean that some people who place a high value on standards and listing and visual style are placated. 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…

> But I'm still going to remember the lint-advocate as a developer too concerned with the wrong things.

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.

Re: GitHub Super Linter: one linter to rule them all

#326

Post by Insanity »

tlrobinson wrote: post #37

Great! Now do it for code formatters! After using Prettier for a few years I'm firmly in the camp of mandatory/enforced code formatters. As long as it's a half decent formatter like Prettier I believe my personal opinions on the specific formatting choices are much less important than essentially never having to think about formatting again, in particular having to ask people to fix formatting in code reviews (or fix…

Exactly what I love about Go and Gofmt.

Re: GitHub Super Linter: one linter to rule them all

#327

Post by forty »

VectorLock wrote: post #196
honkycat wrote: post #87

Earlier quoted context omitted.

One of the hills I am willing to die on is auto-formatting. Code formatting is easily automated to an acceptable level, and people's personal preferences are subjective. I like to solve interesting problems, and concentrate on crafting high quality software. Manual code formatting contributes to neither of these disciplines. Code formatting is BORING robot work, not human work. Total pointless drudgery. Toiling away…

Normally I agree with treating code as a means to an end rather than an end to itself but I take a certain enjoyment in crafting in some way aesthetically pleasing code as well. I even find that if the code is "ugly" that there frequently might be a more eloquent and objectively better way of doing things. And a little time hand formatting I think is worth it if you're maximizing understandability and readability. No…

There are two kind of painting. You can paint a wall/a building, or you can paint Mona Lisa.

This is the same for programming. Each dev have their own taste in term of code style and code formatting preferences. I was an early employee in a startup, and at some point I was able to tell who wrote a chunk of code just from the code style, it was fun :) but as company grown, and team got bigger, it got more "professional", now we have prettier which erases a big part of our code personality. If you believe like me that coders are artists you might find that a bit sad, but the truth is that most Enterprise software building is wall painting, and art doesn't have its place there. That doesn't prevent us from painting Mona Lisa at home though :)

Re: GitHub Super Linter: one linter to rule them all

#328

Post by MoroCode »

honkycat wrote: post #87
tlrobinson wrote: post #37

Great! Now do it for code formatters! After using Prettier for a few years I'm firmly in the camp of mandatory/enforced code formatters. As long as it's a half decent formatter like Prettier I believe my personal opinions on the specific formatting choices are much less important than essentially never having to think about formatting again, in particular having to ask people to fix formatting in code reviews (or fix…

One of the hills I am willing to die on is auto-formatting. Code formatting is easily automated to an acceptable level, and people's personal preferences are subjective. I like to solve interesting problems, and concentrate on crafting high quality software. Manual code formatting contributes to neither of these disciplines. Code formatting is BORING robot work, not human work. Total pointless drudgery. Toiling away…

Personally I vote to let people write code in the format they are most comfortable with and run the formatter as part of CI

Re: GitHub Super Linter: one linter to rule them all

#329

Post by chrisweekly »

antigirl wrote: post #292
chrisweekly wrote: post #102

Earlier quoted context omitted.

Agreed. I adopted the Wes Bos approach (drive Prettier from ESLint) and it's fantastic.

Any links? I only use it for react. I found eslint auto fix works well enough for node etc

https://github.com/wesbos/eslint-config-wesbos

Re: GitHub Super Linter: one linter to rule them all

#330

Post by jmchuster »

softwaredoug wrote: post #207
jmchuster wrote: post #188

Earlier quoted context omitted.

I guess you've never worked in a .NET shop before? Or the days when everyone just developed on Visual Studio on Windows, before Macbooks for developers was a thing?

Yes I’ve worked in MS shops, even written Win32 code. I learned a monolithic dev ecosystem was what I personally did not want. So that pendulum swung more towards OSS...

I think most developers would agree that "open source has won". I feel the aspect of it that you're focusing on here is the ability to choose the best-in-breed tools, and to be able to swap each one out individually as better options arrive. If Microsoft's approach with its open source tooling is to follow that mindset, I'm not concerned. If it isn't, then eventually people will either move on to other tooling or fork it.

Now, if we're saying that Microsoft should be spending more of their time on interop and portability but chooses not to prioritize their resources on that, then that just falls into the category of common complaints that people have with all open-source projects and what the contributors choose to spend their valuable developer hours on.

Post reply on HN