> Use only spaces, and indent 2 spaces at a time.
These conflict in the C++ guide (as well as shell). As I’ve aged, 2-spaced code doesn’t provide the necessary contrast for me to easily read & scan code, but rather than picking a larger number or using tabs so users can configure the value, a low, hard-to-read number was chosen.
I myself have always used 4 spaces for C++ codebases. Spaces provide fixed width and consistency, regardless of the code editor. Tab proponents say that the power of tabs is that they can be configured. Thing is, I don't want to configure them everywhere I go, and I change stations a lot. Think also of code viewers: non-logged in GitHub defaults to a 8-spaces tab width, which is enormous and code becomes too wide to read without horizontal scroll in a non-ultrawide screen.
Also, people are clumsy. I'd wish this was not the case, but that's the world we live in, and people (I'd even say MOST people) are clumsy as hell and will somehow mix spaces with tabs.
Long live the glorious and sweet dictatorship of opinionated, unconfigurable code formatters. Whether they impose 2 spaces, 4 spaces, or tabs, I don't care. Code getting automatically formatted in a consistent style across all teams and contributors, that's bliss.
(I myself actually believe that tabs for indentation + spaces for alignment would be the best of both worlds, but never tried to enforce it in my projects)
I only can use it on personal projects, as most places I worked in use spaces.
The limit on what constitutes a reasonable line length is a bit subjective but I'd say that well written code rarely goes above ~120 or so. Depends a bit on the language, some just have more boilerplate than others. But instead of making that a hard limit I'd warn above that number so actual people can decide if it makes sense there or if a rewrite is in order. Auto-formatting is great and all, but ultimately a human should have the last decision.
Though if you force me to pick a value, then it's 4 because that's the sanest choice for like 95-99.9% of all people.
Use tabs and allow people to pick their own spacing
Also good for accessibility
> New projects should use that unmodified public Python Google style guide (4 space indent with methods_with_underscores). Historically, we adopted a style that was congruent with Google internal Python style guide (2 spaces with MethodsAsCamelCase).
https://chromium.googlesource.com/chromiumos/docs/+/HEAD/sty...
Why are we still having this meaningless discussion in 2023? Adding this functionality to editors shouldn't be that difficult and we can end this discourse.
For everything else, I indent twice, but I have a habit to compress double-indentation in my source code into a single character code by pressing the Tab key only once.
I pose this question sincerely, as I'm over 40 and still prefer 2-space tabs myself.
On the other hand, when the style rules also impose a very short maximum code line length, e.g. of 80 characters, then I agree that in such cases 2-space indenting is a superior choice, because the slight decrease in readability is compensated by a greater increase in readability due to a much less frequent need to break long lines.
When I write for myself, I prefer 4-space indenting, but together with a greater maximum line length.