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.

There's a middle ground though.

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.

It makes sense to me that each team decides their coding standard.

5 or 20 engineers who work in the same code base should have some more or less formal standards for that code.

I can see both sides. I hate it when code is all over the place, different files indented in different ways, no consistency on bracket placement, etc. But then again, I just hate it when rules grow so strict you can't ever break them. For example when line like this in strictly-pep8-compiliant codebase:

    return "some very long string"

is exactly 81 characters long. I'd much rather place some "# ignore this" comment on it than break a line there, forcing a "\" after return.

Genuine question: Do people still adhere to 80 character limits for lines? I expected that everyone would have relaxed those with all the extra resolution we have. I use 100 at work.

I often switch between working on my desktop and my laptop. keeping to a limit of about 80 characters makes it easier when working on the laptop. And as others have said, I often split screens when working on my desktop as well, so it helps there too.

I also find that very long lines can be a code smell - deeply nested callbacks or a case of 'divitis' in html markup.

When working with html, I find it convenient to put attributes on separate lines if there are more than a couple of short ones. This naturally helps keep line length down. Having them on separate lines helps with editing a bit too.

I like using split panes in my editor: When I'm not at my desk, I can just fit two 80 character panes in. When I'm at my desk I can fit three!

I don't follow it religiously, but I try and fit everything into 80 characters where possible (my editor has an indicator for the 80-character mark).

For me the big win with 80 is that I can easily do a side-by-side diff in my IDE without needing to expand the diff window at the expense of the outline, package, and other views. And horizontal scrolling in a diff view sucks. A lot.

Agreed, also I like to have a portrait monitor for code and browser, can see more without scrolling, so 80 helps.

I keep a ruler at 80char but treat it as a soft limit. It seems to work okay, functionally its probably about the same as a 100char limit but there's something psychologically better about being able to break the limit and not worry about it.

Yes. Some almost religiously.

Every sane linter has //NOLINT support.

Yes. But not every code reviewer has a //NONITPICK option.

I hear you. E.g. - I find go-format to be vile. I remember "non New Jersey" languages from back in the 80s, and find K&R syntax / format worship sickening.

Yes, leave an existing file in its existing layout. No, don't get your shorts in a twisty if both double quotes and single quotes are used in places when the language treats them EXACTLY the same (i.e. - no value interpolation).

Don't force me to copy Java idioms (UGHHHHH!) in an otherwise functional programming language. I don't care about how to use "this" (other than to read somebody else's crap OOP code); I'm using variables in closures that happen to be bundled into an "object". I'm using currying for "dependency injection", rather than writing crap classes with one "do it" method for 90% of instances of "class". (alas, I do most of my work in Java, and only a little JavaScript, which is why the java-isms in JS upset me so much -- Java clowns, GO AWAY!!!)

This is an unfocused rant, I apologize, but I hear your complaint about mandated arbitrary stupidity. I don't know why you got downvoted. People didn't just not agree, you offended them. Go figure.

At 472 commits my guess is it's truly a "guide" rather than a rulebook and a living, changing one at that!

It looks like airbnb does a good job updating theirs, but I can sympathize with the parent comment. I've found coding style guides that end up obtuse, easily outdated, and arbitrarily fit to the preferences of it's creators. They often stagnate and are blindly followed just for the sake of following. A lot of the best practices in the document are things that should be screened for at the hiring stage, and many of the others are heavily debatable preferences that are only going to make a developer with an opposing opinion feel needlessly boxed.

Not that they are a bad thing and airbnb's looks really solid to me, but writing a coding style guide means you now need to maintain and curate it periodically – a process that is easy to neglect.

Give it time...