2

we have here at work a very strange coding convention, and I didn't managed to setup the Java Formatter in Eclipse right to do what I want. The convention says:

  • Before a curly brace "{" there should always be a new Line

[UPDATE] There is no rule in our convention saying, if after a "{" should be a line break or not. The examples actually use a line break (and almost ANY convention I saw so far says or implies that after a "{" and a "}" should always be a line break). So sample 1 and 2 are both "syntactically correct". [/UPDATE]

As this blows the code, our team have decided to write code like this (no, this wasn't my choice!):

public void methode(final boolean b)
{ if (b)
  { do.something();
  }
  else
  { do.somethingElse();
  }
}

But in the formatter I only managed to get this:

public void methode(final boolean b)
{
  if (b)
  { 
    do.something();
  }
  else
  { 
    do.somethingElse();
  }
}

or this:

public void methode(final boolean b) { 
  if (b) { 
    do.something();
  }
  else {
    do.somethingElse();
  }
}

Is there a way to tell the formatter to break lines before a "{" but not after that? I know the first style is awful, and I would be pleased to use one of the last two, but this is a company decision.

Asturio
  • 525
  • 7
  • 21
  • 11
    Maybe a baseball bat could solve the problem? Nope? No, ok, violence is not the solution, but the code style you've chosen is an abomination. **If** compact code is the motivation, then leaving out braces around single-statement blocks *might* be the better solution. – Joachim Sauer May 04 '11 at 13:39
  • 6
    Ouch :( I feel for you man! – Mark Pope May 04 '11 at 13:40
  • 1
    I do not know how to make any code formatter format code like this. In all of my experience, I have never seen code formatted this way. Putting the curly-brace on the same line as the first line of code inside the function makes it difficult to use copy-cut-paste functions to move around lines of code. It's really a bad decision, and should be changed. Sorry I don't have an answer. – Erick Robertson May 04 '11 at 13:43
  • On a more serious note: I'd suggest you don't try to bend the rules. Even if you follow the letter of the rule, you won't have the advantages that a unified code style brings (and they are plenty!). Swallow your pride and follow the coding convention. Your second sample might not be the most space-saving one, but at least it's consistent and doesn't look like some newlines where swallowed. – Joachim Sauer May 04 '11 at 13:43
  • @Joachim: His team decided on the first one. The second and third are disallowed by their team. Personally, I think I'd fire any team that made this decision. It's royally asinine. – Erick Robertson May 04 '11 at 13:48
  • @Erik: my understanding was that the bullet item is company standard and the first option is what "the team" decided to make of that company standard. So while the first item is not up for discussion, the latter might be (smaller circle of decision makes, higher chance of success). So I would bring back the argument "the style we've chosen is so abstruse that no sane code formatting tool supports it" to overthrow the decision.# – Joachim Sauer May 04 '11 at 13:49
  • Actually the second sample is the decision of the company. But the team decided for the first (as both are "allowed" by the coding convention). I'd be really fine with the second one, but our team want to stick with the first one. The baseball bat solution seems to be the best one :_) . @Joachim: I'll try to argument on that point. – Asturio May 04 '11 at 13:52
  • 3
    @Asturio: If the second sample is the decision of the company, then why is the first one allowed? This seems odd to me. Your team shouldn't have changed it -- especially to something so asinine. Make sure that you have expressed your dissent to your team. If your team leader doesn't accept it, go over his head. Whatever you do, don't actually write code like this! – Erick Robertson May 04 '11 at 14:11
  • 1
    I would not upvote any answer that actually suggests a way of trying to accomplish this abomination. You should make sure your team members reads your question here and the opinions of others. – Robin May 04 '11 at 15:56
  • @Robin: Agreed. No upvote for answers (even if I mark the only one as a possible solution). Is that ok? – Asturio May 04 '11 at 20:45

2 Answers2

2

So, here an Information about this Topic. I have done some more research. The here so abominated Brace-Style (sample 1) has a name: The Horstman Brace Style or here Horstman. There is a small group of people defending it, as it combines the advantages from the K&R and the Allman (sample 2) Style. As the braces are lined up, and there is no "waste" of space.

But this is not the only true. This style miserable for the VCS. If you need to add a Line between the opening brace and the first statement, you need first to break the line, and put your new line there. In the diff or merge you will see then not "one line been added", but "one line been exchanged by two lines". But the actually old statement was changed by you.

So another argument, not to use this style.

Asturio
  • 525
  • 7
  • 21
0

Could you turn off the relevant parts of the code formatter and make use of the Templates instead. For example when typing 

private_

and hitting ctrl+space would invoke the private_method template. You could then modify the private template to be something like this -

private ${return_type} ${name}(${}) 
{ ${cursor}
}

You'd have to do similar things to the other block statements and you'd have to modify your coding style to start using the templates more often, but I reckon it could work.

spot35
  • 878
  • 4
  • 9
  • 1
    OK, I'll try this one, but this is just a small help, I think, as every block is meant, every for, while, do, switch, else, static and instance methods, constructors and so on. Should be formatted this way. Probably the best choice is to talk with my boss, an convincing him and other co-workers in changing the convention (or following it better). – Asturio May 04 '11 at 20:39