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

91–100 of 360 posts

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

#91

Post by closed »

6gvONxR4sf7o wrote: post #42
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…

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 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 characters to this one line list statement, it will get exploded across 5 lines", and affect readability, etc..)

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

#92

Post by michaelmior »

kevin_thibedeau wrote: post #78
asutekku wrote: post #73

Earlier quoted context omitted.

Can’t you just set up a linter/formatter to your style, apply it to your style when editing and on save set it to the project style?

It fucks up the diffs in the codebase.

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.

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

#93

Post by Guillaume86 »

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?

I wish there was good C# one (and ideally a standard one like go). When switching between typescript with prettier and C# the first thing I notice is the lack of autoformating.

edit: seems https://github.com/dotnet/format is the closest thing

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

#94

Post by kevin_thibedeau »

michaelmior wrote: post #92
kevin_thibedeau wrote: post #78

Earlier quoted context omitted.

It fucks up the diffs in the codebase.

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.

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

#95

Post by diarrhea »

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.

This weirded me out, but the Dockerfile [0] reveals how this just pulls together a bunch of linters. A nice convenience to have taken care of, but nothing groundbreaking or closed-off. I guess this still counts as an "Extend" step, though.

[0]: https://github.com/github/super-linter/blob/master/Dockerfil...

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

#98

Post by philwelch »

minimaxir wrote: post #82
wenc wrote: post #72

Earlier quoted context omitted.

Another recommendation for Black. I use 'black -l 120' because the default PEP recommended 80 chars per line is too restrictive.

Black uses a 88 char per line limit. In the course of normal Python coding I rarely hit it. For public code I do not recommend changing the defaults since it may make PRs a mess.

The 88 character limit is just a best effort thing anyway. I find the double-quote coercion more disruptive.

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

#99

Post by ianleeclark »

honkycat wrote: post #87
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…

One of the hills I am willing to die on is auto-formatting. Code formatting is easily automated to an acceptable level, and people's personal preferences are subjective. I like to solve interesting problems, and concentrate on crafting high quality software. Manual code formatting contributes to neither of these disciplines. Code formatting is BORING robot work, not human work. Total pointless drudgery. Toiling away…

I agree with this wholeheartedly. Being introduced to gofmt a few years categorically eliminated a certain class of PR comments allowing PRs to be more focused on actual implications and logic.

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

#100

Post by jameslk »

throwaway43234 wrote: post #58
jameslk wrote: post #48

One step closer to Linting as a Service. That'll be next, along with Compilation/Build Systems as a Service. Or more likely part of the whole IDE moving to the cloud. The pain being solved here is that setting up the right development environment is hard, especially for those still learning to program. Many would be much more productive if we skip this step. Another prediction: Once the development environment moves…

GitHub Codespaces was announced at Satellite and it's basically what you say - a way for developers to skip the "setting up" step (often the most annoying step and single biggest blocker for OSS contributions) in a new repo. https://github.com/features/codespaces Disclaimer, I helped make these :)

Interesting. Yes this is definitely in the direction I was thinking. I'd also say Repl.it is very similar too. Maybe they'll be acquired.
Post reply on HN