GitHub Super Linter: one linter to rule them all • Hacker News Board

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

#101

Post by [deleted] » Thu, Jun 18, 2020, 6:12 PM UTC

oefrha wrote: post #60

jameslk wrote: post #48

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…

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.

[deleted]

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

#102

Post by chrisweekly » Thu, Jun 18, 2020, 6:13 PM UTC

honkycat wrote: post #87

tlrobinson wrote: post #37

Great! Now do it for code formatters! After using Prettier for a few years I'm firmly in the camp of mandatory/enforced code formatters. As long as it's a half decent formatter like Prettier I believe my personal opinions on the specific formatting choices are much less important than essentially never having to think about formatting again, in particular having to ask people to fix formatting in code reviews (or fix…

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…

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

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

#103

Post by jwilk » Thu, Jun 18, 2020, 6:16 PM UTC

mfontani wrote: post #8

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…

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 
   _______
  
   -------
          \   ^__^
           \  (oo)\_______
              (__)\       )\/\
                  ||----w |
                  ||     ||
  test.pm syntax OK

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

#104

Post by kristopolous » Thu, Jun 18, 2020, 6:16 PM UTC

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.

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

#105

Post by jtwaleson » Thu, Jun 18, 2020, 6:17 PM UTC

jameslk wrote: post #48

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…

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

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

#106

Post by toolz » Thu, Jun 18, 2020, 6:20 PM UTC

kitplummer wrote: post #90

lixtra wrote: post #86

Earlier quoted context omitted.

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

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

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

#107

Post by zodiac » Thu, Jun 18, 2020, 6:21 PM UTC

jbergknoff wrote: post #80

oefrha wrote: post #23

Earlier quoted context omitted.

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.

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

#108

Post by necrotic_comp » Thu, Jun 18, 2020, 6:22 PM UTC

honkycat wrote: post #87

tlrobinson wrote: post #37

Great! Now do it for code formatters! After using Prettier for a few years I'm firmly in the camp of mandatory/enforced code formatters. As long as it's a half decent formatter like Prettier I believe my personal opinions on the specific formatting choices are much less important than essentially never having to think about formatting again, in particular having to ask people to fix formatting in code reviews (or fix…

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…

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.

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

#109

Post by libria » Thu, Jun 18, 2020, 6:22 PM UTC

michaelmior wrote: post #49

6gvONxR4sf7o wrote: post #42

Earlier quoted context omitted.

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…

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.

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

#110

Post by philsnow » Thu, Jun 18, 2020, 6:23 PM UTC

tlrobinson wrote: post #37

Great! Now do it for code formatters! After using Prettier for a few years I'm firmly in the camp of mandatory/enforced code formatters. As long as it's a half decent formatter like Prettier I believe my personal opinions on the specific formatting choices are much less important than essentially never having to think about formatting again, in particular having to ask people to fix formatting in code reviews (or fix…

Code autoformatting is amazing and I never want to go back; even though I strenuously disagree with the particular formatting my team/company has chosen for python, I'm so relieved to never ever have a style discussion in PRs that I don't care about double quotes vs single quotes anymore.

BUT

I'm tired of seeing diff chunks on github where 95% of the chunk is because black/gofmt decided to change the formatting / 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.