Live data from Hacker News

GitHub Super Linter: one linter to rule them all

github.blog

221–230 of 360 posts

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

#221

Earlier quoted context omitted.

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

Prettier is a formatter, not a linter.

Standard isn't a linter either. My question was why they're using the Standard style, rather than the Prettier style, both of which can be validated with eslint.

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

#222

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?

mix format for Elixir

rubyfmt for Ruby

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

#223
post #81

What I'm missing is a really good linter and auto-formatter for PostgreSQL or just standard SQL. Haven't found something that seems well established and well made.

I tried apexsql and redgate and didn't like them. I do like the built in one for datagrip, it still isn't perfect but is acceptable for me. Apexsql has a cli too I believe

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

#224

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…

It's been go-fmt that's converted me to this way of thinking. It's such a waste of time having a linter tell me after I've checked in code that I'm missing a space on line 123... please just add the space. Please let me and my colleagues never have to argue again about what is the right way to format something.

[deleted]

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

#225
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?

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

lol r u anti spellcheck 2? bcuz idk why old fogeys thnk thtz so imprtant, is juts stylistic choice, u know xactly what i'm typng rite now, if u r genuinely CONFUZED, CONFOUNDED, OR SEVERELY IMPEDED by this, prhaps ur not terribly good at reading. i cant believe thoz guyz want to interrupt my flow by mking me fix my spleling whn thz ar not even bugs, i hv close to 30 yrz of muscl memory.

I'm being facetious of course, but seriously, you are being very arrogant and rude with your suggesting that people who think stylistic standards are beneficial are bad at their jobs. Maybe they are also good at their jobs and genuinely have come to different conclusions than you and maybe despite your presumably high level of skill and experience, you're not great at developing a large team's productivity with your habits...

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

#226
post #91

Earlier quoted context omitted.

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?”

Yeah--we're basically second-order black formatters now. Not writing code that looks nice, but writing code so a tool that writes code will make it look nice.

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

#227

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.

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!

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

#228
post #134

Earlier quoted context omitted.

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

I think this is the key question, and doing this will enable numerous interface improvements for people working with software (Eg: separation of content and presents means that everybody can use their favorite view — three-space-tabs, extra-long lines, whatever). The challenge is that version control on text files (list of lines) is fairly straight forward and language agnostic, while OTOH the VCS would have to run a…

Storing an AST instead of text might be a way to eliminate parsing ambiguity of angle brackets for generic arguments (as opposed to comparisons). It might still be visually ambiguous, but I don't think it's a problem in practice (if the display forces whitespace around comparisons)?

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

#230
post #220

Earlier quoted context omitted.

Black is not free. At least not for me. I have to put in a fair amount of work to get Black to produce decent code. Things like changing names to affect line breaks, inlining or outlining expressions etc. Small things can turn 1 line into 8, and vice versa.

I’d be willing to bet that in many cases where you feel you need to fight against it, many other folks wouldn’t actually agree that your changes are objectively an improvement. Now, to be clear, I’m sure it’s possible to find some examples where most programmers would come together and agree that black made the wrong decision. But my experience using it across entire teams is that this is surprisingly rare.

You're probably right, but I'm not interested in putting it to a vote. Most programmers are pretty bad at writing readable code. If the computer can understand the code, many consider it done.

I aim higher than that.

Post reply on HN