That's just, like, your opinion, maaaaan. Granted there's a pretty broad spectrum of kinds of projects and kinds of collaboration. But even in the broadest mo

That's just, like, your opinion, maaaaan. Granted there's a pretty broad spectrum of kinds of projects and kinds of collaboration. But even in the broadest most open of collaborations, fundamentally there are aesthetic, stylistic and design decisions being made about API structure and the usability of a code base's constructs (which is what is so frustrating about watching new communities of new programmers coalesce w/o the benefit of hindsight from previous cultures/systems). It's just a hop, skip and a jump from those higher level domain concerns down to actual coding style. Also, buildings and bridges are creative and artistic endeavors. Edit: To be a little less flippant about it, the broader point is that writing code is always a stylistic endeavor. You can agree with your colleagues or friends explicitly on style conventions, or you can roll with organically created conventions. But to say that you can write code devoid of design decisions and stylistic choices is foolish (again, all buildings and bridges are designed objects, and sure there are best practices for how concrete is poured, but to declare that construction has no craftsmanship is incorrect). Beyond that, the utility of forcing others to adhere to your style is one that should be more rigorously considered. My vast preference is to ensure that large engineering structures are constructed of compact and well factored components with sane/intuitive APIs, regardless of what their internal stylistic choices are w/r/t formatting. Having a global style guide across multiple projects might be nice, but it also might be stymieing in terms of iterating towards better practices.