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

261–270 of 360 posts

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

#261

Post by jlarocco »

philsnow wrote: post #241
kristo wrote: post #134

Earlier quoted context omitted.

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

I have thought about this a bit in the past, and I think the answer is that the AST for a given blob of text can be different depending on which version of the language you interpret it with. consider 'print "foo"' in python 2.7: Python 2.7.15 (default, Feb 14 2019, 16:26:56) [GCC 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.10.44.4)] on darwin Type "help", "copyright", "credits" or "license" for more information.…

I suspect you're probably right, but that example isn't the greatest because Python 3 isn't source compatible with Python 2. The source code text itself isn't even backwards compatible in that case.

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

#262

Post by longcommonname »

BiteCode_dev wrote: post #64
oefrha wrote: post #13

A problem I can see with this super linter is that it seems be written exclusively for GitHub Actions; there's no local install option. (I didn't read the code, maybe you can use lib/linter.sh directly, but it's certainly not directly supported.) So contributors have to rely on the CI feedback loop to see if their changes are compliant (insert fencing comic here)... Or more realistically, still use whatever linters t…

To be honest, if you code professionally, you probably have all those linters installed already (probably directly in you IDE). The value is to have them in the github actions.

Gcp terraform linting is sorely needed,.

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

#263

Post by est31 »

SOLAR_FIELDS wrote: post #259
waheoo wrote: post #244

Earlier quoted context omitted.

Ive seen heaps of autoformatters dirty up version control. Mostly when theyre fussing about new lines. I kind of wish autoformatters would just ignore new lines and focus on indentation alone. It would certainly cut down on the over zealous rules. I also think formatting should be separate from linting but because they both require a parser people seem to think theyre the same thing.

Wouldn't having the autoformatter run as a pre-commit hook alleviate this issue? (This is assuming you had already cleaned up all of the currently checked in code with said autoformatter)

Most autoformatters are under active development, and updates to them often causes changes in their behaviour. So you have to have all devs agree on the precise version of the formatter used, and even then you still need to do regular commits that contain nothing but a run of the newest version of the formatter on the codebase, which sadly destroys long term git blame.

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

#264

Post by Merad »

Guillaume86 wrote: post #93
philwelch wrote: post #56

Earlier quoted context omitted.

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

ReSharper's formatter is pretty good, but you do have to pay to use it in the VS IDE and it's kind of slow. The service I'm working on at present is fairly small (20k LOC) and formatting the entire solution takes about 5 minutes in the IDE or 30 minutes in CI. :/

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

#265

Post by userbinator »

musingsole wrote: post #186
lowercased wrote: post #182

Earlier quoted context omitted.

You're not the only one. As a freelance/contractor, my environments change, often daily/weekly. I routinely switch between Java, PHP, Vue, React and some other tools. Doesn't matter WHAT I do, I end up having some stupid red squiggles telling me I can't use "double-quotes" or that I can't use 'single-quotes', depending on context. Multiple languages and 'community standards' conflict with each other, and I'm always c…

> It does mean that some people who place a high value on standards and listing and visual style are placated. This times a million. It doesn't help that the advocates of linting are so dogmatic about the whole idea (as demonstrated so colorfully in this thread and this sub-thread in particular). I mean, I understand why. Linting is an all or nothing type of thing. But I'm still going to remember the lint-advocate as…

I think it's mainly the difference between result- and process-oriented personalities, with the latter being advocates of linting and other "formalities", and the former opposing it.

As someone in the former group, I completely agree that these sorts of things bring little value; the fact that the code works is the most important, regardless of how it looks. If your coworkers are writing code that's not working or misleading, talk to them about it.

I've got project one which insisted - the point of blocking PRs - that "Yoda style" for null checks was mandatory. Guess what? Another project I'm on, Yoda-style is prohibited, because "it's confusing". Every keystroke I'm having to wonder/worry about what context am I in, and always battling stupid red squiggles.

That sort of insignificant minutiae really irritates me. It shouldn't matter at all, yet some people love to make mountains out of molehills. (I personally use the "if(ptr)" style because it's the simplest, but I wouldn't care if my coworkers used "if(NULL != ptr)", "if(ptr != NULL)", "if(ptr != 0)", or "if(0 != ptr)"; they're all equivalent, and anyone who doesn't know that, doesn't know the language. "if((NULL != ptr ) == true)" will cause me to raise a comment, however, although not a blocking one.)

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

