Hacker News new | past | comments | ask | show | jobs | submit login
GitHub Super Linter: one linter to rule them all (github.blog)
622 points by Amorymeltzer on June 18, 2020 | hide | past | favorite | 349 comments

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 it myself).

I also love just banging out code, saving, and having my editor clean up the formatting for me.

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 because you like your bracket with a different spacing is IDIOTIC. Run the formatter and move on.

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.

Not arguing about style is nice, but having to resort to this brutalist architecture style of code formatting doesn't seem great to me. "Its just holding people, who CARES what the building looks like!"

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."

I’d agree that 100% consistency is harmful to communication, but the primary communication happening in programming is with a computer. Even when it comes to other developers looking at your code, their internal process is “let me simulate what the computer understands”.

Unless you are enforcing weird autoformat choices, everything should look pretty enough.

> the primary communication happening in programming is with a computer

Working in a team with 15 people on the same code base I disagree with this. Count the computer as one teammate

"Style" means things that the human sees. If it changes execution its not style any more. This is what tests are designed to enforce.

People at work nit: my code all the time. I just straight up ignore them. If they ask me why, I tell them to add an autoformat to our ci or shut the hell up.

Fwiw, i use an auto formatter but its got problems with certain rules so i switch them off.

The reason we dont have it turned on in ci is because these rules break code.

Yeah, auto formatter (or at least format validation) is a must.

There are two kind of painting. You can paint a wall/a building, or you can paint Mona Lisa.

This is the same for programming. Each dev have their own taste in term of code style and code formatting preferences. I was an early employee in a startup, and at some point I was able to tell who wrote a chunk of code just from the code style, it was fun :) but as company grown, and team got bigger, it got more "professional", now we have prettier which erases a big part of our code personality. If you believe like me that coders are artists you might find that a bit sad, but the truth is that most Enterprise software building is wall painting, and art doesn't have its place there. That doesn't prevent us from painting Mona Lisa at home though :)

I like the point in general, but I will say there are times when idiosyncratic formatting can really help understanding "this particular bit of code". Often it has to do with aligning values so that they are easier to read; if a code formatter was smart enough to at least understand the signal the programmer is sending, and maintain (or even improve!) that kind of formatter, it would be the best of all worlds.

One simple example is when you're parsing text and you have a long list of simple one-line if statements. I personally think it's wasteful and harder to read that block of code if you impose curly braces and new lines on that list of conditionals. This kind of formatting convention has been around for at least 40 years, and it makes the code more readable. I have yet to see an auto-formatter that doesn't turn that kind of code section into an unreadable mess.

Or key value lists where the keys have slightly different lengths.

It's possible to do both: https://designyoutrust.com/2019/03/in-berlin-there-was-a-gia...

There's also plenty of room for art in the choice of materials and colours as well as the shapes of buildings. Likewise, with code, if you limit yourself to only what one person can do, you'll end up with a very constrained view of what "art" means.

You will flip out when you discover “git blame” or, even better, GitLens on Visual Studio Code.

I find that if the auto formatter isn't dealing well with a section of code, it's usually an indication that the code architecture is off. Too clever, too verbose, too much nesting, trying too hard to make one-liners, etc.

There's a beauty that comes from simplicity, and code for matters, at least for me, are good of reminding me of that.

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.

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.

> It decides to undo your work

What you're missing here is that you're supposed to be using it all along, all the time. Format on save. Format on commit. Format on server pipelines. Format all the time. It can never 'undo' anything if it's what's providing the formatting in the first place.

Thats what im talking about. If you add text to a line, and it goes over a length, it will reformat a jsx element into about 5 lines instead of 1. Similarly, when you add more than it needs because you want consistency, or know youll add more, and the formatter runs, often it undoes your work.

Prettier lets you control object literal formatting by inserting/removing the newline after the opening brace, I'm not sure why they don't do that for JSX elements.


If you really want 5 lines, add a dummy // in there and will be forced to use 5 instead of 1. Dirty hack, but it works.

That, or a prettier-ignore comment above the JSX tag. I find your solution more elegant, though.

My two cents: Write the comment's purpose inside it. "// Comment inserted to force prettier line break until more attributes are added"

Im talking about adding an attribute in the next 5 minutes, no, im not going to add a comment, or an ignore line while im editing a component. Those are really awful work arounds to a man made problem.

It's tunable. Pick a line length you all agree on and when it reformats after that, that's what you asked for.

If the rule never works for you, turn that one off.

If the rule is what you want 99% of the time but it made this one line look dumb, mark that one block #ignore and let the team decide in CR if that was the right call.

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.

Chromium has a presubmit that enforces that code is autoformatted. However, it only enforces this for changed lines, and in practice, it works pretty well.

this is a solved problem, pin your packages.

But you still have to update them every now and then otherwise you can't use new features of your language. Which gives you the issue of breakages again.

I dont think people want to hear that there are still problems with autoformatting text.

Anyway, my point still stands, drop rules about line length and rules that care about inter line break positions and most of these problems go away.

Sure. Most large teams do this on a 6 month basis or when it is needed to implement something. Again, a solved problem.

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 :)

My workaround is to run the formatted in the whole codebase as a separate PR, make the commit with a separate user that’s none of my colleagues (like “Prettier <invalid@acme.corp>”) and add that commit’s hash to a file in the repo. I then configure git to use that file for ignoring changes in git blame.

Now the code is formatted and additions won’t trigger reformatting the line or the file.

That doesn't necessarily mean that you need to check in auto-formatted changes. You can just autoformat the two revisions before feeding it to the diff program.

Of course, a lot of tooling simply isn't there for that, unfortunately, but that's what I see as the ideal solution.

We've found https://git-scm.com/docs/git-blame#Documentation/git-blame.t... very useful in these cases. When Prettier changes significantly, we run across the whole codebase & add the commit to an ignore file.

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.

Not to mention that if multiple people work on a codebase over time, if a very large project gets very old (like 20 years old), having consistent formatting goes a long way in allowing people to understand code that they may not have context for.

Agreed. I adopted the Wes Bos approach (drive Prettier from ESLint) and it's fantastic.

Any links? I only use it for react. I found eslint auto fix works well enough for node etc

I agree with you, but I’m not gonna lie: you had me worried with your first sentence. :)

I don’t know. I feel formatting choice can carry information and removing that information for conformity might be not worth it.

Huge plus!

Personally I vote to let people write code in the format they are most comfortable with and run the formatter as part of CI

Not sure I agree. Most coding is maintenance. Far better to adapt to whatever the coding style convention is.

I also believe that formatters should be "light-touch" and not have an opinion about every last thing. At that point I start thinking, "if you so smart, why don't you write the bloody code!"

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.

I feel the same, fmt is a productivity boon for me too.

There was a good quote from Rob Pike in his Go proverbs talk: "Gofmt's style is nobody's favourite, but gofmt is everybody's favourite."

Many linters have built-in auto-fix features like what you describe. (eslint, for example)

    rubocop -a
For the win.

Not the same experience as some of the best formatters out there. RoboCop is too configurable and too slow.

It would be nice if Rubocop didn’t need as much customization as it does, because it promotes styles that violate everything I have done in my 18 years of writing Ruby.

Some of its defaults? Fine, whatever. Others? They’re just _wrong_.

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.


I'm tired of seeing diff chunks on github where 95% of the chunk is because black/gofmt decided to change the formatting / indentation / grouping / whatever. I want language-agnostic, AST-aware diffing, that de-emphasizes the part of a chunk that is irrelevant-in-the-world-of-auto-matic-code-formatting.

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.

Storing an AST instead of text might be a way to eliminate parsing ambiguity of angle brackets for generic arguments (as opposed to comparisons). It might still be visually ambiguous, but I don't think it's a problem in practice (if the display forces whitespace around comparisons)?

There are some cases where formatters like Prettier don't have one canonical representation for an AST, in particular behavior around line breaks (multiple empty lines are allowed, a line break after an "{" opening brace in an object literal will force it to span multiple lines, etc)

