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

181–190 of 360 posts

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

#181

Post by pmiller2 »

closed wrote: post #91
6gvONxR4sf7o wrote: post #42

Earlier quoted context omitted.

So much this. I had strong opinions on style until I found good autoformatters. Now I write horribly unformatted code and it comes out super clean and organized as soon as I hit save. Now I don’t even really care what the standard is because it only affect reading code.

I would be a bit surprised if this is true, because it implies that when you're writing code that will be formatted you do not think of the reader's experience. This could be the case if you have extreme confidence in the formatter, but I have def seen some very funky black outputs. It seems like when writing people will likely do so with a model of how black will yield the final code in mind. (Eg "if I add more char…

Rather than “writing... with a model of how black will yield the final code in mind,” it’s more like “Oh, shit, Black made a real mess of this. Can I fix this without butchering the code?”

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

#182

Post by lowercased »

kristopolous wrote: post #104

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.

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

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

#183

Post by aidenn0 »

kristopolous wrote: post #125
Vinnl wrote: post #114

Earlier quoted context omitted.

What do you dislike about bugs being highlighted as you type, rather than first having to run your code?

This is just me btw, don't take offense: 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. M…

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

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

#184

Post by leadingthenet »

mintplant wrote: post #155
philwelch wrote: post #98

Earlier quoted context omitted.

The 88 character limit is just a best effort thing anyway. I find the double-quote coercion more disruptive.

I maintain Lavender as a Black alternative with single-quote support. https://github.com/spinda/lavender

But the double quotes are exactly what I like about Black haha.

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

#185

Post by sdesol »

avtar wrote: post #33
zkoppert wrote: post #16

Earlier quoted context omitted.

Hi, there is a local run option with instructions here: https://github.com/github/super-linter/blob/master/docs/run-...

It's kind of odd that GitHub is asking people to pull an image from a Docker account that most people won't recognize (admiralawkbar/super-linter), as opposed to an official GitHub one.

GitHub's Super Linter has an unusual history. See below for example:

https://imgur.com/KZ008vu

https://imgur.com/yJSHIWS

admiralawkbar accounts for 80% of the commits in the repository and over 98% of the code churn. I'm guessing this was a side project of his (Lucas Gravley aka admiralawkbar) and the docker image was just something that was overlooked when it became an officially advertised GitHub repo.

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

#186

Post by musingsole »

lowercased wrote: post #182
kristopolous wrote: post #104

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.

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 a developer too concerned with the wrong things.

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

#187

Post by pmiller2 »

BurningFrog wrote: post #147
nilkn wrote: post #146

Earlier quoted context omitted.

My experience with black is that it’s good enough for Python that it’s a waste of time to not use it. Sure, on many teams formatting discussions are friendly. But why even spend the time? It also really democratizes the language, because even folks brand new to Python or who are inexperienced with programming in general end up with code that is well-formatted and consistent with everything else.

To me, because readability is the most important aspect of programming, and it needs to be done right.

When you use a standard formatter, people adapt. It’s as if formatting becomes a part of the language. Yes, there’s some initial pain, and, yes, some constructions become awkward occasionally, but, if you really need to, you can generally tell the formatter not to mess with a specific section.

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

#188

Post by jmchuster »

softwaredoug wrote: post #79

Is anyone else uncomfortable with Github/MS owning more and more of your tool chain? Maybe my lock-in radar is faulty, but the more this happens, the more scared I get.

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?

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

#189

Post by z3t4 »

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…

I don't like auto-formatters as they take away the personality, and sometimes even change the meaning of the code. I prefer intelligently formatted code over automatically formatted code.

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

#190

Post by lowercased »

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…

I joined a project - small startup - code in production for... 4 months at this point. 0 tests of any sort. First week, I do a small feature, add a test, and it was blocked, because I used a single letter variable name in a data setup method in a test file. "Single letter variables aren't professional". Developing and pushing code with no tests for 6+ months apparently is just fine though. I was tempted to use a four-letter variable name... They then got automated-linting fever.
Post reply on HN