#266

Post by cheez »

est31 wrote: post #263
SOLAR_FIELDS wrote: post #259

Earlier quoted context omitted.

Wouldn't having the autoformatter run as a pre-commit hook alleviate this issue? (This is assuming you had already cleaned up all of the currently checked in code with said autoformatter)

Most autoformatters are under active development, and updates to them often causes changes in their behaviour. So you have to have all devs agree on the precise version of the formatter used, and even then you still need to do regular commits that contain nothing but a run of the newest version of the formatter on the codebase, which sadly destroys long term git blame.

this is a solved problem, pin your packages.

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

#267

Post by waheoo »

SOLAR_FIELDS wrote: post #259
waheoo wrote: post #244

Earlier quoted context omitted.

Ive seen heaps of autoformatters dirty up version control. Mostly when theyre fussing about new lines. I kind of wish autoformatters would just ignore new lines and focus on indentation alone. It would certainly cut down on the over zealous rules. I also think formatting should be separate from linting but because they both require a parser people seem to think theyre the same thing.

Wouldn't having the autoformatter run as a pre-commit hook alleviate this issue? (This is assuming you had already cleaned up all of the currently checked in code with said autoformatter)

Prettier specifically annoys me to no end with this problem.

If youre adding more attributes to a jsx component later and know it you might format to multiline early. It decides to undo your work and slow you down, because some arbitrary line length.

Similarly, if you go over that line length, on something you want single line for readability of structure, it just straight up does what it wants.

Im 100% on the auto format train but it has to go the gofmt route and only apply rules that are actually important and incredibly uncontroversial.

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

#268

Post by CGamesPlay »

waheoo wrote: post #244
stimpson_j_cat wrote: post #209

Earlier quoted context omitted.

Not to mention it dirties up version control. It's a lot easier to tell which _significant_ things changed from the last commit when you're scanning a diff and no formatting changes are highlighted.

Ive seen heaps of autoformatters dirty up version control. Mostly when theyre fussing about new lines. I kind of wish autoformatters would just ignore new lines and focus on indentation alone. It would certainly cut down on the over zealous rules. I also think formatting should be separate from linting but because they both require a parser people seem to think theyre the same thing.

This problem is caused by adding a formatter to your editor, instead of adding it to your project (or one of your contributors adding it to their editor). But if you adopt a formatter into the project, then this isn't a problem. Create one commit called "reformat all files", and then use `--ignore-rev` to never see it in your git log.

If your contributor is changing thousands of lines in a diff to fix a typo, ask them not to do that :)

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

#269

Post by sethreno »

Merad wrote: post #264
Guillaume86 wrote: post #93

Earlier quoted context omitted.

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

ReSharper's formatter is pretty good, but you do have to pay to use it in the VS IDE and it's kind of slow. The service I'm working on at present is fairly small (20k LOC) and formatting the entire solution takes about 5 minutes in the IDE or 30 minutes in CI. :/

Is your service open source? I'd be interested in testing it. Also, you could speed up formatting in CI by only formatting files that changed.

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

#270

Post by ergothus »

a_t48 wrote: post #208
VectorLock wrote: post #196

Earlier quoted context omitted.

Normally I agree with treating code as a means to an end rather than an end to itself but I take a certain enjoyment in crafting in some way aesthetically pleasing code as well. I even find that if the code is "ugly" that there frequently might be a more eloquent and objectively better way of doing things. And a little time hand formatting I think is worth it if you're maximizing understandability and readability. No…

Consistent style is more important than each block of code being perfectly pretty. You can still argue aesthetics, but they need to be applied across the entire codebase. Never having to bother someone because their PR doesn't meet the formatting guidelines is well worth it.

> Consistent style is more important than each block of code being perfectly pretty

"Pretty", yes, but we're literally talking about using language to communicate. Consistency taken to extremes is harmful to communication.

I don't understand the worship that people have for consistency. STUPID inconsistencies are bad, yes, and yes, there are certainly arguments that about subjective matters that are a waste of time. But distilling everything down to the lowest common denominator of grunt-talking is very consistent and terrible communication. (Does that feel like a strawman? I'd love for it to be! Once people stop talking about consistency uber-alles we'll be discussing the things that I consider important.) Right now, the most common reaction is to dismiss any idea of communication through language as irrelevant, subjective, and a waste of time."

Post reply on HN