But yeah, otherwise everyone could just have their own preferred formatter/settings and we could commit whatever representation is most optimal for diffing to version control (e.x. multi-line object literals, trailing commas in arrays/args, etc).

You could use something more compact like a binary AST but for compatibility with "legacy" tools that deal with text I think it would be better to use a more verbose text-based representation.

I believe unison does something along those lines:


I believe that's called "lisp".

Which lisps don't use text files for source code?

I kind of like the ability to have comments, though. The tools I've worked with have issues round-tripping them though ASTs.

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.
    >>> import ast
    >>> ast.dump(ast.parse('print "foo"'))
    "Module(body=[Print(dest=None, values=[Str(s='foo')], nl=True)])"
but in python 3.7:

    Python 3.7.2 (default, Feb 14 2019, 16:12:42)
    [Clang 10.0.0 (clang-1000.10.44.4)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import ast
    >>> ast.parse('print "foo"')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/Users/philsnow/.pyenv/versions/3.7.2/lib/python3.7/ast.py", line 35, in parse
        return compile(source, filename, mode, PyCF_ONLY_AST)
      File "<unknown>", line 1
        print "foo"
    SyntaxError: Missing parentheses in call to 'print'. Did you mean print("foo")?
nothing changed in the text, but the AST is different. What should get committed to this hypothetical "git-ast"?

The answer probably lies in creating a different abstraction , different building blocks. In git we have bytes -> blobs -> trees -> commits, where the bytes of a given file get annotated with a file name (and mode bits etc etc, gross posix things) by the tree object.

In git-ast, maybe the abstraction is bytes -> lexemes (which annotates the bytes with a language version, and thus lexer version) -> tree? I haven't gone down the thought experiment that far.

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.

That was maybe not a great example, pick any language change where a new keyword was introduced that wasn't previously a keyword or reserved word.

I tried to make an example with `with`, because that was introduced between 2.4 and 2.5 IIRC, and 2.4 and 2.5 aren't nearly as far apart as 2.* and 3.*, but I didn't find an easy way to install a 2.4 python (it didn't compile in pyenv on my mac, and I looked at a couple docker images before giving up).

But you're describing a benefit of storing an AST. Instead of the code suddenly changing meaning, you have an AST that says what the meaning should be.

The worst case is that you export it with the old version of the converter, and then the code changes meaning. You have silent corruption. But if you stored raw text this would always happen.

The good case is that you export it with the new version of the converter. It will notice that a variable name matches a keyword, and alert you to fix it.

Since even minor releases can introduce new syntax that previously failed to parse, this happens more than just on major version numbers. For example: async/await, formatting string literals, underscores in numeric literals, the list goes on and on. So you'll have to upgrade your formatter. And when you upgrade it, it may start formatting something differently than it previously did, even if that chunk had no new syntax.

Use one that won't change how it formats on a whim?

Because that requires either compiler support, or a plug-in to be written for each language and language version. But, I guess you can always fall back to text files in the worst case.

Sounds like a great idea, or binary representation of lexer tokens, the AST is larger in size than the lexer tokens and the AST can be easily generated from the tokens

This is basically solved by pinning the formatter to a specific version in your project's dependencies, and enforcing its use in continuous integration.

Of course that doesn't help if you're setting up the formatter for the first time, or want to upgrade to a new version.

Some tools like GitHub's diff do try to deemphasize whitespace but it's pretty limited.

In easy steps (Python/Git specific):

1. Use a tracked directory for Git hooks: `git config --local core.hooksPath 'git-hooks'`.

2. Create format.bash and lint.bash.

2.1. Run `black` and `isort` in format.bash.

2.2. Run `flake8`, `mypy`, `black` and `isort` in lint.bash.

2.3. Run lint.bash in the pre-commit hook.

2.4. By default, lint/format only files which are different from origin/master to save time: `git diff --diff-filter=d --name-only -z origin/master "[asterisk].py"`.

3. In CI, run lint.bash with `--all` or some other keyword to verify formatting on every file: `git ls-files -z -- "[asterisk].py"`.

After more than a year with this setup I absolutely adore it.

Even better, IMHO, is just setting your editor to format on save. That way you can just write ugly code and hit save to get it formatted.

I've found git hooks to be more trouble than they're worth.

But as long as it's enforced in CI you can leave it up to individual team members how they want to do it.

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.

The frustration is real in a PR situation when you have your editor set to run a formatter on save (same thing with stripping whitespace) but if you have enough control of the project and want to switch to using a formatter then git can help you there.

You can do a format run over the whole codebase then ignore the commit in blame.


Hopefully you're already aware but just in case: many tools (including git and github) have an option somewhere to hide whitespace changes. In some contexts this can help a lot, though it certainly doesn't get us all the way there.

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..)

Formatters don't have the understanding like the developers do. Certain changes that might increase the understandability for a human might get obliterated if they don't conform to the rules of the autoformatter.

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?”

Yeah--we're basically second-order black formatters now. Not writing code that looks nice, but writing code so a tool that writes code will make it look nice.

Not really. At least that wasn't my intention to say that. Most of the time, I find Black does a Good Enough Job(tm) that I don't care to mess with it.

I agree with sentiment but I don't think it's entirely true that it only affects reading code. When it comes to modifying existing code, I have to deal with whatever format the existing code was written in. For example, personally I hate working with code with tabs so I would find this frustrating. (As an aside, I'll admit this is really my problem and a rather silly one.) Of course one solution is to transform code on read to the current user's preferred format and then back to the canonical format on commit. Although this seems potentially error prone.

> When it comes to modifying existing code

You don't have to deal with anything as long as you're using the same formatter everyone else is using.

My point was that when writing new code, I can write it in whatever format I want knowing that it's going to be formatted the canonical way. But when modifying code, I have to work with code in one specific format that may not be my preferred format.

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.

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.

And in those large reformat commits, add a file like `.git-ignore-revs-file` that is checked in, so you can configure git to ignore that revision and pretend it never existed:

      ignoreRevsFile = ".git-ignore-revs-file"

That's an incredibly useful trick to know

This is something that keeps coming back to me either as a feature or as a product of some kind - a tool that can stop this from getting in our way.

The simplest and safest would be to apply the formatter to both the old and the new copy before diffing it. It ceases to be the actual difference at that point, but there are definitely two distinct use cases for diffs - one for humans to read and one for the machine to apply.

The other case that would be amazing but even more of a stretch would be to rewrite the entire history. It seems like there is a spot for "different views of history" and you could do a no-difference merge to join the to histories as of now so that the actual history did not get lost. As I write this, it starts to sound like just a caching system for the idea above.

This needs a highly reliable formatter of course... I have on occasion had code broken when formatting.

If you're talking about moving from a codebase that did not use a consistent formatting style or a style that did not match the auto formatter configuration, sure. I was assuming a case where automatic formatting was done from the start.

Git has an option to ignore certain commits when doing a git blame, —ignore-revs. You can also point it to a file with —ignore-revs-file <file>. You can configure this per project with git config ignoreRevsFile .git-blame-ignore-revs. After doing this, you get nice diffs AND nice looking code. The price to pay is that every developer has to run one git command locally.

I feel like this is a team preference problem and not a formatter problem. The formatter will only do what you tell it, spaces or tabs.

Looking at this another way, formatters are designed to "frustrate" devs into working only 1 way. If you think it's more helpful to have a codebase with mixed spaces/tabs with commits that express each developer's unique flair, then a formatter is not for your team.

Formatters are a way for one person who likes the formatters output to enforce their will on other who might not necessarily like that.

I can wholeheartedly recommend Black for Python, gofmt for Go, and terraform fmt for Terraform.

What are some other great formatters out there?

The previously mentioned prettier[0] along with swift-format[1] and rustfmt[2].

[0]: https://prettier.io [1]: https://github.com/apple/swift-format [2]: https://github.com/rust-lang/rustfmt

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

I wish their was a standard c# formatter too. dotnet-format doesn't support wrapping long lines which is one of the more important features in my opinion.

Resharper has a free command line tool that supports wrapping long lines. https://www.jetbrains.com/help/resharper/CleanupCode.html

I made a wrapper for it to try and make it easier to use. https://github.com/sethreno/ReGitLint#regitlint

Thanks I will check it out

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.

Nah, this is from my day job so it's a proprietary closed source thing. Supposedly the CI speed issues are because the CI has to start with cold caches every run (we use Gitlab pipelines that run in docker containers) whereas the IDE has the caches on hand. Something about the way our devops has set up the Gitlab runners makes enabling shared cache much hard than it should be so I haven't had the chance to test that. I don't think I ever tried limiting it to only changed files, that's worth a shot.

I really want one for sql, but haven't found any good ones available.

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.

I started programming in the 80s, so I'm used to double-quoting anyway.

Apostrophes occur so often in English that it makes it easier to type strings like "I'm a dog". With single quoting you have to go 'I\'m a dog'.

If I hit double quotes in a string, I just triple-quote.

"""He said "hah" sarcastically""".

I know Guido (van Rossum) prefers single quotes -- I'm not sure why exactly -- so it's become a default Python style. I tried to adopting it but always ended up reverting to double quotes.

I use single quotes simply because I'm lazy and tapping the quote key with my pinky is marginally easier than shift-quote :p

> I'm not sure why exactly

Might be ease of typing? Eg: `foo = 'bar'` doesn't require any shift chords, whereas `foo = "bar"` requires two. Though then I'd expect similar preference for kebab-case in identifies, for similar reason.

Yes, that must be right, although to me the trade-off is escaped strings which lack good aesthetics.

'The class of \'72 didn\'t think much of Sam\'s speech'


"The class of '72 didn't think much of Sam's speech"

To me, the shift chord is an almost negligible price to pay for more aesthetically pleasing strings, especially since on a QWERTY keyboard, the shift key is literally right next to the ' key. For emacs users who are used to complex key chords, it's even more negligible.

I do use single quotes for strings frequently in interpolated f-strings though:

f"The date is {result['year']}"

Unless I mean straight quotes, I type curly quotes as a matter of course. Love my Compose key. :)

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

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


But the double quotes are exactly what I like about Black haha.

We use klint at work (Kotlin) https://github.com/pinterest/ktlint It's take inspiration from standardjs and gofmt

mix format for Elixir

rubyfmt for Ruby

Yup, we recently implemented auto linting/formatting using pre-commit hooks and it's made a huge difference in maintainability and readability.

I don't care about the specific formatting/linting rules as much as I care about consistency. Auto formatting is great to reduce friction for those on the team who can't/won't convert change how they write code locally.

Universal formatter & linter tools already exist. A whole bunch of them, and they're much better than this one. I wrote about a number of them on my blog at https://blog.urth.org/2020/05/08/comparing-code-quality-meta...

I used to program Java. A friend of mine put together the largest slide deck I have ever seen documenting not only how we format code, but also rules for how to structure code.

We spent a lot of time on making the code look like it at least came from the same company. And weeks of my life has been wasted trying to get people to agree on code formatting and coding style.

Fast forward a few years and we start using Go. I didn't agree with some of the formatting choices or code conventions. And pretty much everyone on the team had at least one thing that would grind their gears.

But we agreed that we'd use the gofmt tool to format the code. As everyone now does: by ensuring whatever IDE or editor we use pipes the code through that.

It took less than a week for everyone to adapt and I have hardly heard anyone complain since. There are still things I think could have been different, but for me, that's a very low price to pay for not needing to have these discussions.

IMHO there should be a distinction between code serialisation (the bytes on-disk, in version control) and code formatting for display/editing.

The serialisation should be normalised automatically, preferably in a way that minimises line-based diffs.

The way code is formatted for display should be distinct, and can usually be more of a personal preference. Most people seem to be happy for their editor to use syntax highlighting to make things more readable, but not much else. Indentation, line length, aligning sub-expressions, etc. can also help readability, but showing those things differently from the bytes on disk is usually avoided.

Perhaps this is due to a conflation of meaning for certain bytes. For example, \n can mean "token separator" to the language, "long line splitter" or "intent separator" to the developer, "unit of comparison separator" to version control, etc.

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.

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.

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.

You're probably right, but I'm not interested in putting it to a vote. Most programmers are pretty bad at writing readable code. If the computer can understand the code, many consider it done.

I aim higher than that.

google-java-format has been imposed from outside our team. It's not configurable, makes poor choices a lot more than 1% of the time, forces diffs to cover many more lines than needed, and vandalizes blocks that were already well-formatted by a professional for human readers.

I think there are few subjective style choices that are so egregious that a robot would have done a better job. Where I want enforcement is likely correctness and safety mistakes.

I have not used that and can’t speak to its quality.

When you use a standard formatter, people adapt. It’s as if formatting becomes a part of the language. Yes, there’s some initial pain, and, yes, some constructions become awkward occasionally, but, if you really need to, you can generally tell the formatter not to mess with a specific section.

I like formatters like Prettier and gofmt as well, but not StandardJS. I'd still use it if everyone used it though. I just don't like their stance of relying on automatic semicolon insertion, even if Go does the same thing

I agree with you. We recently implemented a mandatory code formatter for Python code at work. Many people hated it, but I love it for this exact reason. Now, I never get comments about formatting!

In general, I tend not to care a whole lot about style, except to try and match whatever is pre-existing, as long as it’s vaguely readable. Otherwise, it’s basically whatever python-mode on emacs does, subject to a reasonable line length. Formatting nitpicks in code review bug me enough that I always just give in and do what they suggest.

That would be great if I actually worked on a team who saw the light and used tabs. Unfortunately I haven’t had that pleasure in a long time, so no, I do not agree with their formatting choices to use spaces. I guess what I really need is an editor that will convert spaces to tabs when I open a file and then convert it back to spaces when I close the file. Although that’s still not quite ideal because it’s not always a lossless 2-way conversion.

No, you need an editor that abstracts away the indentation and uses the existing style of the file. I use the tab key to indent code, my editor (Emacs) is configured to just cycle through sane choices.

gofmt's idiotic handling of maps and forcing them to align entries was enough to put me off the entire idea of autoformatters.

Enforcing a code style where adding a single byte can result in an unlimited-number-of-lines block in a diff is pure idiocy.

It's bad enough having to review someone's changes when they're polluted with this garbage, but it also makes merges fail more often and pollutes `git blame`.

The idea that people will put up with this crap because they can't just unclench about a few spaces here and there I will never understand.

"But it minimizes diffs because it stops people committing simple spacing changes" - people shouldn't be adding those hunks to their commits in the first place and such changes need to be pulled out in review. This will also get people out of the habit of just blindly doing a `git add`.

edit: I'm certain that if slightly non-uniform formatting really sets off your OCD then this should be solvable to some degree at the editor level, but please keep your obsessions out of my repository. In return I'll keep mine out of yours.

Yeah -- we use Python Black and it's a blessing. The entire purpose was to replace linting so that we could have something extremely opinionated so that people could stop arguing.

This seems like a cool tool, but I don't know if I would use it at this point. I would _pay_ for having autoformatters from Github -- it was a pain to set it up and would love to just enable on new projects.

> This is why we allow users to use any rules for the linter as they see fit for their repository.

So not like prettier/black/goftm.

You get to choose. It's more of a way to group things.

Which make sense. I don't mind being dictated code formatting, but linters will complain about branching, number of arguments, comments and so on. I change the settings of my linter for each project.

Those should not be fixed.

I really want to love Prettier, but I never want to spend the hours googling etc. on how to setup the frickin config files! Especially as someone who works on a wide variety of languages/file types, I really want to find a drop in formatter that works well enough in all situations.

I think you might be thinking of ESLint? Prettier has, like, 10 options, and they are all listed on this page [0], and you aren't required to even have a config file because the defaults make sense.

I personally find ESLint to be a nightmare of configurability and silly defaults.

[0] https://prettier.io/docs/en/options.html

My first real software job I was subject to long, painful PRs full of semi-colon nitpicking. I fucking hated it and have made sure to use auto formatting on any project I work on from now on. gofmt paved the way, but rustfmt and Prettier are also great.

That's exactly the right way to do it and I've been advocating for this, as well as maximum use of parsing/tranformation/codegen technology (essentially compiler tech) for development productivity, long before LSP was a thing.

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.

Very frustrating working in Xcode because it doesn't support a code formatter out of the box. Some extensions do a passable job but randomly break when I have multiple versions of Xcode installed.

I'd like to see robust solutions for formatting personalisation: locally I'd like to use my own style, but in repo it might be canonical so an assistance for that might be easier to create.

I don't like auto-formatters as they take away the personality, and sometimes even change the meaning of the code. I prefer intelligently formatted code over automatically formatted code.

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.

when my co-worker moves a curly boy, I'll fight to the death. When a tool does it, I shrug and move on..

Exactly what I love about Go and Gofmt.

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 they've been using so far, but now you have to maintain linter configs in two places.

I get why it's probably not ideal as a local tool, and integration with Status API is nice and all, but I personally prefer to see devs linting their code before pushing for review.

Correction: it can run locally in Docker, as pointed out below: https://github.com/github/super-linter/blob/master/docs/run-...

Hi, there is a local run option with instructions here: https://github.com/github/super-linter/blob/master/docs/run-...

It's kind of odd that GitHub is asking people to pull an image from a Docker account that most people won't recognize (admiralawkbar/super-linter), as opposed to an official GitHub one.

Which is funny too because GitHub repos have Docker repository functionality: https://github.com/features/packages

But since its release, you still can't do public pulls: https://github.community/t/docker-pull-from-public-github-pa...

What was Admiral Ackbar's famous quote?

“ask yourself if that answer doesn't make you look just a bit like a dewback's cloaca”

It’s an exception?

GitHub's Super Linter has an unusual history. See below for example:



admiralawkbar accounts for 80% of the commits in the repository and over 98% of the code churn. I'm guessing this was a side project of his (Lucas Gravley aka admiralawkbar) and the docker image was just something that was overlooked when it became an officially advertised GitHub repo.

Yup, thats exactly what happened.

looks like it's changing now: https://github.com/github/super-linter/pull/137

Have to install docker to run a linter... Nah, thanks.

Docker is probably the least annoying solution, would you rather install linters for 40 different languages on your system?

I'd rather not run a linux VM for this, so yes. It should be possible to isolate it to /opt/github-linter/* on my BSD machines, or put into a nix package.

(Also, I guess this is one more reason that docker is a big red flag for 'hastily hacked together unportable software that would be hell to ship.')

I'm 100% fine with running this and similar tools with docker to avoid polluting my machine with dependencies / un-uninstallable cruft and also to allow the people making such tools to concentrate on the tools and not supporting installation on 30 different platforms. Hell, docker even works on windows these days.

but your comment made me think of this meme, which I can't not link to https://i.imgflip.com/24ac74.jpg

text for people who don't want to click:

    It works on my machine

    Then we'll ship your machine

    And that is how docker was born

Look at the Dockerfile, it's all there. All 143 lines and 2 bash scripts. Are you about to introduce a new BSD ports package?

Install linters as needed / pick up what's already installed could be a feasible option.

Sure, if you want to get a billion issues reported that are caused by outdated versions of the linters.

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 platforms? And now you multiply all that effort by the number of linters you are packaging, because almost none of them share a common toolchain.

It just opens a whole box of problems, that do nothing to actually further the tool you are building.

The "install as needed" linters of course should live in their own separate universe, not scattered everywhere.

Alternatively you ask people to install linters themselves, and refuse to run if they're outdated. Language X devs likely already have reasonably up-to-date language X linters installed, or know how to install them anyway.

A lot of effort: probably. Many different platforms: there are three platforms that carry any weight. See GitHub Actions runner environments.

Docker on the dev machines is easy for the project, but (1) performance is subpar on macOS and Windows due to virtualization; (2) it also gets outdated; (3) the image is easily gone if you like pruning, then you need to pull the image all over again. (Thankfully the image isn't huge, ~380MB at the moment.)

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

Installing Docker is so easy, and it’s significantly easier than installing individual tools when we’re talking about shared tooling and local development. But hey, you do you!

I'm about to uninstall Docker. I have a 128GB Macbook Air and it's taking up 17 gigs after some light use. I'll be using it from CI instead. I like it but it isn't a no-hassle option. It depends on the project whether it's easier. I prefer to avoid it if I can.

Not to be that guy, but I feel the 128GB drive is more to blame than Docker at this point. 17GB just isn't that outlandish these days.

You can prune unused containers and images if didn’t know it already

Oops, missed it, thanks for the correction.

Having to use docker certainly affirms "I get why it's probably not ideal as a local tool" to some extent, though...

On the contrary: Docker is currently the best way, bar none, of distributing tools like this one to developers. Kudos to the Super Linter developers for doing this right.

I wrote an article a while ago arguing this point: https://jonathan.bergknoff.com/journal/run-more-stuff-in-doc...

Regarding "cross-platform": Docker for Windows used to be really terrible IMO (relied on VirtualBox, did not translate WSL paths, etc). I never managed to get the networking between VirtualBox, WSL and applications (e.g. Chrome running in Windows) working properly.

Thankfully Microsoft rewrote WSL 2 in a way that makes it work much better with Docker.

I've also had some bad experiences with Docker for windows but that was quite a few (2+ years ago) - since then it's mostly been smooth sailing for me, even without WSL

My experience was that it used to be bad specifically because of the bad interactions with WSL (1)

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,.

So, this looks interesting. Rather than a real new linter, Github is proposing a tool that runs against a number of common linting standards with a single shared standard library.

Perhaps it would have been better pitched a Lint-runner for CI jobs rather than a real linter.

Never thought of that! That does seem more accurate and descriptive.

Agreed. The headline and article had me believe that this was some language-agnostic linter framework. Which I guess it is in a sense, but it's only the dispatching part that's language-agnostic.

The primary feature is the integration with Actions. Surprisingly most linter actions don't give you inline annotations. For each linter you have to find a separate solution.

Css Eslint


I ended up using jest and the linter plugins for that, just so I would get readable inline reports. Otherwise it just fails and my devs have to search for the raw log in the checks panel.

I didn't do any others because it's too much work to set up and runs longer, burns more carbon.

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...

Fun fact : it runs a shell script of "only" 2300 lines : https://github.com/github/super-linter/blob/master/lib/linte...

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 ?

I mean I would do the exact same thing. Consolidate dev mindshare around the organization. That doesn’t mean I have to like it!

Indeed and I wasn't criticizing you, this was a legit question: Is there a way in that situation to continue improving while not creeping out users. I guess the answer is to do it for long enough without screwing your users like MS did in the past.

I guess the extreme would be to spin off Github into a non profit like a Mozilla, but dedicated to improving software tools and keeping them open source.

MS only owns GitHub, not git. Likewise, MS doesn’t own docker, Linux, or, as other comments have mentioned, any of the actual linters in the image. I don’t really see the problem, unless you’re actually developing inside the MS / .Net ecosystem.

Definitely. Side projects, fine. But I'll never use a pipeline that's coupled to my VCS hosting solution for anything production facing. Did it before and not only does it make it tricky to move to another VCS host, but your ability to release is held hostage by their uptime - which isn't super reliable.

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.

As if licenses mean anything. What exactly does forking by you?

the ability to use an old working version if the maintainers make breaking changes - which will at least buy you enough time to move to something else

I guess you've never worked in a .NET shop before? Or the days when everyone just developed on Visual Studio on Windows, before Macbooks for developers was a thing?

Yes I’ve worked in MS shops, even written Win32 code. I learned a monolithic dev ecosystem was what I personally did not want. So that pendulum swung more towards OSS...

I think most developers would agree that "open source has won". I feel the aspect of it that you're focusing on here is the ability to choose the best-in-breed tools, and to be able to swap each one out individually as better options arrive. If Microsoft's approach with its open source tooling is to follow that mindset, I'm not concerned. If it isn't, then eventually people will either move on to other tooling or fork it.

Now, if we're saying that Microsoft should be spending more of their time on interop and portability but chooses not to prioritize their resources on that, then that just falls into the category of common complaints that people have with all open-source projects and what the contributors choose to spend their valuable developer hours on.

I am starting to feel this way about just git.

How so? Don't get me wrong; I dislike monocultures and wish hg/fossil were more popular, but git is open source, portable, and totally supports distributed workflows.

Yep. I'm not a giant fan of the way GH is currently moving. GH is slowly becoming what Atlassian wish it had.

Yes. Me. Very.

There seems to be a universal law of software systems that if small, self-contained subsystems exist - someone will glom them all together into an Uber-system, and vice versa. It’s inescapable.

In business they call it bundling and unbundling:

> There are only two ways to make money in business: One is to bundle; the other is to unbundle. [1]

[1]: https://twitter.com/eriktorenberg/status/1214671238552940544

This happened at a number of places I worked!

In one case, we started with a monolith, broke it down to a service oriented architecture, realised the SOA was not scalable enough, so rebuilt the monolith. Good way to waste a couple of years!

“You will appear to be a visionary planner if you decentralize everything which is centralized and centralize everything which is decentralized.”

— Dogbert, Build a Better Life by Stealing Office Supplies (Dogbert’s Big Book of Business), Scott Adams, 1991

That’s kind of the rationale behind the Unix philosophy. Every individual tool does one thing well, but, many tasks need you to do n things. So, you bodge together a few of the simple tools (analogy: simple machines from classical physics), et voilà! Now, you’ve done something bigger than the sum of its parts.

Yes, this is a bit different, but, you know, having a super-linter around would be kinda handy. It gets old installing and configuring these things sometimes.

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 to the cloud, it will be tied directly to the deployment to a specific platform, such as Azure if this is offered by GitHub. Then Amazon and Google will have to build their own IDEs in the cloud to compete. We'll no longer be developing locally but in the browser, and it will cost a lot more.

I fully agree. The "I" in IDE (Integrated) has not aged well, just look at how many parts of the software development cycle are outside of the IDE. It's time to really integrate/bundle everything in a way that makes sense.

Things I want in my IDE:

- monitoring/alerting (how many times is this method executed, how long does it take, how many errors, etc)

- discussions as in Google Docs on code fragments, rather than "comments" that are part of the git history (comments are an orthogonal concern from checked in code)

- visual representation of my code base

- ultra fast automated test that cover only what I recently changed

- a documentation system that makes sense

> The "I" in IDE (Integrated) has not aged well

This such a good observation. I will be using this quote in the future.

I've seen what integration of the development environment looks like inside a big company (Facebook) and it's just amazing how seamless everything can be when all your tools are built with an awareness of each other. I think we'll see that soon outside these big companies.

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.

> I'd also say Repl.it is very similar too.

Indeed. It's interesting that GitHub Classroom uses Repl.it (and another MS web IDE) rather than Github Codespaces:



Seems like a friendly ecosystem for the moment.

Automated code review SaaS'es (using off-the-shelf linters, and more) have been around for what, a decade, or longer? So this is not "one step closer" to linting as a service.

Yay for (some) Perl support!

The Perl validation seems to be restricted to "compile with warnings", despite "perlcritic" being now almost 15 years old, predating both some other linters' and even some other languages' very existence.

I'll try to see how feasible it'd be to add it as a ("the"?) Perl linter to be used as using just the compilation step to infer everything's fine doesn't really satisfy the role a linter is meant to have.

Also note that "perl -c" can't be used securely against untrusted code:

  $ echo 'BEGIN{`cowsay pwned > /dev/tty`}' > test.pm
  $ perl -Mstrict -cw test.pm 
  < pwned >
          \   ^__^
           \  (oo)\_______
              (__)\       )\/\
                  ||----w |
                  ||     ||
  test.pm syntax OK

Also, it looks like the perl linter only triggers against .pl files and not .pm files

Yes please! Feel free to open up an issue and collaborate with others to get it added! https://github.com/github/super-linter/issues

What's very interesting in the list here: https://github.com/github/super-linter/#supported-linters

Java is the only major language without any sane default coding standard (no, google-java-format is google-specific, outdated, not up-to-date with recent versions and not maintained by community). It's a pity really.

I wonder why they went with Standard for JavaScript and TypeScript, instead of Prettier which is far more popular now.

As others have stated, prettier is a formatted not a linter. I do however agree that Standard is a weird choice and in my experience is far from an actual “standard”. IMO the Airbnb style is excellent and would have been a better choice here. It’s also available as an ESlint plugin. Hopefully something like this can be configured on the GH Action in the future, allowing for a choice between available presets.

Sounds like there is some consensus around switching out Standard. Feel free to open up an issue in the repo and we can discuss and move forward there if you like.

Prettier is a formatter, not a linter.

Standard isn't a linter either. My question was why they're using the Standard style, rather than the Prettier style, both of which can be validated with eslint.

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.

> Java is going downhill(as in not much new code is being written in it)

This is just completely false.

- https://madnight.github.io/githut/#/pull_requests/2020/1

- https://insights.stackoverflow.com/survey/2020#technology-pr...

I could link many other links showing Java as an extremely widespread language. There is just nothing comparable in the corporate world.

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 :)

