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

151–160 of 360 posts

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

#151

Post by jakear »

kristopolous wrote: post #143
Vinnl wrote: post #138

Earlier quoted context omitted.

So are you saying sometimes you want to initialise a variable without ever doing anything with it afterwards? That that's not the result of a typo down in your code in the vast majority of cases? I mean, I'll be the first to agree that blocking your development in the heat of it over some stylistic issue like quote styles is counter-productive, but if those rules are turned off and the rest help you catch actual bugs…

It hasn't been my experience. I have had to deal with linters probably about 15,000 or so hours of my work life (luckily that's only about a third). It's been probably between 99.4% and 99.8% just acrobatic dog tricks to satisfy the linter. It's not like I'm some grumpy malcontent that hasn't given it a go. If you want to use it go ahead, I just thought I'd be standing in a larger crowd

Not sure what these “dog tricks” you speak of are. Have the linters you’ve worked with had ”—fix” options such that you don’t need to do anything besides save the file?

Aside, it’s funny that you dismiss linters as being for “type A folks who must have everything in its right place”, but your concerns seem to be that you want things in their right place and the linters won’t let you. The folks who use linters have decided worrying about it isn’t worth it and just let the linter do its thing, which is less “Type A” than how you describe yourself.

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

#152

Post by microcolonel »

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 think some mix should be reached with auto formatting. I like the automatic indentation I get in Emacs with clojure-mode, but for everything else, manual formatting is just better.

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

#153

Post by kristopolous »

jakear wrote: post #151
kristopolous wrote: post #143

Earlier quoted context omitted.

It hasn't been my experience. I have had to deal with linters probably about 15,000 or so hours of my work life (luckily that's only about a third). It's been probably between 99.4% and 99.8% just acrobatic dog tricks to satisfy the linter. It's not like I'm some grumpy malcontent that hasn't given it a go. If you want to use it go ahead, I just thought I'd be standing in a larger crowd

Not sure what these “dog tricks” you speak of are. Have the linters you’ve worked with had ”—fix” options such that you don’t need to do anything besides save the file? Aside, it’s funny that you dismiss linters as being for “type A folks who must have everything in its right place”, but your concerns seem to be that you want things in their right place and the linters won’t let you. The folks who use linters have de…

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.

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

#154

Post by dtech »

kevin_thibedeau wrote: post #94
michaelmior wrote: post #92

Earlier quoted context omitted.

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.

Usually when introducing such a tool you do 1 commit that reformat the whole codebase to the new style and then automatically enforce it.

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

#155

Post by mintplant »

philwelch wrote: post #98
minimaxir wrote: post #82

Earlier quoted context omitted.

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.

I maintain Lavender as a Black alternative with single-quote support.

https://github.com/spinda/lavender

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

#156

Post by i_dursun »

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 ?

I believe unison does something along those lines:

https://www.unisonweb.org/

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

#157

Post by u801e »

nxrabl wrote: post #116
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…

Append “?w=1” to the end of a Github PR URL, it’s like passing “-w” to git. (Not that that addresses all of your comment, I just wanted to share the tip. Agreed that smarter diffing would be really nice.)

git diff has a --diff-algorithm parameter that has several options to choose from. I don't know whether Github supports that via url parameters though.

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

#158

Post by minimaxir »

philwelch wrote: post #98
minimaxir wrote: post #82

Earlier quoted context omitted.

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.

That, I've gotten surprisingly used to. (atleast Black is smart about using single-quotes instead if you use double-quotes in a string)

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

#159

Post by jakear »

kristopolous wrote: post #153
jakear wrote: post #151

Earlier quoted context omitted.

Not sure what these “dog tricks” you speak of are. Have the linters you’ve worked with had ”—fix” options such that you don’t need to do anything besides save the file? Aside, it’s funny that you dismiss linters as being for “type A folks who must have everything in its right place”, but your concerns seem to be that you want things in their right place and the linters won’t let you. The folks who use linters have de…

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

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

#160

Post by stu2b50 »

softwaredoug wrote: post #140
lixtra wrote: post #86

Earlier quoted context omitted.

It’s MIT License. You’re free to fork.

Yeah but only MS/GH have the resources to maintain a viable project here. Little old you and me aren’t really going to reasonably fork something and have the time to maintain it.

Hm, I wouldn't say so for the superlinter specifically. If you actually look at the source, it doesn't seem particularly hard to maintain.
Post reply on HN