Nope! There isn’t.

The coding style you use is a preference.

Even if studies have backed your preference1, it does not matter. The next team you work on or codebase you inherit may not follow that preference. But if they have implemented a consistent style, use it. If you are open to using it, and force yourself to code that way2, you will start to think in that style quickly. Your old preference will start to stick out in code you read because your brain has recategorized what is “normal”.
Consistency is the only thing that matters. Having a consistent style is better than not having one. Enforcing it is better than that. And automating enforcement so no one has to think about it is best of all.

One of the best ideas I’ve seen in a language is gofmt. That command is the code formatter shipped with the Go programming language. How convenient is that? They made the choices for you so you don’t have to waste time. You can do what matters: focus on what you’re trying to build.

In all likelihood, your language community is not in agreement about what a “good” coding style is. I know nothing about the Go community but I’d bet money there are things gofmt does not do that the community has discussed endlessly. What does that mean? It means community is a baseline, but everyone is just making a choice. You should also make a choice, automate it as much as possible, and move on.

Each language community will usually have one ormore style guides. Those will include consistency things (like code formatting) but they also include things like code quality.

Code quality, or code styles that aim to reduce developer error or confusion, are still preferences. But they at least merit thought before making a decision. Automate away aesthetic preferences because they don’t impact how the code actually works, and they’re (in general) safe to automatically apply. Then automate detection of code quality.

Some code qualities that could be worth detecting are cyclomatic complexity (number of branches in a method), file/class/module size, code duplication and use of immutability. You’ll find that most languages have code quality tools called linters/static code analysis software which can raise warnings for you automatically.

Once you’ve locked in your preferences:

  • Your aesthetic decisions should be applied on save of a file
  • Code quality red flags (that again, you decided on) can be raised as you’re saving code
  • You can write/review code and know that as many small decisions as you could remove have been removed
  • Congratulations! You can focus on the purpose of the code and free up mental effort from the minutia! 3


If you’re not sure what to choose for your standards:

  1. Start with the community. See if there is a popular source for styles (style guides). The larger the community, the more of them there will be. In those cases go for most popular, but any will suffice.
  2. Utilize tooling to enforce your decisions. Prettier and ESLint are a good choice in the Javascript world. Rubocop and Standard are good options for Ruby. Every popular language has something, so search for linters and static code analysis tools.
  3. Generally follow community and language idioms. While consistency is paramount, having a style totally inconsistent with your programming language community might turn off potential collaborators or hires.
  4. If you decide to do something different, codify it in your linting rules (in a tool like ESLint) or if it can’t be codified, document your decision. Then immediately stop worrying about it.


Still having trouble deciding on some common, contentious style decisions? I can help.

  1. snake_case vs camelCase? Both animals can be dangerous in their own way. See which animal the community has bet on (I suppose Python boxed themselves into snake_case with the name) and use that. Keep anti-venom nearby for snakes and a spit shield nearby for camels. Be happy you aren’t using 🦛case.
  2. Tabs vs spaces? Burn some sage. Make sure the room you’re in is free of any negative energy. Breathe deeply. Count to ten slowly. Realize this decision is not important. Still struggling? Maybe you’ll feel better coding in Whitespace.
  3. Single quotes vs double quotes? If you’re in Javascript, why not backticks? If you’re in Kotlin, a single quote is a character and a double quote is a string, so you can’t decide, it decided for you (rascally devil). Consult your MLA guide for more information4

  1. yes, there are studies done on things like how quickly people can comprehend certain code conventions. Xah Lee references some of them here ↩︎

  2. I think forcing yourself to code in a new style when things change is always a good idea in general. Don’t lean on what you know, lean into what you don’t know. If your language or framework of choice adds new conventions/methods and you use that new version, try thinking that way instead of the old way (particularly if the old way is deprecated, or becomes very uncommon). Holding onto your preferred approach in software when things change is like trying to capture a stream with your bare hands ↩︎

  3. seem like overkill? It might be if you’re working alone. But from my own experience working on dozens of freelance applications as a solo developer I can confidently say, even with your own style/preferences, you’ll write some code outside of your own style and quality standards and totally miss it. Getting a linter hooked into your code editor is pretty straight forward now, and frameworks like blitzjs build in linting tools from the start! ↩︎

  4. don’t, I’m joking, the answer is it doesn’t matter just choose one ↩︎