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.
GitHub Super Linter: one linter to rule them all
221–230 of 360 posts
Re: GitHub Super Linter: one linter to rule them all
#222Great! 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?
rubyfmt for Ruby
Re: GitHub Super Linter: one linter to rule them all
#223What 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.
Re: GitHub Super Linter: one linter to rule them all
#224Great! 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.
Re: GitHub Super Linter: one linter to rule them all
#225Earlier 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…
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
#226Earlier 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?”
Re: GitHub Super Linter: one linter to rule them all
#227Is 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 ?
Re: GitHub Super Linter: one linter to rule them all
#228Earlier 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…
Re: GitHub Super Linter: one linter to rule them all
#229Re: GitHub Super Linter: one linter to rule them all
#230Earlier 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.
I aim higher than that.