Having no rules is not freedom, it’s just chaos. How would one write a book on programming language without any coding standards? Can you imagine each book having completely different formatting?

I have personal preferences about how the code should look like, but my personality is not really important when I work in a team. Collaboration is important, and coding standards make it possible, not just easier.

Is this possible to do? (E.g. client plugins, repository configuration, etc.)

Yes, but with worse performance, bugs, and additional setup phase. I have enough of configuration and plugins thanks to Maven, so I better stick with good old discipline.

However, there is an idea about storing a program not as it’s source code, but as it’s syntax tree. Like language-agnostic ASTs and stuff.

Update: On comments.

I see and understand your point, but I still believe my concerns are true.

Imagine you have those magic plugins which abstract away the formatting. You team up and code with other people without knowing about their preferences, and it’s all double rainbow all across the sky =)

Then, one of your colleagues tells you something like: “I’m writing a book about programming, need your help.” Then she sends you a manuscript and you see she’s gone completely opposite direction with not only formatting, but even with concrete syntax. Imagine she invented something like CoffeeScript on top of the language you both use: keywords are different, shorter syntax constructs, etc. It’s totally possible when you have such a magic plugin and people will do it (because of Murthy’s law, and it ain’t no joke).

So, you can’t help her, unless you both reject your personal preferences and use “standard”, “default” formatting and concrete syntax. Ta-a-da-a!

So I claim:

1. If there are N people and each one is allowed to have his/her own concrete syntax and formatting styles, there eventually be N different styles.
2. If there are people using those different styles, they would either write books using those different styles, or agree on using “default”.
3. If you end up using “default” anyway to be able to collaborate, why bother with customization?

I’m not insisting on “purity” or something. I work with code which often has a mix of different formatting styles. But that’s mostly just slight differences which don’t affect the language. I’m totally fine with that.

But I don’t want to learn a new language just to feed someone’s ego (my own too, for that matter). I sometimes just copy-paste code in my instant messenger and I don’t want to have any plugin in it (on both mine and recipient sides, I’ll have you know) to send a snippet.

If you have such a magic plugin in your IDE, you have to have such plugins everywhere you want to stick you code to. That’s nothing more than additional problems.

Summary: you can do so, but you shouldn’t. Standards are better when customization. Conventions are better than plugins.

Update 2:

Image person A prefers to put an opening brace on a separate line:

while (true) // endless loop
{

Then this code can be stores in some kind of syntax tree and then shown to person B, who uses Egyptian style. That can be done either like so:

while (true) /* endless loop */ {

or so:

// endless loop
while (true) {

And this second one has different order of tokens.

This shows that not all syntax constructs would fit in this model. So the language should be probably restricted in many ways to provide ability to customize formatting. Still I think it is possible, since there are programming languages like Google’s Blockly which have completely different concrete and “stored” syntaxes.

By the way, Blockly is a proof of concept, since you totally can customize the frontend to fit your artistic taste.

Technically, the main problem I see is with line numbers and debugging.
If you reformat the code, code might end-up on different lines, making it much harder to make sense of stacktraces and such. Also referring to code in general would be much harder, if your colleagues see different lines than you.

In context of collaboration, I think recognizability of the code is important. If I look at the same code on the screen of a colleague, it would be much harder to collaborate if I don’t easily recognize the code.

There’s an excellent tool uncrustify that takes a description of the source code formatting from a config file and outputs a formatted file as per specification in config file. However, there’s a few problems with this approach, most obvious and important are:

1. File stored in the repository will be different than view of your file making looking into diffs much harder.

2. It will be much harder for you to keep whitespace changes separated from the important commits.

I’m sure there’s more.