When starting a new project, one of the first questions that arise are: “Which Code Style do I use?”. Depending on the team/company size and personal preferences this question could lead to a lot of discussion.
The style could be different for each project, but at least in the project the style should be the same for each developer.
I think this question is one of the most discussed question on the internet and among developers. Some prefer spaces; some prefer tabs.
The arguments for both of the styles are very wild and sometimes not even reasonable.
In my opinion the answer depends on the use case:
Beyond this, another important question is: How many Spaces/Tabs should be used.
For better code readability, I recommend 2 or 4 spaces. If using tabs, there is usually an option to define the tab size. If only one tab is used per indentation level, it should be set to 2 or 4 spaces, depending on personal and team preferences, so that the indentation “remains the same.” However, using multiple tabs (e.g., 2 tabs per indentation level) could be redundant if the overall style enforces a maximum width of 2 spaces per indentation, since this would effectively mean 1 tab = 1 space.
Also mixing spaces and tabs should be prevented at all costs, as it will make formatting and reading code in different IDEs very hard. Further some languages, for example Python does not support mixing Spaces and Tabs.
Python also answers the question themself, if spaces or tabs should be used:
Spaces are the preferred indentation method. Tabs should be used solely to remain consistent with code that is already indented with tabs. Python disallows mixing tabs and spaces for indentation.https://peps.python.org/pep-0008/#tabs-or-spaces
In my opinion 4 Spaces should be used for Indention.
Beyond the tabs vs. spaces debate, there are other aspects worth considering, though I won’t go into them in detail here.
For a long time, 80 characters per line was the standard in code styles. This was primarily due to monitor size limitations and the ability to compare files side by side, such as during code reviews.
Python also provides a recommendation:
Limit all lines to a maximum of 79 characters. For flowing long blocks of text with fewer structural restrictions (docstrings or comments), the line length should be limited to 72 characters. Limiting the required editor window width makes it possible to have several files open side by side, and works well when using code review tools that present the two versions in adjacent columns.https://peps.python.org/pep-0008/#maximum-line-length
With the increase in monitor size, longer lines are more manageable. Personally, I prefer a 100-character line limit. Inline comparisons in modern code review tools reduce the need for strict width limits. If side-by-side file comparison is still necessary, a simple workaround is to reduce the font size slightly.
As I am primarily a Java developer, I look for dedicated Java code styles. I use IntelliJ IDEA for my daily work, and several code styles can be used:
Many large tech companies, such as Google and Twitter, have defined their own internal code styles for their developers.
The most commonly used IDEs for Java development are Eclipse and IntelliJ, and most code styles can be imported into either. However, there are limitations when using the built-in code style features.
For example in IntelliJ IDEA not all code conventions can be specified and applied that are desired. Because of this Google has created a Eclipse/IntelliJ Plugin: google-java-format. The Plugin is open source and also can be used as standalone: https://github.com/google/google-java-format
Using the plugin over intellij-java-google-style.xml has some pros and cons.
Pros:
Cons:
For me the pros are much better than the cons and with IntelliJ it is possible to define Required Plugins, as well as sharing the project setup via version control: https://intellij-support.jetbrains.com/hc/en-us/articles/206544839. Also instructions needs to be given either way. Install the plugin or install the code style if the project setup is not shared.
The most important step in coding is: applying the code style and other rules.
Even the best code style conventions are useless if they are not consistently applied.
IntelliJ IDEA allows defining actions that should be executed before committing code. One such action is “Reformat Code”, which ensures that all committed code adheres to the project’s style. Additionally, “Optimize Imports” should be selected to remove unused import statements, as this can trigger SonarQube analyses or other static code analysis tools.
Other actions depend on user preferences.
Also there are several Gradle and Maven Plugins (google-java-format can also be used with Maven and Gradle) to perform code formatting, for example in CI or as Git Commit Hook.
I use IntelliJ and decided to use the google-java-format plugin to enforce the style, as I experienced some issues with using the IntelliJ standard formatter, like not idempotent formatting or not fully supporting all convention features. Maybe this are some Issues I have experienced, but they lead for me to use the plugin.
Everyone is free to use the style they can work with best, but in a team there shouldn’t exists multiple different code styles and therefore sometimes compromises have to be made.
