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

161–170 of 360 posts

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

#161

Post by kristopolous »

jakear wrote: post #159
kristopolous wrote: post #153

Earlier quoted context omitted.

That wasn't me. It's a nice visual but I think it's mostly for fun. 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.

Oh, misread authors I guess. 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

we probably just code different things for a living. It's a big world. I'm sure they're useful in your job.

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

#162

Post by The_rationalist »

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?

We use klint at work (Kotlin) https://github.com/pinterest/ktlint It's take inspiration from standardjs and gofmt

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

#163

Post by KindOne »

perryizgr8 wrote: post #97
corndoge wrote: post #29

No C/C++ support?

You don't have linters for C/C++ as far as I know. I guess they could have included code-formatters too, like clang-format.

What about clang-tidy?

http://clang.llvm.org/extra/clang-tidy/

cpplint?

https://github.com/cpplint/cpplint

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

#165

Post by thefunnyman »

ascorbic wrote: post #67
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.

As others have stated, prettier is a formatted not a linter. I do however agree that Standard is a weird choice and in my experience is far from an actual “standard”. IMO the Airbnb style is excellent and would have been a better choice here. It’s also available as an ESlint plugin. Hopefully something like this can be configured on the GH Action in the future, allowing for a choice between available presets.

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

#166

Post by _bohm »

wenc wrote: post #111
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 started programming in the 80s, so I'm used to double-quoting anyway. Apostrophes occur so often in English that it makes it easier to type strings like "I'm a dog". With single quoting you have to go 'I\'m a dog'. If I hit double quotes in a string, I just triple-quote. """He said "hah" sarcastically""". I know Guido (van Rossum) prefers single quotes -- I'm not sure why exactly -- so it's become a default Python…

I use single quotes simply because I'm lazy and tapping the quote key with my pinky is marginally easier than shift-quote :p

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

#167

Post by tlrobinson »

philsnow wrote: post #110
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…

Code autoformatting is amazing and I never want to go back; even though I strenuously disagree with the particular formatting my team/company has chosen for python, I'm so relieved to never ever have a style discussion in PRs that I don't care about double quotes vs single quotes anymore. BUT I'm tired of seeing diff chunks on github where 95% of the chunk is because black/gofmt decided to change the formatting / ind…

This is basically solved by pinning the formatter to a specific version in your project's dependencies, and enforcing its use in continuous integration.

Of course that doesn't help if you're setting up the formatter for the first time, or want to upgrade to a new version.

Some tools like GitHub's diff do try to deemphasize whitespace but it's pretty limited.

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

#168

Post by usr1106 »

perryizgr8 wrote: post #97
corndoge wrote: post #29

No C/C++ support?

You don't have linters for C/C++ as far as I know. I guess they could have included code-formatters too, like clang-format.

I learned C 1986 and lint existed back then. According to Wikipedia it's from 1978.

Of course C was a different languange back then. But I am rather sure modern variants exist.

Clang-tidy comes to my mind, but I don't write any significant amount of C/C++ these days.

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

#169

Post by tlrobinson »

kristo wrote: post #134
philsnow wrote: post #110

Earlier quoted context omitted.

Code autoformatting is amazing and I never want to go back; even though I strenuously disagree with the particular formatting my team/company has chosen for python, I'm so relieved to never ever have a style discussion in PRs that I don't care about double quotes vs single quotes anymore. BUT I'm tired of seeing diff chunks on github where 95% of the chunk is because black/gofmt decided to change the formatting / ind…

Why don’t we just check ASTs in to git instead of text files ?

There are some cases where formatters like Prettier don't have one canonical representation for an AST, in particular behavior around line breaks (multiple empty lines are allowed, a line break after an "{" opening brace in an object literal will force it to span multiple lines, etc)

But yeah, otherwise everyone could just have their own preferred formatter/settings and we could commit whatever representation is most optimal for diffing to version control (e.x. multi-line object literals, trailing commas in arrays/args, etc).

You could use something more compact like a binary AST but for compatibility with "legacy" tools that deal with text I think it would be better to use a more verbose text-based representation.

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

#170

Post by danpalmer »

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 think many people install the default linter for their ecosystem, get satisfaction from a bunch of essentially busy work getting some green check marks or removing warnings, and believe their code is better.

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.

Post reply on HN