Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Super Linter: one linter to rule them all

github.blog

Post reply on HN
Print view View original

111–120 of 360 posts

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

#111

Post by wenc »

philwelch wrote: post #98
minimaxir wrote: post #82

Earlier quoted context omitted.

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.

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

#112

Post by ausjke »

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.

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

#113

Post by michaelmior »

kevin_thibedeau wrote: post #94
michaelmior wrote: post #92

Earlier quoted context omitted.

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.

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.

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

#114

Post by Vinnl »

kristopolous wrote: post #104

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.

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

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

#115

Post by dllthomas »

philsnow wrote: post #110
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 / ind…

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.

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

#116

Post by nxrabl »

philsnow wrote: post #110
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 / ind…

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

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

#117

Post by philsnow »

ori_b wrote: post #25
GaryNumanVevo wrote: post #22

Earlier quoted context omitted.

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
Post reply on HN