Seems like this is the equivalent to GitLab's Code Quality CI template [1]? Which is supposedly built on Code Climate [2].

[1] https://docs.gitlab.com/ee/user/project/merge_requests/code_...

[2] https://codeclimate.com/

We're in the process of stripping out Code Climate at work. Since it's difficult to run locally, the whole "let CI run to see if your code lints" isn't a great experience. And when first running prettier on our codebase, it stated something like 8 days to "fix" it.

Just a poor experience all around.

GitHub's approach here seems much more sane.

They don't do the same thing

Oh we use GitLab for work. Was wondering if there's an equivalent for that or similar.

GitLab Product Manager here - The Codeclimate engine that out CodeQuality feature uses does support about half of the same languages as SuperLinter through plugins that can be added in the codeclimate.yml file. We are exploring how to support the missing languages and add output to the existing and future CodeQuality features.

We have also seen that SuperLinter can be run as part of a GitLab pipeline without too much hassle.

-James H Product Manager - Testing

You can see how to do so here, if interested: https://gitlab.com/snippets/1988376

> Setting up a new repository with all the right linters for the different types of code can be time consuming and tedious.

Is it? In my company I maintain a set of exemplars for all of our commonly used repository types. When someone wants to make a new one they just copy and paste stuff from one of the exemplars.

