71–80 of 360 posts
- UPM: universal package manager https://github.com/replit/upm
- Prybar: universal REPL interface for interpreters https://github.com/replit/prybar
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 can wholeheartedly recommend Black for Python, gofmt for Go, and terraform fmt for Terraform. What are some other great formatters out there?
Earlier quoted context omitted.
> 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.
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 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!
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'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.
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.
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'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.
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."
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
Hi, there is a local run option with instructions here: https://github.com/github/super-linter/blob/master/docs/run-...
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...
I wrote an article a while ago arguing this point: https://jonathan.bergknoff.com/journal/run-more-stuff-in-doc...