I started with IntelliJ a long time ago when I was learning Java in 2001 or some such, and it helped me write better code. IntelliJ has a code formatter, and other good tools (e.g. copyright, line endings, trim whitespace, and so on) and we used it — my team agreed on some standards and set our editors the same way as there is little in the world more annoying than having one person who doesn’t get it and made me troll a diff looking for something that had no changes.
I know, I am old, and all the cool kids use vim or Sublime and say my old Java-based editor is slow and expensive (it is not slow if you have it set up correctly, and it is free now). The coolest part is the code inspector, which subtly highlights little imperfections, instantly points out syntax errors, and often finds simpler ways to express the same idea. I have avoided thousands of errors simply by its built-in spell checker. There really is value in just finding a standard (a broad standard) and following it.
In all the teams I have worked with, we set a few rules that forced people to converge on our practices.
- When you find a file saved with the wrong encoding, or line endings, or is formatted differently than the team has decided, the first commit is a reformat-only (which is a single command in a good editor). Now you don’t have to troll through white-space diffs
- We do pull requests, and agree that a PR is instantly rejected when someone finds things like indent, typo, and other stuff like that. In short, we shame people into paying attention. I cannot tell you how many bugs are caught by the simple act of knowing that someone is going to look at your code and publicly shame you for something stupid. For all of the test frameworks, code linters, and other tools, the single best way of finding bugs in your code is to read it. So many developers fail to take this simple step, especially junior developers who think getting something done quickly is the most important skill.
It’s remarkable how quickly developers start writing better code when they know it’s going to be reviewed (every time). And I promise you, having tried every single other way of doing code reviews that are painful, horrible, demoralizing, inefficient and generally useless, pull requests are a magic, mythical beast. I have done them now (via GitHub in my case) since 2010 in 4 different companies. Miraculous.