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

61–70 of 360 posts

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

#61

Post by protonimitate »

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…

Yup, we recently implemented auto linting/formatting using pre-commit hooks and it's made a huge difference in maintainability and readability.

I don't care about the specific formatting/linting rules as much as I care about consistency. Auto formatting is great to reduce friction for those on the team who can't/won't convert change how they write code locally.

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

#62

Post by ithrow »

rdsubhas wrote: post #50

What's very interesting in the list here: https://github.com/github/super-linter/#supported-linters Java is the only major language without any sane default coding standard (no, google-java-format is google-specific, outdated, not up-to-date with recent versions and not maintained by community). It's a pity really.

Java is going downhill(as in not much new code is being written in it), so of the mainstream languages is going to get supported last if ever.

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

#63

Post by BiteCode_dev »

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…

> This is why we allow users to use any rules for the linter as they see fit for their repository.

So not like prettier/black/goftm.

You get to choose. It's more of a way to group things.

Which make sense. I don't mind being dictated code formatting, but linters will complain about branching, number of arguments, comments and so on. I change the settings of my linter for each project.

Those should not be fixed.

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

#64

Post by BiteCode_dev »

oefrha wrote: post #13

A problem I can see with this super linter is that it seems be written exclusively for GitHub Actions; there's no local install option. (I didn't read the code, maybe you can use lib/linter.sh directly, but it's certainly not directly supported.) So contributors have to rely on the CI feedback loop to see if their changes are compliant (insert fencing comic here)... Or more realistically, still use whatever linters t…

To be honest, if you code professionally, you probably have all those linters installed already (probably directly in you IDE). The value is to have them in the github actions.

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

#65

Post by SPBS »

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 like formatters like Prettier and gofmt as well, but not StandardJS. I'd still use it if everyone used it though. I just don't like their stance of relying on automatic semicolon insertion, even if Go does the same thing

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

#66

Post by fizixer »

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…

That's exactly the right way to do it and I've been advocating for this, as well as maximum use of parsing/tranformation/codegen technology (essentially compiler tech) for development productivity, long before LSP was a thing.

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

#67

Post by ascorbic »

rdsubhas wrote: post #50

What's very interesting in the list here: https://github.com/github/super-linter/#supported-linters Java is the only major language without any sane default coding standard (no, google-java-format is google-specific, outdated, not up-to-date with recent versions and not maintained by community). It's a pity really.

I wonder why they went with Standard for JavaScript and TypeScript, instead of Prettier which is far more popular now.

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

#68

Post by ambicapter »

michaelmior wrote: post #49
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 agree with sentiment but I don't think it's entirely true that it only affects reading code. When it comes to modifying existing code, I have to deal with whatever format the existing code was written in. For example, personally I hate working with code with tabs so I would find this frustrating. (As an aside, I'll admit this is really my problem and a rather silly one.) Of course one solution is to transform code…

> When it comes to modifying existing code

You don't have to deal with anything as long as you're using the same formatter everyone else is using.

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

#69

Post by michaelmior »

ambicapter wrote: post #68
michaelmior wrote: post #49

Earlier quoted context omitted.

I agree with sentiment but I don't think it's entirely true that it only affects reading code. When it comes to modifying existing code, I have to deal with whatever format the existing code was written in. For example, personally I hate working with code with tabs so I would find this frustrating. (As an aside, I'll admit this is really my problem and a rather silly one.) Of course one solution is to transform code…

> When it comes to modifying existing code You don't have to deal with anything as long as you're using the same formatter everyone else is using.

My point was that when writing new code, I can write it in whatever format I want knowing that it's going to be formatted the canonical way. But when modifying code, I have to work with code in one specific format that may not be my preferred format.

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

#70

Post by kevinastone »

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?

The previously mentioned prettier[0] along with swift-format[1] and rustfmt[2].

[0]: https://prettier.io [1]: https://github.com/apple/swift-format [2]: https://github.com/rust-lang/rustfmt

Post reply on HN