Over the years I've come to value "white box" code re-use over "black box" re-use. In my experience many projects will outgrow their tools and need custom tooling, so it makes sense to keep the black boxes tiny and copy over large tooling in a white box fashion. For example, what if I want to change the Python linter for Pylint to flake8? I'll need a separate fork of superlinter or something. I'd prefer to just edit the tooling that is build in to my project.

So basically you've done the same as super linter at your company. But now, nobody else has to go through the pain of setting all of the exemplars up, because you get nice defaults, everything included for free from super linter.

> The rule set for Ruby and Rails are pulled from the Ruby gem: rubocop-github and follow the same rules and versioning we use on GitHub.com.

Anyone know how this compares with https://relaxed.ruby.style ? The default rubocop is very angry about meaningless shit, curious where github falls on that spectrum.

What 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.

I was looking for one recently and was also surprised not to find anything really. I thought there'd for sure be one already packaged for `pre-commit`.

I tried apexsql and redgate and didn't like them. I do like the built in one for datagrip, it still isn't perfect but is acceptable for me. Apexsql has a cli too I believe

Am I the only one that dislikes linting?

Btw, you don't have to respond with the talking points I've heard all my life on why it's supposedly great, I've obviously heard them and think they're bogus.

I just find it strange that I'm the only one.

