CodingConventionsBracePlacement.Imported @ jos.sf.net

I'm going to letter them for sanity's sake...BK

A) Here's a (fairly) silly one to get the ball rolling:

class Curmudgeon {
	  int iErrors;
	  }

or B)

class Curmudgeon
	  {
	  int iErrors;
	  }

Which is preferable?

I'll add a third option: C)

class Curmudgeon {
	  int iErrors;
}

-ChrisSmith

Moved here Nov 9, 1997 by ChrisSmith

Back to CodingConventionsQuestions

My favorite one is: D)

class Foobar
{
	 int iBla;

	 public static void main( String args[] )
	 {
		  return;
	 }
}

MarkusPeter

I'd suggest a slight change, to reduce line count: E)

class Foobar
{	int iBla;

	 public static void main( String args[] )
	 {	return;
	 }
}

--BillRehm

I'm in favour of Bill's (above). -BenKnowles

As long as the { and } are in the same column I am happy. - ClarkEvans

The problem with D) is high line count, the problem with E) is that code editors don't support the style very well in practice. IMHO, these styles exist because many people don't tab new blocks in their code for readability. If people simply tab their code and make sure to leave a space between the header and the '{', then that makes C) very readable. C) is also the standard from JavaSoft if that makes any difference to anyone.

http://java.sun.com:81/docs/codeconv/html/CodeConventionsTOC.doc.html

-- AveryRegier

In at least one sense, it doesn't really matter whether code editors support E. A prettyprinter is a fairly trivial app, which I'll gladly write once we've decided on a format. FWIW, __I've__ never had any problems with text editors using style E, but you might have guessed that since I suggested it. -- BillRehm

I regularly program using D). C) is typical of c|c++ code. I don't suggest making a holy war over where the braces/whitespaces and everything else are placed. Perhaps the prettyprinter as a front end on a Java file text editor might be a useful tool to have. I will add a SourceCodeTools section to main. Then we can start filling it in. It's at least a start. --MichaelFried

Another vote for the PrettyPrinter. But for myself I prefer (D), though I take it further; not only do I vertical-format braces, but when there's any complexity I do the same with parentheses. This is truly beneficial in understanding complex expressions and scanning function signatures.

The idea is that, to scan code rapidly, line count is less relevant than contrast. Whether that's true probably depends on how many lines you can comfortably accomodate on your screen and in your brain, which in turn depends on eyesight, fatigue, short term memory, and other human factors. I've got 20/15 eyes and edit in 80 line windows so I don't give a toss for conserving lines. To pick operators and terminators out of a (C) style format is, for me, a great deal more trouble than any line-conservation is worth.

Historically I trace (D) to the wonderful early 80's Tim Long AUUG C formatting standard, but you'll also see (D) in the most popular C++ standard, the Ellemtel standard, and in HenricsonAndNyquist's latest and greatest, the superb IndustrialStrengthC++. (C) and (A) derive from wretched typesetting in the otherwise mind-blowingly good old KernighanAndRitchie C reference book.

Given that our ilk spend half our waking lives staring at sourcecode, I agree with Bill, a PrettyPrinter is the way to go here. Interfaces should adapt to users, not the other way round. -- PeterMerel.

For What It's Worth: the evolved NASA C/C++ standard is (D).

[To elaborate on PeterMerel above] Personally, I feel that with a PrettyPrinter to justify all JOS Official code to any standard is good enough - it can always be adjusted later with any other PrettyPrinter. And each coder can whatever style what most asthetically pleases her, even if ObfuscatedCode is your CupOfJava :)

--MattAlbrecht 11-JUL-1998

Personally I like (C)... and I have never heard anything really convincing for one style or another... So, C i will use. As for a convention for official style... I leave it to who ever is maintaing the repository. I can always reformat in any way I like, when I have to work on somehitng... The Formatter I use in conjunction with Kawa, is astyle...

Artistic Style http://www.bigfoot.com/~davidsont/astyle
Kawa http://tek-tools.com/kawa/

Here is an except from the docs on astyle:

-b OR --brackets=break Break brackets from their pre-block statements ( i.e. ANSI C, C++ style ).

if (isFoo)
{
	bar();
}
else
{
	anotherBar();
}

-a OR --brackets=attach Attach brackets to their pre-block statements ( i.e. Java , K&R style ).

if (isFoo){
	bar();
} else {
	anotherBar();
}

-- BrillPappin 16-JAN-1999

I think pretty printers are the answer too however I think this page is for voting and I go for D. I don't think saving lines is at all important at the expense of readability. If its too tall - print it out. I have a sneeky suspicion that C evolved historically out of coders using vi on Unix but I've no proof of that. To me the '{' introduces a new stack frame and therfore is a statement like any other and should have its own line.

{
	 // statement...
}

is legal code and if the block has a control element associated with it then I would place the controle element in line with the top brace aka:

if(blah blah blah...) // controll element of new stack frame
{
	 // statement...
}

It seems sensible to me that the beginning '{' and end '}' of a stack frame are vertically aligned. And that everything from within the frame is indented (pictorialising moving down the stack).

Well that's my 2 penneth...

-- GarethBuxton 19-Apr-2000

Content of these pages are owned and copyrighted by the poster.
Hosted by: