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.
GitHub Super Linter: one linter to rule them all
41–50 of 360 posts
Re: GitHub Super Linter: one linter to rule them all
#42Great! Now do it for code formatters! After using Prettier for a few years I'm firmly in the camp of mandatory/enforced code formatters. As long as it's a half decent formatter like Prettier I believe my personal opinions on the specific formatting choices are much less important than essentially never having to think about formatting again, in particular having to ask people to fix formatting in code reviews (or fix…
So much this. I had strong opinions on style until I found good autoformatters. Now I write horribly unformatted code and it comes out super clean and organized as soon as I hit save. Now I don’t even really care what the standard is because it only affect reading code.
Re: GitHub Super Linter: one linter to rule them all
#43There 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.
Re: GitHub Super Linter: one linter to rule them all
#44Earlier quoted context omitted.
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.
Re: GitHub Super Linter: one linter to rule them all
#45There 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
Re: GitHub Super Linter: one linter to rule them all
#46that'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.
Re: GitHub Super Linter: one linter to rule them all
#47Re: GitHub Super Linter: one linter to rule them all
#48One 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.
Re: GitHub Super Linter: one linter to rule them all
#49Great! Now do it for code formatters! After using Prettier for a few years I'm firmly in the camp of mandatory/enforced code formatters. As long as it's a half decent formatter like Prettier I believe my personal opinions on the specific formatting choices are much less important than essentially never having to think about formatting again, in particular having to ask people to fix formatting in code reviews (or fix…
So much this. I had strong opinions on style until I found good autoformatters. Now I write horribly unformatted code and it comes out super clean and organized as soon as I hit save. Now I don’t even really care what the standard is because it only affect reading code.
I 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.
Re: GitHub Super Linter: one linter to rule them all
#50What'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.