I'm strongly against over-bearing autoformatters.

In my experience a little hand crafting tweaks to formatting go a long way to increasing understandability.

It feels like a lot of people are having issues with bikeshedding and they're using enforced autoformatters to impose their will and stifle debate they may not like.

Not arguing about style is nice, but having to resort to this brutalist architecture style of code formatting doesn't seem great to me. "Its just holding people, who CARES what the building looks like!"

Also thing like line-length limits. I'm with Linus on this one, enforce line-length limits causes a lot of problems, like breaking context in greps. And an autoformatter that breaks at a certain number of characters is never going to be able to understand the context to break it intelligently.

Are people using editors that don't display long lines wrapping properly? Do people think everybody uses the same resolution, the same window size, the same columns per terminal, etc?

i completely agree with you. i think the people who advocate for auto-formatters must not be very skilled at using their text-editors and/or don't put enough attention on readability/understandability. i'm happy with linters and command line tools to auto-format when you explicitly call for it, like `eslint --fix`; i'm just not on board with the formatter running on git hooks or in whatever automated workflow.

almost every rule has an exception where understandability could be improved by violating the rule, ex. line length. code format is huge for understandability/readability, which makes it worth paying attention to while you're writing.

in my experience the loudest advocates for code formatters are the ones who write really complicated code; which makes sense that they just hammer on code until it works without being able to reduce and simplify their logic and naming.

