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

141–150 of 360 posts

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

#141

Post by jakeogh »

hobofan wrote: post #44
oefrha wrote: post #34

Earlier quoted context omitted.

Outdated version could simply be counted as nonexistent, then a new version would be installed "as needed".

And then you'd need to figure out how to install that new version side-by-side with the existing one, or otherwise you will upgrade and break the existing setup of a lot of people. That is also not always trivial, especially if you have an existing setup like e.g. system python + pyenv managed python. Should the linters then be installed via the system package manager? How would you handle that across many different…

Portage solved all that long ago. Parallel versions are called slots.

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

#142

Post by majewsky »

bluedevil2k wrote: post #89
ithrow wrote: post #62

Earlier quoted context omitted.

Java is going downhill(as in not much new code is being written in it), so of the mainstream languages is going to get supported last if ever.

This is an inane comment, there's TONS of new code being written in it, probably more than any other language. Outside the HN bubble of Rust/Draco/OCaml companies tend to stick with the Java/JS/Ruby/C# languages.

> there's TONS of new code being written in [Java], probably more than any other language

Nah, it's a pretty safe bet that the language with the most new code being written is JavaScript. If it weren't JavaScript, I'd actually guess Excel next. (Okay, maybe not in terms of LOC, but certainly in number of applications.)

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

#143

Post by kristopolous »

Vinnl wrote: post #138
kristopolous wrote: post #125

Earlier quoted context omitted.

This is just me btw, don't take offense: Because some things are better expressed in different rules. That's why some syntax is optional in the first place, that's the reason it was made that way. The flexibility is a very intentional feature. It wasn't an accident. Maybe you want multiple spaces to vertically align code in a complex set of logic. Maybe you want to express things on multiple lines to break them up. M…

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

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

#144

Post by BurningFrog »

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 definitely format code better than Black does. But that's probably not true for the average programmer. I do appreciate it formatting big dicts for me.

If you find formatting discussions with your teammates painful, Maybe some fraction of your team are stubborn jerks?

I've worked where formatting discussions were always friendly and constructive. It can be done.

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

#145

Post by krzyk »

majewsky wrote: post #142
bluedevil2k wrote: post #89

Earlier quoted context omitted.

This is an inane comment, there's TONS of new code being written in it, probably more than any other language. Outside the HN bubble of Rust/Draco/OCaml companies tend to stick with the Java/JS/Ruby/C# languages.

> there's TONS of new code being written in [Java], probably more than any other language Nah, it's a pretty safe bet that the language with the most new code being written is JavaScript. If it weren't JavaScript, I'd actually guess Excel next. (Okay, maybe not in terms of LOC, but certainly in number of applications.)

Java and Javascript are head to head on that one, if you look at any data on the web. (and Java is nice to work with, mature environment, quite opposite of Javscript).

With Python or C++ being next.

But they don't count Excel :)

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

#146

Post by nilkn »

BurningFrog wrote: post #144
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 definitely format code better than Black does. But that's probably not true for the average programmer. I do appreciate it formatting big dicts for me. If you find formatting discussions with your teammates painful, Maybe some fraction of your team are stubborn jerks? I've worked where formatting discussions were always friendly and constructive. It can be done.

My experience with black is that it’s good enough for Python that it’s a waste of time to not use it. Sure, on many teams formatting discussions are friendly. But why even spend the time?

It also really democratizes the language, because even folks brand new to Python or who are inexperienced with programming in general end up with code that is well-formatted and consistent with everything else.

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

#147

Post by BurningFrog »

nilkn wrote: post #146
BurningFrog wrote: post #144

Earlier quoted context omitted.

I can definitely format code better than Black does. But that's probably not true for the average programmer. I do appreciate it formatting big dicts for me. If you find formatting discussions with your teammates painful, Maybe some fraction of your team are stubborn jerks? I've worked where formatting discussions were always friendly and constructive. It can be done.

My experience with black is that it’s good enough for Python that it’s a waste of time to not use it. Sure, on many teams formatting discussions are friendly. But why even spend the time? It also really democratizes the language, because even folks brand new to Python or who are inexperienced with programming in general end up with code that is well-formatted and consistent with everything else.

To me, because readability is the most important aspect of programming, and it needs to be done right.

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

#148

Post by ssivark »

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 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 after the language parser processes on the text file, and then be able to interface with the AST generated by the parser (for multiple languages). I presume this would become easy if different languages have the same parsing setup, or we have language/project-specific VCS tools. While the answers are not obvious (to me, at least) this definitely seems like the right direction to move in, instead of getting hung up on plain text and formatting issues.

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

#149

Post by nilkn »

BurningFrog wrote: post #147
nilkn wrote: post #146

Earlier quoted context omitted.

My experience with black is that it’s good enough for Python that it’s a waste of time to not use it. Sure, on many teams formatting discussions are friendly. But why even spend the time? It also really democratizes the language, because even folks brand new to Python or who are inexperienced with programming in general end up with code that is well-formatted and consistent with everything else.

To me, because readability is the most important aspect of programming, and it needs to be done right.

But what do you get in that regard by not using black? Maybe in 1% of cases you’ll find a better way of formatting that everyone will also agree is better. That doesn’t seem worth very much at all to me, especially when by not using it you have to do a lot of manual work across the entire team now to get the 99% that is free with black.

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

#150

Post by vorticalbox »

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…

Out front end team use prettier on back team we use eslint and air bnb style.

But totally agree on forced lining.

Stopping things like reassign function parameters, no unused variables and the like really makes code far nicer.

I also love auto formatting in vscode saves a lot of time.

Post reply on HN