The alternative is that every coder has their own style and over time every file becomes random and wildly inconsistent. That doesn't sound good to me either.
On my team, the long-standing rule is that you need to make a best effort to stick to the module's existing style. So we're not gonna bust your balls because you don't split at exactly 100 characters or whatever... but if you never wrap your lines and if you insist on indenting things completely differently than everyone else then yeah, you're creating a problem.
It also helps that our "style guide" is pretty minimal. Brace conventions, indentation, spaces before conditions, etc. Things that have a serious impact on readability and ease of debugging and that can easily be auto-formatted. What we don't specify is the higher order stuff -- provided you are internally consistent. We don't mind if API A uses one naming scheme and API B uses another, provided that we don't have a mix of different ones in the same API. Same for how something like object extension is handled. This falls into the realm of "we assume our developers will make the best technical choice", but so far it works.
There's always a complaint that specifying the braces, spacing, etc. is stupid, and if it required a lot of human intervention or was treated as a serious offense I'd agree. For us it doesn't, and it's not. The purpose is to limit the amount of visual friction when switching from one file to another. What the code is doing is the important part -- presentation should be as uniform as possible to limit distraction. Add in the fact that we've got an Eclipse profile with all the spacing, etc. setup the way that we do it, and it's pretty easy to keep things tidy.
On my team, the long-standing rule is that you need to make a best effort to stick to the module's existing style. So we're not gonna bust your balls because you don't split at exactly 100 characters or whatever... but if you never wrap your lines and if you insist on indenting things completely differently than everyone else then yeah, you're creating a problem.
It also helps that our "style guide" is pretty minimal. Brace conventions, indentation, spaces before conditions, etc. Things that have a serious impact on readability and ease of debugging and that can easily be auto-formatted. What we don't specify is the higher order stuff -- provided you are internally consistent. We don't mind if API A uses one naming scheme and API B uses another, provided that we don't have a mix of different ones in the same API. Same for how something like object extension is handled. This falls into the realm of "we assume our developers will make the best technical choice", but so far it works.
There's always a complaint that specifying the braces, spacing, etc. is stupid, and if it required a lot of human intervention or was treated as a serious offense I'd agree. For us it doesn't, and it's not. The purpose is to limit the amount of visual friction when switching from one file to another. What the code is doing is the important part -- presentation should be as uniform as possible to limit distraction. Add in the fact that we've got an Eclipse profile with all the spacing, etc. setup the way that we do it, and it's pretty easy to keep things tidy.