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

251–260 of 360 posts

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

#251

Post by wenc »

a1369209993 wrote: post #192
wenc wrote: post #111

Earlier quoted context omitted.

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…

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

vs

"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']}"

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

#252

Post by nilkn »

erik_seaberg wrote: post #247
nilkn wrote: post #149

Earlier quoted context omitted.

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.

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 like…

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

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

#253

Post by justatdotin »

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…

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

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

#255

Post by obrajesse »

jwilk wrote: post #103
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

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

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

#256

Post by gtm1260 »

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…

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.

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

#257

Post by ryanblakeley »

ryanblakeley wrote: post #214
VectorLock wrote: post #204

Earlier quoted context omitted.

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 co…

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…

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

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

#258

Post by aidenn0 »

lowercased wrote: post #205
aidenn0 wrote: post #183

Earlier quoted context omitted.

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 an…

> 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 rewr…

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

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

#259

Post by SOLAR_FIELDS »

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

Earlier quoted context omitted.

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

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

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)

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

#260

Post by jameslk »

jtwaleson wrote: post #105
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 "…

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

Post reply on HN