[Mono-devel-list] REPOST: Mono class layout

Jonathan Pryor jonpryor at vt.edu
Wed Nov 12 07:32:44 EST 2003


Here's a stab at an explanation...

Most of the brace format is the "one true brace format" -- K&R style.

	void ThisIsKAndRStyle()
	{
		if (true) {
		} else {
		}
	}

Of course, this then gets modified for readability -- I usually put
"else" on a newline, resulting in:

	if (true) {
	}
	else {
	}

There's actually "benefits" to this approach over "MS" style:

	if (true)
	{
	}
	else
	{
	}

The "benefits" are in "Code Complete" (which I've sadly lost, so I can't
directly quote it), but the basic gist is that the first style allows
you to get a better feel for the code flow structure at a glance, as the
begin & end scopes are at the same indentation level.  This is opposed
to the "MS" style which adds an extra line of "noise".

An alternate style (which I've also used, but less frequently) is
drastically different, but really makes an outline view of the code
easy:

	if (true)
		{
		}
	else
		{
		}

Suffice it to say, NO code should use this in CVS. :-)  But it does make
it easy to see control flow.

I can't explain why functions generally have braces start on a newline,
though.  I'd think the same logic would apply.  But functions are
generally fewer than control-flow statements, so this doesn't bother me.

Now, do people have this memorized?  Some do, I'm sure, but most don't. 
Which is why the code in CVS is not entirely consistent, as not everyone
(a) read the guidelines, or (b) remembered them.

I can't remember if Monostyle corrects this.  I'm not actually aware of
anyone who uses it, since we generally avoid CVS commits that just
change code formatting (as this deteriorates CVS history, as you have
"cosmetic" changes intermixed with "real" changes).  Just like we try to
keep line-endings the same, even if CVS has DOS line-endings -- we don't
want to lose history if we can avoid it.

 - Jon

On Tue, 2003-11-11 at 15:31, Hayes, Dennis wrote:
> /Rant on
> Does anyone have so much spare time that they would like to explain why
> sometimes the bracket goes on the same line and other times it goes on the
> next line.
> I know this comes from another "standard" (Java?).
> Do people have this memorized? Do they look it up every time they use a
> brace? Does Monostyle correct this? Do people just put all their braces one
> way or the other and ignore this (like me - my bad)? 
> /Rant off
> Thanks,
> Dennis
> 
> -----Original Message-----
> From: Miguel de Icaza [mailto:miguel at ximian.com] 
> Sent: Tuesday, November 11, 2003 1:03 PM
> To: mono-devel-list at ximian.com
> 
> 		* Inside a code block, put the opening brace on the same
> line
> 	  	  as the statement:
> 
> 			good:
> 				if (a) {
> 					code ();
> 					code ();
> 				}
> 
> 			bad:
> 				if (a) 
> 				{
> 					code ();
> 					code ();
> 				}
> 
> 		* When defining a method, use the C style for brace
> placement, 
> 		  that means, use a new line for the brace, like this:
> 
> 			good:
> 				void Method ()
> 				{
> 				}
> 
> 			bad:
> 				void Method () {
> 				}
> 
> 		* Properties and indexers are an exception, keep the
> 		  brace on the same line as the property declaration.
> 		  Rationale: this makes it visually
> 		  simple to distinguish them.
> 
> 			good:
> 				int Property {
> 					get {
> 						return value;
> 					}
> 				}
> 
> 			bad:
> 				int Property 
> 				{
> 					get {
> 						return value;
> 					}
> 				}
> 
> 		  Notice how the accessor "get" also keeps its brace on the
> same
> 		  line.
> 
> 		  For very small properties, you can compress things:
> 
> 			ok:
> 				int Property {
> 					get { return value; }
> 					set { x = value; }
> 				}
> 
> 		* Use white space in expressions liberally, except in the
> presence
> 		  of parenthesis:
> 
> 			good:
> 
> 				if (a + 5 > method (blah () + 4))
> 
> 			bad:
> 				if (a+5>method(blah()+4))
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list




More information about the Mono-devel-list mailing list