The problem is...

it is expensive for a company to format code manually, but it is also expensive not to format code at all.

Summary from ThoughWorks Tech Radar

For as long as we can remember, what style to use for formatting code has been a matter of personal taste, company policy and heated debate. Finally, the industry appears to be tiring of this endless argument and teams are freeing up surprisingly large amounts of time by forgoing these discussions and just adopting opinionated and automated code formatting tools. Even if you don't agree 100% with the opinions of the various tools, the benefits of focusing on what your code does rather than how it looks is something most teams should be able to get behind. Prettier has been getting our vote for JavaScript, but similar tools, such as Black for Python, are available for many other languages and are increasingly being built-in as we see with Golang and Elixir. The key here is not to spend hours discussing which rules to enforce, but instead pick a tool that is opinionated, minimally configurable and automated — ideally as a pre-commit hook. Quoted from (https://www.thoughtworks.com/radar/techniques/opinionated-and-automated-code-formatting)

Bits

Community Content

• https://www.reddit.com/r/AskProgramming/comments/eojat4/do_you_format_your_code_manually_or_use/
• https://www.thoughtworks.com/radar/techniques/opinionated-and-automated-code-formatting
• https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=prettier gofmt&sort=byPopularity&type=comment

There are Bigger Fish to Fry (Business Value).

• Conversations about formatting really waste time and is cyclical.
• Formatting code takes energy without adding value for customers.
• Formatting code takes energy away from adding new features and/or fixing bugs.

Messiness Decreases Readability (Individual Productivity).

• A laissez-faire approach to formatting makes it difficult to scan code quickly.
• A diff against two files with different formatting produces a lot of noise.

Conflict is Inevitable (Team Cohesion)

• No two developers have exactly the same code formatting preferences.
• Objective criteria do not exist for choosing "the best" code formatting style.
• Team cohesion is at risk of decreasing whenever code formatting presents a productivity obstacle.

Manual Formatting is a Drag (Team Cohesion)

• Manually formatting code can be a chore.
• Even for those who like to format code, manually formatting it to someone else's standards tends to be demoralizing and can build resentment.

Changing Formats is Difficult (Team Cohesion)

• Language format trends change over time; for instance, the style of 2005 for C# is not the same as it is now in 2021.
• If the team decides to follow modern conventions, overhauling the code base is a manual process.

Differences in Format is Noise (Individual Productivity)

• Changes to code formatting in a pull request obscure meaningful changes.
• Containing code formatting is separate commits adds overhead.
• Switching between code formatting styles in a code base decreases readability.

Possible Actions

What style guide to use?

1. Take a laissez-faire approach to formatting - there is no style guide.
2. Create an internal style guide.
3. Adopt an external style guide and tweak it to suite team preferences.
4. Adopt an external style guide and make it immutable.

How to adhere to the style?

1. Take a laissez-faire approach to enforcement - it is a guideline only.
2. Use code review to point out differences from the style guide.
3. Use a linting tool / code analysis tool to point out differences.
4. Use a automated code formatting tool to catch and automatically fix differences.

Pros and Cons

What style guide to use?

	Benefit	Cost / Risk
Laissez-Faire	Avoid manual code formatting. Avoid confrontations about preferences in code formatting.	Conflicts go unresolved as the team avoids confrontation. Lack of consistent formatting decreases readability. Automated code formatting is not possible.
Internal Style Guide	Initial sense of encouragement as the team devises standards.	Conflicts around style resolve through democratic process, top-down dictatorship, or most effective complainer. The sheer number of formatting rules makes democratic process and/or consensus building extremely time consuming. A company that was in the business of building a SaaS product is now in the business of creating and curating a style guide. Automated code formatting is not possible without building an internal code cleanup tool.
External Style Guide with Tweaks	There will be consensus among the team about most of the external style-guides rules. Automated code formatting is possible if the tweaks are within the external style guides options.	About 10% of the external style-guides rules will offend the aesthetic sense of some of the team. Resolving conflict about that 10% of the style guide faces the same challenges, on a different scale, as we found in the Internal Style Guide approach. Automated code formatting is not possible if the tweaks are not within the external style guides options.
External Style Guide without Tweaks	No internal debate about individual stylistic choices. Over time, the team gets used to the new style. Some initial detractors start to prefer it. Automated code formatting is possible.	The external guide will offend at least some aesthetic sensibilities of most developers over the long-term. Few members of the team are totally stoked about the new style.

How to adhere to the style?

	Benefit	Cost / Risk
Laissez-Faire	Avoid work on code formatting	The problems of inconsistent code formatting go unresolved.
Code Review	Over time, the team might produce a consistently formatted code base. Those who do not care about code formatting can choose not to raise the topic in code review.	Reviewers who care about code formatting will run into conflict with developers who do not care about code formatting. Code review time that could be used to find faults in logic is taken up by finding faults in style adherence.
Linting Tool	Over time, the team might produce a consistently formatted code base.	The team still needs to format code manually. A linting tool is available only for supported, external style guides.
Cleanup Tool in IDE	More developer time/energy is spent on developing features and fixing bugs. The team does not have to spend any time reviewing code for style or manually formatting code to fit a standard.	Developers need to remember to run the code formatter before pushing to a remote repository. Running the code formatter involves opening each project the IDE.
Cleanup Tool on Command Line	More developer time/energy is spent on developing features and fixing bugs. The team does not have to spend any time reviewing code for style or manually formatting code to fit a standard. The tool can become part of an automated toolchain. For instance, the formatting can happen before push to the trunk.	Running the tool requires installation of software. Some team members might not like the set of styles that the cleanup tool supports. Running the automated code formatter takes time, and that time increases as the number of files to format increases.

Our Choice Is...

Naturally, the choice is entirely up to your team.

If you do decide on automated code formatting, here are some consideration for how exactly you might do it.

How exactly?

Here is how to use a cleanup tool on the command line for a microservice architecture in .NET Framework / .NET Core. We're going to demonstrate the ReSharper command line tool.

Install the ReSharper Command Line Tools

choco install resharper-clt.portable --pre -y

Run Cleanup Code on a Single File

cleanupcode Path\To\Some\File.cs

Usually I run the above from a solution directory or a project directory.

View the Help for the Tool

cleanupcode --help

After reading that help, savvy developers can figure out many use cases.

Run the Cleanup on an Entire Project

cleanupcode .\Api.v2.csproj --include="*/**/*.cs"

Run the Cleanup on an Entire Solution

cleanupcode .\Api.v2.sln --include="*/**/*.cs"

Run the Cleanup Tool on Every C#.NET File in the Company

Get-ChildItem *.sln -Recurse | ForEach-Object { ... }

Maintain the Standard over Time

For IDE users, install the Visual Studio extension.

For command line users, add the cleanup tool as a Git hook that formats only changed files. Using git diff --name-only --diff-filter=AM helps.