5

UPDATE: an issue would arise from stuff that is not strictly defined by a formatter, like consecutive empty lines etc., that would get lost in the process (local to server to local reformatting) which would annoy people (me as well :)

I'm used to adopting some shared code formatter so my question is not about "should I submit to that?"

I wonder does this (code formatting) have to matter at all? Isn't it possible to have your repository store your commmits in some "default" formatting? You would never get to see what that style looks like, because every time you checkout all the sources get saved to your HDD after getting reformatted using YOUR formatter. Also every time you would browse the repository your client would show you the source reformatted using YOUR formatter. Also all diffs would be done after reformatting using YOUR formatter.

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

Jaroslav Záruba
  • 159
  • 3

3 Answers3

4

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.

Community
  • 1
scriptin
  • 4,432
  • 21
  • 32
  • I was trying to make it clear that my question is not about removing those rules, just making it possible to keep your own without colliding with other team members' rules. Therefore there would be no "every book having its own formatting". – Jaroslav Záruba Nov 02 '14 at 09:54
  • 1
    "*Can you imagine each book having completely different formatting?*"- I can imagine a book that has a standard formatting when it is in the bookshelf (=repo), another one when you read/write it and yet another one when I read/write it. Can't you? Formatting is only a way to *represent* the code on screen/printout. The only thing the compiler is interested in is syntactically valid code, nothing else. We humans are interested in formatting, but even then you'll find that different people have different preferences. That's a feature I'm looking for in modern IDEs for years now. – JensG Nov 02 '14 at 10:34
  • 1
    "*... storing a program not as source code, but AST*" - Good, finally we're heading in the right direction. Anything that can be found in coding standards with regard to formatting is only a crutch that would no longer be needed once everyone gets his own view of the code without affecting anyone else. – JensG Nov 02 '14 at 10:40
  • I edited my answer to make my point clear. @JensG you cannot have your own w/o affecting anyone else. You still have to share your code not only through a repo, but with copy-pasting. And you still have to teach juniors by writing on a whiteboard. And there's much more. – scriptin Nov 02 '14 at 11:35
  • 2
    Sure. But nobody is going to tell me how code looks in *my* editor. For teaching/whiteboarding, people will have to read my code, and I theirs. Don't think that's a big problem. But at their own desk they can do whatever they want, and so do I. Wouldn't that be cool? – JensG Nov 02 '14 at 11:50
  • No. You'd have to read their code written in their language, and they'd have to read your code written in your language. That ain't cool, that's just more time to understand other's work. Again, conventions are compromise (and in compromise there are no 100% winners, everyone sacrifice something), but they give you simpler communication. I've seen guys using *no indentation in their code* whatsoever! I don't want to learn from them or read their code at their desks, even it's totally fine in a repo. – scriptin Nov 02 '14 at 12:03
  • 1
    I agree with @scriptin. Not to mention pair programming, which is sometimes used not only as a learning tool for new-joiners, but as a full part of a team's development technique. – Patrice Gahide Nov 02 '14 at 12:25
  • 2
    "*You'd have to read their code written in their language*" - Remember, I talk only about formatting here. Nothing else. – JensG Nov 02 '14 at 18:28
  • 1
    @JensG I didn't say it isn't going to work. Blockly is a proof that it actually works, but it is a language from a niche where it is advantageous to have some level of such customization, e.g. you can [translate blocks into another (natural) language](https://translatewiki.net/wiki/Translating:Blockly). Most other programming languages are not from that niche. Sorry if my disagreement disappoints you. I remember that you speak only about formatting (see update 2). – scriptin Nov 02 '14 at 20:22
4

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.

Maarten Winkels
  • 336
  • 1
  • 3
3

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.

Nemanja Boric
  • 464
  • 6
  • 15
  • 2
    As explained, no whitespace changes would get committed, whitespace would get taken care of by default server formatter. Before a diff is made both files would get reformatted by your viewing tool. – Jaroslav Záruba Nov 02 '14 at 09:42