I feel like squeezing out every possible place for people to be creative and express themselves creates a pretty boring environment. Like, imagine if all buildings were just purely functional. They'd all be the same grey box shaped things. I recently worked on a codebase that was lovingly developed by a single maintainer and had all kinds of weird and wonderful quirks that made me smile every so often. I'm a pretty serious person most of the time but I'm not going to lie it made my day that little bit more interesting.

Io (http://iolanguage.org) can work this way, as the message tree (maybe including comments - I don't recall) is what the interpreter used to evaluate the code and is accessible at runtime. However, it didn't store the choice of terminator (newline vs return) or indentation info (though it would be easy to add), so the pretty print of the message tree might look different depending on the source conventions.

This article is barely a comment on some other situation; but I've been saying this to anyone who wants listen for years.

There's nothing special about whitespace (unless you write python).

Capitalization and a bunch of other stuff in your coding convention document are usually just signs that you have poor tooling and lack of skill.

Give me a PR that satisfies the requirements and the appropriate test cases and i'll happily rewrite it to spaces only indented with curly braces on newlines and etc... as I see fit.

The hard part is the first two tasks, you can train an intern to do the third

The main selling point for source code in plain text files is compatibility. You can use whatever tool you wish. Yes, it's not ideal, and yes, we are still using non-semantic diffs in these days, even though it should have been a solved problem by now. I'd still argue that even if all the editing/VCS tools start working in a structured way, the storage format should be plain text.

A small point on formatting that I'm getting increasingly firm about as I "age" (still not that old): Formatting is very important, but if you find yourself complaining about what a formatter does to your code, the code be bad (obviously making an exception for a big block of constants or something)

e.g. if the formatter is really shifting stuff around, your code might be too nested - if you have a compiler, let it take the strain.

> you could view the source however you wanted. Spaces vs. tabs didn't matter because neither affects the semantics and the editor on the system let you modify the program tree directly (known today as projectional editing).

But formatting still doesn't matter. Outside of whitespace-dependent languages, formatting is a subjective thing -- it's a people concern, not a computer concern. I can store my JavaScript as AST if I want to.

  <span>foo</span>

  <span>
    foo
  </span>

Lua is especially annoying - even after years of using it I just can't really decide how to format it for better readability. lua-fmt sometimes works, often it makes it even worse. I welcomed Fennel in my Lua setups mainly because of this.

In Javascript there is Prettier which auto-formats the code on saving: https://prettier.io/ So essentially you stop caring about adding new lines or tabs, just press save and the code gets indented/formatted correctly.

Code layout is important, even though it - much like naming - doesn't impact functionality.

I can write code that (IMHO) is substantially better than any formatter. But I've realized that there is no way to make other people on a team have the same opinions and skill as me, so I accept automatic code formatters.

I have gotten into discussions with people about linters and code formatting standards in general and I always liken it to a work desk. If my company decided that every work desk had to be 100% generic and that every day if I put any adjustment, even to the seat height, on that desk they would reset it, I would probably think that place was hostile. Even if I could 'auto format' it back to something close every time I stepped up to the desk I would be pretty unhappy. It just wouldn't feel like mine and eventually I would be beaten into whatever style, which wasn't my own, the code came out of the repo as. Basically, linters are evil. They only work for the person that set them up.

Leave code format up to the primary owner of the file. It is pretty rare that code has more than one person that does 95% of the edits on a file so let them own the formatting. In the rare case where there are shared files with shared edits then it is ok to mandate some sort of enforced format but those are so rare that it generally isn't worth discussing. The proposed approach here ignores all the messy non-standard stuff that happens because of the margins or the rules that are very hard to build in when codifying personal coding style.

Let me have my messy desk and I'll let you have yours.