*idk about that last part; it's a dumb anecdote. the auto-formatting i'm salty about is prettier. ones that are manually invoked and either 0 config or highly configurable (like eslint) seem sensible. use an auto-formatting hook in your text-editor if you want; i just don't like the absolutism of it being hard-baked into everyone's workflow and a tool with limited non-zero config.

I swear by auto-formatters, and I've always been good at making readable code. I love auto-formatters because it makes everyone else's code readable too even if they're bad at formatting it themselves.

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 constantly having to double check things and 'clean up' stuff.

And... conforming to all of these various 'standards' has not increased the speed of development, nor the robustness, nor the client satisfaction. It does mean that some people who place a high value on standards and listing and visual style are placated.

Increase of automated testing and documentation have more value - long term and short term. And I understand it's not an 'either/or', but visual style and 'linting' standards are low-hanging fruit that are immediately visible, so tend to get more attention (and ongoing).

And then in group discussions, I end up being the person who is apparently "AGAINST CODE STANDARDS". I'm not terribly against them, but in the projects I end up being involved in, it's lower value.

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.

If you spend 40+ hrs/week using one and one one tech platform where you can have one standard to follow and adhere to - great. I switch platforms, teams and projects regularly, and it's soured me on the huge importance some people place on linting.

> 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 a developer too concerned with the wrong things.

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.)

The justifications I've had over the years:

"It means we don't have to argue about style"

Well... for the most part, I wasn't arguing about your style in the first place. You're trying to get stuff done your way under the guise of "let's all stop fighting and just get along". I didn't start the fight.

"It makes things easier to read"

If it's harder for me (and some others) to write it that way, it's because it's not natural/default, and, actually, it might actually be harder for me (and some others) to read as well.

