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

231–240 of 360 posts

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

#231

Post by peterstensmyr »

kevin_thibedeau wrote: post #94
michaelmior wrote: post #92

Earlier quoted context omitted.

How so? If the canonical format is applied every time you save, you'll always be doing a diff with files using the same format. Of course, it does mean the code in the diffs may not be in your preferred format.

If you want to diff against anything in the past you get a bunch of formatting noise that occludes real changes.

Git has an option to ignore certain commits when doing a git blame, —ignore-revs. You can also point it to a file with —ignore-revs-file . You can configure this per project with git config ignoreRevsFile .git-blame-ignore-revs. After doing this, you get nice diffs AND nice looking code. The price to pay is that every developer has to run one git command locally.

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

#232

Post by reledi »

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.

Definitely. Side projects, fine. But I'll never use a pipeline that's coupled to my VCS hosting solution for anything production facing. Did it before and not only does it make it tricky to move to another VCS host, but your ability to release is held hostage by their uptime - which isn't super reliable.

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

#233

Post by mbar84 »

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…

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

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

#234

Post by derwiki »

karanrajpal wrote: post #229

Argh I just worked on exactly this idea, as a tool for my company! What do people do when they see an idea they had/care about being implemented by someone else?

This is the nature of invention -- the current climate gives multiple people the same good idea around the same time. You could abandon and join, convince the other project to do the same, keep working on yours, stop working on yours and use theirs... depends on your goals.

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

#235

Post by waheoo »

a_t48 wrote: post #208
VectorLock wrote: post #196

Earlier quoted context omitted.

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…

Consistent style is more important than each block of code being perfectly pretty. You can still argue aesthetics, but they need to be applied across the entire codebase. Never having to bother someone because their PR doesn't meet the formatting guidelines is well worth it.

People at work nit: my code all the time. I just straight up ignore them. If they ask me why, I tell them to add an autoformat to our ci or shut the hell up.

Fwiw, i use an auto formatter but its got problems with certain rules so i switch them off.

The reason we dont have it turned on in ci is because these rules break code.

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

#236

Post by sailingparrot »

softwaredoug wrote: post #227
sailingparrot wrote: post #216

Earlier quoted context omitted.

Serious question: what should a company like MS do in that position ? I think this is a nice feature and it's useful, it's also open source and MIT licenced, so in other word, it's an open as it can get. Is there anyway for MS to not making you uncomfortable apart from just not adding any new feature ?

I mean I would do the exact same thing. Consolidate dev mindshare around the organization. That doesn’t mean I have to like it!

Indeed and I wasn't criticizing you, this was a legit question: Is there a way in that situation to continue improving while not creeping out users. I guess the answer is to do it for long enough without screwing your users like MS did in the past.

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

#237

Post by koreth1 »

philwelch wrote: post #56
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 can wholeheartedly recommend Black for Python, gofmt for Go, and terraform fmt for Terraform. What are some other great formatters out there?

Google-java-format for Java and ktfmt for Kotlin.

https://github.com/google/google-java-format

https://github.com/facebookincubator/ktfmt

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

#238

Post by reledi »

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.

I used to be bullish on linting around 2014-2017. Now I avoid them as much as possible.

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.

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

#240

Post by nemetroid »

LibertyBeta wrote: post #4

So, this looks interesting. Rather than a real new linter, Github is proposing a tool that runs against a number of common linting standards with a single shared standard library. Perhaps it would have been better pitched a Lint-runner for CI jobs rather than a real linter.

Agreed. The headline and article had me believe that this was some language-agnostic linter framework. Which I guess it is in a sense, but it's only the dispatching part that's language-agnostic.
Post reply on HN