5

Many teams (such as Google have rules how code should look, including how indentation should be done, how many spaces, in which order should includes be included, etc.

Some of those thing can't be automated away. Fine. But a few definitely can.

All (major) IDEs nowadays support reformatting code.

Why doesn't Google just write a script that upon git commit or git push, it re-formated to Google's main standard, and let everyone program how they want.

For example, some like two space intents, some like tabs and others like four space. Make the standard "two", (so if you work in vi you're stuck) but why can't individual developers change their private layout indents to 6 if they want?

Charles Shiller
  • 305
  • 2
  • 4
  • 12
    I think a better question would be "Why would you ever write code in a team that *didn't* adopt a coding style?" If you're unfazed by that, then "Why would you ever go to work in shorts and shower shoes, unless that's the prevailing dress code?" – Robert Harvey Mar 03 '16 at 03:12
  • 6
    [Why coding style matters](https://www.smashingmagazine.com/2012/10/why-coding-style-matters/) – Robert Harvey Mar 03 '16 at 03:15
  • Auto-format on checkin doesn't help with merges or unformatting on checkout. – Telastyn Mar 03 '16 at 03:38
  • 2
    ... or the guy who wraps his lines to 80 and then the next one wraps to 120 and the next to 160.. and I've *never* seen an auto-formatter that doesn't mess those up (pull the chain of .foo().bar().qux() onto one line? or leave them on separate lines? or have two on the first and one on the second....) its a mess. –  Mar 03 '16 at 03:42
  • 1
    @MichaelT: Resharper isn't too bad in that regard. – Robert Harvey Mar 03 '16 at 03:42
  • 1
    The only way I'd ever argue against a code-style policy is if it's a crappy one. – Alternatex Mar 03 '16 at 08:01
  • 1
    @Alternatex +1.. trouble is they're all crappy ones as nearly all are written by style nazis more interested in minutiae than useful collaborative aspects! – gbjbaanb Mar 03 '16 at 10:36
  • If you look at the Google style guides, most of them deal with "how to name things", "what features should you use", "how should you structure your code into files", ... and a very small amount involve actual "put these spaces, use this indentation, braces go here..." – Vatine Mar 03 '16 at 12:30
  • 1
    @MichaelT - The only code formatting rule about which I feel strongly is the 80 characters per line rule (or 79 in python). This rule is to make the code human-readable. My eyes lose track of the next line on reading code in which lines are overly long. Code in which lines are 160+ characters is completely unreadable to me. – David Hammen Mar 03 '16 at 13:04
  • 3
    Not sure why people are voting to close this as "opinion based". This is a reasonable question, and it has a concrete, non-opinion-based answer. Example of opinion-based: "what is a good coding style?". Example of NON-opinion-based: "why can't arbitrary coding styles be enforced by an automated tool?" (this one has a technical answer!). – Andres F. Mar 03 '16 at 13:57
  • This was an influence on both Go (gofmt imposes a style and is near-universally used) and Python (semantic indentation). – pjc50 Mar 07 '16 at 14:16

3 Answers3

7

Easy, because a style guide (not styling guide)covers much more then indention of 2 or 4 spaces.

Take for instance the google-code java styleguide.

Yes, there's a few paragraphs about indentation but much more ground is covered.

Pieter B
  • 12,867
  • 1
  • 40
  • 65
  • 2
    +1 To elaborate, style guides are more than merely formatting. Formatting can be handled by a tool (we do this at my office). However, there are additional recommendations, such as naming, clarity, which language constructs to favor, etc, that cannot be automatically enforced. – Andres F. Mar 03 '16 at 13:55
4

Why doesn't Google just write a script that upon git commit or git push, it re-formated to Google's main standard, and let everyone program how they want.

Because no matter how good a reformatter is, it ultimately is a dumb, automated tool with no hear, no intelligence, and no creativity behind it. The end result when applying a formatter to a project with no coding styles whatsoever looks just awful.

Another problem is that reformatting oftentimes introduces artificial changes in the CM repository. Suppose you made one small change to one line of a 1000 line long file. Suppose you also reformatted from 2 character indent to 8 character indent, while keeping with an 80 character line limit. Finding which line you changed is no small task. git blame will say you changed every single line in the file.

Indentation style in a sense is "small stuff", and one of the first style guide rules should be the rule "Don't sweat the small stuff". This rule applies to style guide authors and to programmers. Style guide authors should not make rules that do sweat the small stuff; people will bristle against those rules and ignore them. (Most coding style guides are chock-full of rules that sweat the small stuff.)

With regard to programmers, those programmers who have to reformat code to their personal style in order to understand the code are not good programmers. A good programmer should be able to read, understand, and modify code that is consistently formatted to some reasonable style, and do without having to change indentation, braces, etc.

My rules have been simple on the occasions when I've been king of the hill and was able to write the standards for a project: Consistency across modules, with indentation style and amount chosen from a reasonable set of options.

David Hammen
  • 8,194
  • 28
  • 37
2

I think the issue is really about the quality of style guides. There was a famous C++ one that was hundred pages long - a joke of trivia and minutiae that would never help teamwork. I've seen a complex style guide that had all kinds of rules in it, totally unhelpful (except when the guy who wrote the guide failed to follow his own rules... that was fun).

But these kind of guides are useful to a point: code should at least try to look the same so there's no weird and wonderful styles someone introduces because they feel like it (I've seen all sorts of function calls, brackets here and there, indents 2 spaces, 3 spaces, tabs etc). This lack of a style makes reading code difficult. Try it sometime - next time you add a change to your code, choose a different indent width. I guarantee you won't be able to track code blocks after just 2 or 3 changes.

Personally I think style guides should be "do it how the code currently looks like" so there's no need for the petty restrictions and allows for readable exceptions to the rule (as will always be present)

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172