I routinely work with folks who like to 'omit' 'unnecessary' lines - omitting a curly brace block in a one-line if is a regular example.

    if (foo) {
ends up as

    if (foo) bar

    if (foo)
Honestly I can't remember which. Had 'feedback' from people removing my braces saying "these are unnecessary". But now there's two styles I have to be able to read/write, and... there's almost never a time when one line without braces is sufficient forever - whenever I need logging or another piece of code in the block - bam - now I have to add braces, and that whole area of the code looks more 'different' than it used to.

I joined a project - small startup - code in production for... 4 months at this point. 0 tests of any sort. First week, I do a small feature, add a test, and it was blocked, because I used a single letter variable name in a data setup method in a test file. "Single letter variables aren't professional". Developing and pushing code with no tests for 6+ months apparently is just fine though. I was tempted to use a four-letter variable name... They then got automated-linting fever.

> But I'm still going to remember the lint-advocate as a developer too concerned with the wrong things.

See its the opposite for me. If I cant trust you with something as dead simple as "npm run lint:fix", how can I trust you to respect any of our more important policies? It's completely disrespectful to the whole team.

Honestly, I cannot imagine a larger waste of my time than a colleague critiquing code format in a code review. And of the colleague's time. For this complaint of no value whatsoever, they have stalled the merge by whatever the average latency of their code review is. At the very least I have to wait for them to look at it again to see my response that I will not accept the style suggestion.

I'm working with a consulting team of around 8 that was brought in to augment an enterprise team.

Had a Java PR blocked because I'd used "Integer" instead of "int" and "the compiler's going to have to do more work autoboxing".

There was some other feedback on the diffs too. While technically 'correct', the use case for the code is a 10-15 second process that is run around 200 times per week for one specific client on one server (not clustered, just housing that client and maybe a dozen others). This Integer is housing a sequence counter that may go up to 10 in some cases so... we may be saving a fraction of a second 200 times per week, based on this PR change.

MEANWHILE... the 'in house' team - who reviews themselves - somehow manages to push code in to the main develop branch which, once it's pulled down, results in a system where the initial "dashboard" screen is literally broken after login. That will get pushed to the 'testing' server where 15-20 people do routine 'testing' for various client work, meaning... one bad push puts 30+ people out of commission for hours. This has happened 5 times I'm aware of this year.

But... int/Integer merits holding up a PR.

> developer too concerned with the wrong things.

Hyper-concern of linting is in my top 10 red flags of an engineer that is likely unable to prioritize without significant and continuous direction from a PM. It definitely does not mean that are not a skilled developer. Often it does indicate they are quite good. But it also indicates they can not be left alone too long without supervision.

I think many people install the default linter for their ecosystem, get satisfaction from a bunch of essentially busy work getting some green check marks or removing warnings, and believe their code is better.

That’s not really that beneficial, and I can understand why you may dislike this sort of thing.

I think the real benefits come when... - you can enforce a very consistent style, more than a typical linter - you start adding custom linters for things that matter in your codebase

The second point here I’ve used to help move Python 2 to Python 3, move from one library to another by showing linter warnings for importing the old one, enforce new call patterns that might be tricky to enforce in code (like always calling function A before B). It’s less about “linting” and more about flexible static analysis and warnings, and while there will always be other ways to implement those it’s another tool that can be useful to have in your team’s toolbox.

I'll stand with you. I understand the arguments for linting, but the only positive from my perspective is that it scratches enough itches of the Type As out there that they'll climb off my back and get back to being useful...well get back to "organizing" whatever else it is they think is too unruly.

What do you dislike about bugs being highlighted as you type, rather than first having to run your code?

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. Maybe you have deep nesting so you want to go from 4 spaces to 2. Maybe you want no braces in a single line if statement except in certain cases. This could go for pages. Poof! All gone. You can't do any of it anymore.

Not following optional syntax like having a space after a comma or a space before a parenthesis is not a software bug. It's a waste of time. The compiler doesn't care and I don't either.

Instead it becomes a literal Blocking Issue most of the time. So instead of working on the actual blocking issues of the code base, you spend time doing "you did this here because of some context I don't understand and I'm not allowing it" You can't commit your code without conforming to it.

Also because linters are dumb. They "spot" things that are perfectly fine as supposed bugs (because they don't actually know types or logic, they're just dumb syntax checkers) and you have to work around them to satiate them with the possibility of introducing new bugs to prevent some tripwire system from false positives.

Compiler writers and language designers are the only people I've found who agree with me.

It's fine for protecting against profound levels of incompetence but I don't do that and you probably don't either.

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 (and it's hard to argue that it does not), then that's surely a plus?

(Also, why wouldn't linters know types?)

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

Could it be that the problem with the linters you've experienced was that they were just configured far too strictly about things that don't matter too much, rather than linting itself being the problem?

I've got my linters set up pretty loosely, but the things that are enabled have definitely helped me detect bugs earlier and quicker, and I really don't see how anyone could be against that.

well sure. There aren't bad tools just bad practitioners, sure. Certain tools give more affordance to certain use cases and maybe that's the issue.

For instance something where I am the culprit would be in PHP. I like PHP. I think it's a convenient and powerful language. Someone could take my linter arguments and weaponize them against PHP because it's too easy to do terrible things with it. Then I'd be the one on the other side of the argument all of a sudden, standing in defence of this easy to use language with handy powerful abstractions that can trash a system in a few keystrokes.

I think the difference is when we can come to an agreement that say, PHP is a very powerful tool in competent hands and a very dangerous tool for the foolish.

Going back to the topic at hand, I think the foolish side of linting is the dominant application I see in the wild. I used to use a barrage of proto-linting static analysis tools in my CVS scripts during the wild C days because pointer logic and memory management was notoriously tricky and gcc 2.x was notoriously forgiving. These tools could save days of debugging, really, yes, days.

If we can do that for say python it'd be great. Something saying "Oh I see you are doing a list[1:] in a tight loop, have you thought about collections.dequeue? it may be a better option" - those things are things I do actually forget about and would find helpful.

It'd have to be voluntary though. Prod me a bit but then let me dig my own grave if it's a mistake. That's what the power of computing is also about.

Yep, I can definitely agree there.

That said, I'd argue against strict stylistic rules, not against linters in general. For example, the common Javascript linter (ESLint) has a setup wizard that allows you to choose whether you just want to check for bugs, or also enforce style conventions, and will enable a predefined set of rules depending on your choice. The bug-spotter is the one that's preselected. This is a very reasonable approach to me.

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.

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

we probably just code different things for a living. It's a big world. I'm sure they're useful in your job.

I will agree with you that shitty linters are shitty.

> 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. Maybe you have deep nesting so you want to go from 4 spaces to 2. Maybe you want no braces in a single line if statement except in certain cases. This could go for pages. Poof! All gone. You can't do any of it anymore.

Literally none of these should be flagged by a linter IMO, except maybe the braceless if[1]. If those checks are present I would disable them. Those sound more like a code-styling tool, and is particularly egregious because every single thing you mentioned could be automatically changed by a code formatter!

Examples of things a good linter will pick up on: Unused variables, dead code, use before initialization.

The most absurd case of a linter helping was when fixing an unused variable lint warning actually allowed me to speed up a program by almost a factor of 100 (it precomputed a value and then called the version of the function that didn't use the precomputed value in a tight loop).


Do you disable warnings in compiled languages? Note that linters for non-compiled languages are used at least partly to catch things that would be warnings or errors in a compiled language.

1: No braces in an if statement should probably be flagged when the THEN clause is on a separate line because it's a future bug waiting to happen, but I can see the argument for allowing it when it's a single-line statement. OTOH if (foo) {bar();} is only 2 characters longer and 4 if you put whitespace between the braces

> If those checks are present I would disable them.

The purpose of linters on a team - so I've been told - is so that no one has to argue about formatting anymore.

So now we just get to argue about what rules we can enable/disable?

Even though it's perfectly legal to disable linting for lines or files, most of the time when I do it, it's flagged by someone in review, and there's some discussion and I'm forced to rewrite and remove my disable and go back to whatever the linter was forcing. "These rules are there for a reason, and were put together by people with more experience and smarter than us - we shouldn't go disabling things whenever we want just because we don't like them or think we know better". (amalgamation of multiple comments from people stopping me disabling lint checks in specific situations).

This doesn't happen every time, but enough that the occasional 'disable' isn't something I can just do without worrying it will end in multiple hour discussions. Which is probably what people want - unquestioning conformity to "the one true way".

> The purpose of linters on a team - so I've been told - is so that no one has to argue about formatting anymore.

Code formatting is just one feature a linter may have (e.g. shellcheck[1] and pyflakes[2] are definitely linters but don't have code formatting checks).

I disable all the formatting checks in my linters because if I want to enforce a formatting standard, a code reformatter is probably a better way to do it.

1: https://www.shellcheck.net/

2: https://pypi.org/project/pyflakes/

> The purpose of linters on a team - so I've been told - is so that no one has to argue about formatting anymore.

People who argue this are, I believe, missing the forest for the trees. A short on-the-spot version of something I've had in mind for a long time:

almost everyone has a slightly different style that they fall into and the individual styles arent necessarily difficult to understand


Your Brain Adapts To A Given One, When Reading That Style. It May Still Feel Like Stuttering, But Once Adapted It's Fully Readable.


The problemcomeswhen You have MULTIPLE people OnA team, and THE SYLES getallmixedupsoittakes a lot moreefforttofigureoutwhatTHEFUCKisgoingon.

Linting is all about picking a style and sticking with it so the code doesn't end up with multiple personality disorder.

> Even though it's perfectly legal to disable linting for lines or files, most of the time when I do it, it's flagged by someone in review, and there's some discussion and I'm forced to rewrite and remove my disable and go back to whatever the linter was forcing. "These rules are there for a reason, and were put together by people with more experience and smarter than us - we shouldn't go disabling things whenever we want just because we don't like them or think we know better". (amalgamation of multiple comments from people stopping me disabling lint checks in specific situations).

When this happens, I think it should open a wider team conversation about whether that particular rule is actually worthwhile, or whether it goes against what your team wants and should be altered/disabled. Unfortunately, I have encountered a couple rules where the linter wasn't configurable enough to get what we wanted as a team, so there's definitely reason to allow per-instance disabling...

> It's fine for protecting against profound levels of incompetence but I don't do that and you probably don't either.

Everybody starts at a profound level of incompetence. If you want a junior to be able to make a contribution and you don't want to spend half of the pull request discussing mundane aspects of their code style, then linters and formatters improve the situation somewhat.

> 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"

concat strings? PREFER TEMPLATE!!!

OK, ESlint, have it your way, please auto-correct that...

    `Hello ${  user.name}`;

And... this is just one set of 'best practices' to learn - change per language/framework/team multiple times (sometimes in the same week) and it's... difficult.

Yes, I'm an old-fogey. I have close to 30 years of muscle memory of using string concat and double quotes. "auto-fixing as I type" brings a huge interruption of flow, and THESE ARE NOT BUGS. They are style choices someone else is imposing on me. It doesn't make the code less buggy. It doesn't make the client any happier. If someone else coming in to the code is genuinely confused, confounded or severely impeded by

   let greeting = "Hello " + user.name;
to the point where they have trouble deciphering the work, perhaps they're not terribly good at their job?

Goodness help folks when new management comes in and demands a new 'better' style.

So the problem is having rules enabled that do not help prevent bugs. Actually running ESLint for the first time will ask you if you just want to check for bugs or also enforce some code style. The former is preselected, and would not shout at you for not using `const` or template strings.

I'd always argue for using it that way, which is very reasonable to me.

(A bit weird to have 30 years of muscle memory writing `let`, btw :) )

The funniest part about that particular example is that it's highly likely you're using babel to support old browsers, and the compiled version just switches it back to string concatenation.

In the example above, I believe that's the case.

Again, an issue with switching between projects/styles, for me - one client/project insists on "const" in JS. Another client/project is supporting a product on IE9 for a client of theirs, but doesn't use any build tool for some of that JS, so we're not even supposed to use "let" or anything else "new" for some of that project. Mentally switching between those two worlds is like jumping between 2019 and 2009 every few days.

Realistically, could we introduce a transpiler? Technically yes, but operationally? It's a Frankenstein project that has so many larger issues that's low on the list for people (sections of the functionality are being migrated over to react altogether, and throwing 'more tools' in to the mix on legacy stuff is not desired).

You're not the only one. It's just that people who like to impose their will (or style) on others are a lot louder about it, unsurprisingly.

They use the excuse of the linter sometimes highlighting potential bugs to impose their preferred formatting style wholesale over everyone. And it's purely an exercise of power of one person over others -- the computer doesn't care about your style.

And it's not enough, some people will ask you to move sections of code around and start arguing about naming once they have no inconsistent white spaces to complain about -- that's how you know it's not the linter or formatter that they want, they want to control people.

I used to be bullish on linting around 2014-2017. Now I avoid them as much as possible.

Bad linters are expensive. They add complexity to workflows and pipelines, slow down iteration speed, and create a nitpicky culture where most discussions miss the point. Multiply this by a whole engineering team, yikes.

Yet there are some good (parts of) linters, such as catching actual issues rather than preferences. If we bet on linters, they should increase our value multifold to be worth it.

> Am I the only one that dislikes linting?

You're right, I much prefer de-linting, but to each their own.

(it's probably just an artifact of ancient unix history that these tools are called "linters" instead of "delinters", because they preferred vry shrt nms bck thn)

Linting is a lot more relevant and less of a time-sink when you combine it with formatting. Basically, all you’re left with is bugs that need to be fixed, and you completely axe all style arguments.

IF you're the only one, maybe the talking points are correct...

Care to explain why you dislike it?

Right there with you. Overrated.

No talking points, but since everyone finds the value in it and you don’t, maybe you’re wrong and should give it a try?

I have for over a decade, dozens of times in about a dozen languages over thousands of hours. That's what formed my opinion.

I think this is great.

I use SwiftLint for my code (Swift, not supported in SuperLinter, and I don't expect it to be).


I am real big on code quality. LINT is not a silver bullet, but every little bit helps. I also use things like -wall (or the equivalent, thereof, in Swift), and heavy-duty code commenting.


Happy to see this development! There was an earlier attempt at universal static linter by the coala project [1], however, in the recent years the project was not keeping up with the underlying tools changing [2].

It's lovely somebody's picking up the torch here!

[1] https://github.com/coala/coala

[2] https://github.com/coala/coala/graphs/contributors

The trend of putting developer tools behind a unified API is just awesome. Especially great for tool makers like us at Repl.it. We're investing a lot in this area too:

- UPM: universal package manager https://github.com/replit/upm

- Prybar: universal REPL interface for interpreters https://github.com/replit/prybar

I don't understand why there's any innovation around linters. To set them up as a PR hook, you literally just run a single linter command and check the status code. Why use something like this, or the absolutely horrible tool Codeclimate? Linting is a solved problem and easy to set up, and linting rules should be a per-TEAM decision to empower teams to solve their own problems.

Totally understand. I think the problem we are trying to solve here is integration with GitHub Actions as well being able to easily set up multiple linters for code ASR’s with many languages. Hope that makes sense.

There are already quite a few projects that do this, and IMO do it better. I did a write up of a number of them on my blog - https://blog.urth.org/2020/05/08/comparing-code-quality-meta...

Visual Basic (6 at least) had none of these issues. It formatted your code as soon as you pressed <enter>. Im don't recall ever having control over the formatter, which was great because everyone's code ended up looking the same and there was nothing they could do about it.

This is great, but desperately needs a way to also fix these issues. And all functionality should run locally as well.

I imagine the latter is possible thanks to it being a docker image.

So far I've been using this script I built for similar purposes:


Runs locally, and only on changed files against master. Fixes all my python, JS, yaml, terraform, etc. And you can run it against a single file too so I integrated it with vim to replace all my linters.

I really hope the GitHub initiative projects takes off as a standard API (à la language server) for linters and fixers. Seems every single IDE needs to reinvent a plugin for applying a specific linter.

I think there is an opportunity to integrate/add your gist to the super linter. Feel free to open an issue to get that started.

They should have explained what a "linter" is at the beginning of the post. [0]

[0]: https://sourcelevel.io/blog/what-is-a-linter-and-why-your-te...

Considered that but thought the target audience might be familiar. I think your suggestion would have made it more accessible though to those who have not been around linters before.

I like the way it improves the quality of deploys. Actually different approach but same aim is hidden behind Assistant extension to Visual Studio Code. I think both solutions are complementary to improve quality of team work. If you want to check Assistant out version 0.9.0 was just released two days ago: https://marketplace.visualstudio.com/items?itemName=tomasz-s...

It would be nice if you said that it's your own extension...

My name is Tomasz Smykowski. Assistant is my design. And I am proud of it!

Thanks for sharing that! I didn't know it existed.

Sounds great! I am sure you will enjoy it. If you have any feedback let me know. Cheers!

Please someone design a cppfmt for c++ in the modern age.

If possible for C as well, to a less extent.

for clang-format, it can not even add blank lines between functions, and it can not indent "public, private, protect" inside class sanely, which are two very basic needs. The rest options are worse, however, but I hope something better than clang-format.

Interesting, but ultimately the best linting tool is one that runs prior to commit. Especially if it can auto-fix.

No C/C++ support?

You don't have linters for C/C++ as far as I know. I guess they could have included code-formatters too, like clang-format.

I learned C 1986 and lint existed back then. According to Wikipedia it's from 1978.

Of course C was a different languange back then. But I am rather sure modern variants exist.

Clang-tidy comes to my mind, but I don't write any significant amount of C/C++ these days.

lint for C has existed in one form or another for 42 years.


I used this in the past: http://cppcheck.sourceforge.net/

Lots of comments seem to not know about SonarQube[1], which is a meta linter that has been existing for a while now.

[1] https://www.sonarqube.org/

This kind of reminds me of check-all-the-things:


Reading through all these comments I see a lot of people saying "it stops the debate about style!"

It seems like people are having more of an issue with bike shedding than actual code formatting.

Can we have something to beautify the code too? Like gofmt or shfmt?

golangci-lint already supports gofmt. You just need to turn it on.

shellcheck doesn't support formatting. I don't think some of the others support formatting either.

This is just a linter aggregator so someone has to write a formatter and popularize it first.

Yes. I was asking if they could consider adding a code formatter too.

You got me motivated, ONE linter for everything.

Then I checked the code and see that this is a bash script which just runs the language-specific linters packaged in a Docker container :(.

Argh I just worked on exactly this idea, as a tool for my company! What do people do when they see an idea they had/care about being implemented by someone else?

This is the nature of invention -- the current climate gives multiple people the same good idea around the same time. You could abandon and join, convince the other project to do the same, keep working on yours, stop working on yours and use theirs... depends on your goals.

I'd like to find a formatter that aligns opening and closing braces and parentheses vertically, if they span more than one line. Is there such a formatter?

that's fine and all, but it sounds like I'd have to do a bit of manual work to get the same exact set of linting rules locally, so that I can lint before pushing.

CI linting/testing should be a final check, not a part of your iterative workflow. Any linting or testing you do in CI should have already been done locally by the dev.

I wish this would also prevent creating PRs that don’t pass the lint rules. It reduces churn on PR reviewers.

You could use something like https://github.com/typicode/husky to prevent a push if the linter fails.

My (small) issue with git hooks, is that they need be installed everywhere for them to be 100% enforced. Works fine for small teams, but doesn’t scale that well beyond that.

You make the hooks as part of the CI process. That's where something like husky can come in. We do this on my team.

If you're trying to enforce something locally you can definitely enforce it on CI automatically. Once people realized their PRs were failing due to linting issues they started checking them locally as well.

This is what we use. Husky runs linters on pre-commit to ensure everything is linted going into the repo.

We added linter checks to our Travis CI config. It helps flag the PRs that don't pass the linter.

The problem I've seen is that the error message isn't obvious. It just says that the "build failed", which sounds more like a compilation error than a lint problem.

that's what github actions are for.

Why does this post have so many commenters conflating lint & friends with code formatting tools?

I feel like this is just softening us up for the inevitable vscode (online edition)

Does the linter check all or only newly pushed code? Is this configurable at all?

Checks all by default but you can set an env variable in the config to only check new code.

Can someone recommend a Java alternative to ESLint for JS eco-system?

Used `checkstyle` 4 years ago to improve the quality of code. Has neat XML based rules and good IDE support. See if it fits your use-case.

GitHub got a lot of fire in their ... after acquisition. I was stunned how fast GitLab overtook GitHub feature-wise, but looks like now they're at least trying to compete.

And in the darkness combine them?

Obligatory XKCD comic: https://xkcd.com/927/


Not particularly, I think. It's just bundling a ton of existing linters, not competing with them. What is it competing with?

Applications are open for YC Winter 2023

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact