Maintain consistent styles for developers working across various editors
editorconfig.org
editorconfig.org
Others:
https://direnv.net/ -- when you cd to a directory, do things like set variables.
https://asdf-vm.com/ -- manage and use specific versions of software. Can work with direnv too!
https://pre-commit.com/ -- git hooks that I personally found easier to manage than Husky.
https://github.com/qoomon/git-conventional-commits -- enforce standard commit messages. Works with pre-commit!
I loathe pre-commit hooks. I often times just want to save work in progress or show someone what I have right now and they slow down my work or worse fail and lose my commit message and cause me to have to figure out how to disable them to continue. If you want to run checks for formatting or similar that is much better done in CI. I can get a reminder without breaking any dev workflows. Of course make fixing formatting a single command, and maybe an optional hook for those that prefer it. But when projects try to auto-install hooks it drives me crazy.
So you can go wild in your own branches and draft MRs but anything you want someone else to review has to pass.
git commit -n|--no-verify
git config --global rebase.autoSquash true
git commit --squash|--fixup <commit>
git rebase -i origin/master # or whatever your remote/branch is
Works wonders, but occasionally you screw up. To get out of screwup, use `git reflog` and `git reset --hard`.
Any check that take more than 6 seconds can also go jump off a cliff as car as I'm concerned.
But I do greatly value fast fixing & feedback. Run format! (and don't print out unchanged things!) Run lint! Maybe run tests, if they're fast.
One of the constraints becomes that you are trying to make quick actionable easy to view data, and the output can become too long. We had some outside teams come in & deploy centralized & more updated lint & testing, and alas there's just multiple pages of yellow jest configuration warning as it starts, and it's just so much harder to quickly check status. These hooks need to be quick to read, as well as run. All of the hooks should run if they can, not stop on first problem.
Ideally the ci/CD system is a good fast way to see test results. Devs shouldn't even have to think about it, just commit & off board the running. I hear Facebook has very interesting systems where devs aren't even having to make commits for this, which sounds epic. Alas many ci/CD systems are doubly slow, which sucks: slow to start, slow execution speed, and most damming low caching, so they have to do a lot of from-scratch bring up that just takes a really long time versus what local dev has. Systems like nx in JS land are starting to change this more systematically, rather than being a lot of custom ci/CD tweaking.
Informational, not prescriptive! Use the tools to accelerate & guide. Right now we're all learning but tool heavy setups are for sure the way.
- Pre-Commit hooks that fail to handle partial stages.
- Running CI as far away as possible to enlarge feedback time.
- Non-incremental builds.
But pre-commit hooks should fail fast.
Just use dotenv instead.
https://asdf-vm.com/ -- manage and use specific versions of software. Can work with direnv too!
May be useful in some cases, but adds a global dependency on asdf itself.
> https://pre-commit.com/ -- git hooks that I personally found easier to manage than Husky.
Git hooks are disturbing and slow down and/or break advanced git interactions.
> https://github.com/qoomon/git-conventional-commits -- enforce standard commit messages. Works with pre-commit!
Only if you want to be so pedantic about them. I find it mostly a waste of time to enforce commit message style.
While minor variations exist, virtually all Java code follows these conventions pretty closely.
Although I'll note it seems to get a bit more chaotic with regards to indenting newer constructions like streams and lambdas.
function(
arg,
arg
);
Then it also insists on aligning everything prettily. Most, but not all of it can be disabled though.
And lastly it doesn't do very well with tab indents. Most of it works perfectly, you just need to set both tab size and indent size, but then it decides to do its alignment thing and suddenly that line is all spaces, even the base indent.
Clang-format is honestly by far the worst formatter I've had the displeasure to fight. C/C++ still needs to be formatted manually
Oooh, that's much closer. Not perfect, but so much better. Do you have a solution for this as well?
→(StructType){
→····.a = 1,
→····.b = 2,
→};
I haven't myself worked on a tabbed code base during clang-format's existence. You might want to look at Linux's settings for ideas, although they clearly differ from your preferences in other ways. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
> Let some whitespace be programmable. The layout of the input influences the layout choices in the output. This means that the choices between single-line/multi-line layouts in certain situations are made by the user, not by an algorithm. This makes the implementation simpler and leaves some control to the user while still guaranteeing that the formatted code is stylistically consistent.
Coq, Agda, etc. also don't have formatters either, partly because "user-defined layout", but also partly because their syntax is just so complicated and they have smaller ecosystems
When someone commits changes to an existing file, they auto format before committing. If existing parts of the file already contain weird non standard formatting this creates distracting whitespace noise in the pull request that could have been prevented. It's a waste of time to not use standard formatting.
The answer to dirty diffs is to not make them. Every change should be intentional, and a reviewer should agree that it's important. "Reformat this block I haphazardly edited" is fine, but don't make the change bigger for no reason.
Some dev will have 1 newline after a method ends, another dev will have two newlines, some might have 3 etc. Should you as a code reviewer be wasting time looking for such issues and putting comments tell the other to fix such issues?
You dont care about an extra blank line, what about 2 extra lines, what about three and so on. Do you see why there is a need for a consistent style?
exactly, which is why such rules should be part of the code, no need to trust if such conventions are followed if the rule will take care of it.
You should spend your time doing some meaningful not wasting it on such issues.
I've never seen that code that needed to be weirdly formatted with its own rules separate from other files in the codebase in order to make sense. That just sounds like a developer being a prima donna with their code style, not something that genuinely improves understanding and collaboration.
System.arraycopy(src, srcPos, // from
dest, destPos, len) // to
Tools also won’t know how to format a DSL well at all, which has already been a problem with Spark jobs in Scala.
If your function has too many parameters then the code probably needs refactoring.
Yes agreed about DSL in Scala. Scala is complicated. I was a Scala dev for many years. We tried to avoid the more academic and overly abstract designs with that language.