www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Code Style

reply Robert Fraser <fraserofthenight gmail.com> writes:
Hi all,

Right now, I'm working on a code formatter for the Descent IDE
(http://www.dsource.org/projects/descent ), and I'm planning to make a (or
possibly more than one) "default" profile for code style. All this stuff will
be configurable down to the tiniest detail (if you want spaces before the comma
but not after in superclass/interface lists and after the comma but not before
everywhere else, that'll be evry possible), but having some sensible defaults
would be a good thing. 

So, what style do you code with (I know I'm not going to get a consensus, but
I'm looking for what's most popular)? You don't have to answer everything, just
give me a general idea; saying "I follow the Java conventions" or "I follow the
conventions at this link: [...] except for braces, which I always put on a
separate line" or "check out this source file: [...]" is fine. These are
"questions to get you/me thinking" ratehr than specific questions, so an
implicit "etc., etc." should be added to the end of every paragraph here.

Where do you indent and where don't you (do you indent the body of every type?
Every function? Modifier blocks? Switch statements? Switch cases? Do you
un-indent the break on a switch case?)? Do you indent with tabs or spaces (or
both?) What size tabs/how many spaces do you use?

Where do you put your opening braces (same line, the next line, or next
-line-indented?) Do you do this differently for different braces (i.e. next
line for declaration blocks but same line for statement blocks or something?)

What sort of spacing do you like to use? Do you put spaces before and/or after
commas in lists? Do you treat different comma-separated lists differently? How
about around (before and/or after) parentheses? Do you put a space before
semicolons? Before the colon in switch cases/labels?

Do you ever align your members, i.e.:
int foobar = 1;
int baz     = 1;
(It's hard to show with variable-spaced text, but you get the idea). Do you
align parameters, and put them on separate lines?

Where do you put your line breaks and empty lines? Do you like empty lines
before/after the module and import declarations? Do you put two blank lines
between every function? Do you like a blank line at the beginning of every
function? Do you put a simple (one-statement) if on one line or split it up? Do
you put new lines after closing braces for "else if", "catch"/"finally" and/or
"while" (in a do-while) statements?

How about line wrapping? Do you always wrap your lines at a specific column
(i.e. 80) and do you like to wrap at specific places (i.e. don't strand the
type from it's name in an argument list)? Do you put every parameter on a
separate line?

Again, it's all going to be configurable, but having a few sensible defaults
will probably be helpful. There won't be any comment formatting in the first
version, so don't worry about that part (they'll just be dumped as they are...
so will inline assembly).

Also, a more general question... would you ever consider actually USING a code
formatter/have used one in the past?

Thanks for your help,
All the best,
Fraser
Jun 15 2007
next sibling parent BCS <ao pathlink.com> writes:
Reply=20to=20Robert,


see=20the=20attached=20file

one=20thing=20to=20note,=20I=20try=20to=20never=20use=20tab=20after=20any=20non=20tab=20and=20if=20things=20on=20different=20lines=20are=20dsupposed=20to=20aline,=20I=20try=20to=20use=20the=20same=20number=20of=20tabs=20on=20each,=20even=20if=20it=20adds=20lots=20of=20spaces=2e
Jun 15 2007
prev sibling next sibling parent reply Clay Smith <clayasaurus gmail.com> writes:
Robert Fraser wrote:

 So, what style do you code with? 


I follow http://www.digitalmars.com/d/dstyle.html , except:

1) Indent using hardware tabs for each level indent

2) use
func()
{
}
curly brace style

3) class arguments I use (argV1, argV2) , V1_ V2_ or _V1 _V2 would also 
work for me (might switch to one of those)

function arguments I use whatever

Member align would be nice.

I usually do import decls like this

import
(tab)one,
(tab)two,
(tab)three,
(tab)four;

I also seperate these import statements by the first decl in the 
statement, like

import
(tab)one.one,
(tab)one.two;

import
(tab)two.one,
(tab)two.two;

No line wrapping.

If a function is only one line long, I like to put it all on one line

void func() { return; }

Yes, I would like to use a code formatter.
Jun 15 2007
parent reply Clay Smith <clayasaurus gmail.com> writes:
Clay Smith wrote:

 Robert Fraser wrote:

 So, what style do you code with? 


 
 I follow http://www.digitalmars.com/d/dstyle.html , except:
 
 1) Indent using hardware tabs for each level indent
 
 2) use
 func()
 {
 }
 curly brace style
 
 3) class arguments I use (argV1, argV2) , V1_ V2_ or _V1 _V2 would also 
 work for me (might switch to one of those)
 
 function arguments I use whatever
 
 Member align would be nice.
 
 I usually do import decls like this
 
 import
 (tab)one,
 (tab)two,
 (tab)three,
 (tab)four;
 
 I also seperate these import statements by the first decl in the 
 statement, like
 
 import
 (tab)one.one,
 (tab)one.two;
 
 import
 (tab)two.one,
 (tab)two.two;
 
 No line wrapping.
 
 If a function is only one line long, I like to put it all on one line
 
 void func() { return; }
 
 Yes, I would like to use a code formatter.
 
 


Oh, and I use this too: 
http://www.dsource.org/projects/arclib/wiki/CodingStyle
Jun 15 2007
parent reply Alexander Panek <a.panek brainsware.org> writes:
Clay Smith wrote:

 [...]
 Oh, and I use this too: 
 http://www.dsource.org/projects/arclib/wiki/CodingStyle


What exactly does following rule mean?


 use get/set accessors, not the property syntax


So basically one should use setProperty/getProperty instead of an 
overloaded property method? This is so un-D-ish, IMHO.

Kind regards,
Alex
Jun 15 2007
parent Clay Smith <clayasaurus gmail.com> writes:
Alexander Panek wrote:

 Clay Smith wrote:

 [...]
 Oh, and I use this too: 
 http://www.dsource.org/projects/arclib/wiki/CodingStyle


 
 What exactly does following rule mean?
 
  > use get/set accessors, not the property syntax
 
 So basically one should use setProperty/getProperty instead of an 
 overloaded property method? This is so un-D-ish, IMHO.
 
 Kind regards,
 Alex


It's more explicit for the user, to prevent bugs like

glGenTextures(1, &tex.ID)

with property syntax, you don't know if ID is a getter (crash program), 
setter (compiler error), or a variable by itself.
Jun 15 2007
prev sibling next sibling parent reply Alexander Panek <a.panek brainsware.org> writes:
Robert Fraser wrote:

 Hi all,
 [...]
 Also, a more general question... would you ever consider actually USING a code
formatter/have used one in the past?


Personally, I don't use code formatters as they tend to have only one 
set of formatting properties, which makes it a bit of a pain in the ass 
at times. The fact that Vim does not provide any (on-the-fly) code 
formatting might also be an influence..

Anyways, my formatting of code requires rather much space(s) and thus 
might not be appreciated by anyone. Though, if you'd like to take a peak 
on it, here are some files with hopefully interesting formatting :)

http://trac.brainsware.org/libodf/browser/branches/d/odf/OpenDocument.d
http://trac.brainsware.org/libodf/browser/branches/d/odf/Content.d

Basically, everything that is not contextually connected is placed in a 
new paragraph, which means:

<code>
set;
of;
instructionsContextA;
                         // teh space.
set;
of;
instructionsContextB;
</code>

A function is always written as follows:

<code>
Type functionName (T) ( T1 a, T2 b ) {
	/// code...
}

// or

Type functionName ( T1, T2 ) ( T1 a, T2 b ) {
	/// code...
}
</code>

Classes are similar to that:

<code>
class Foo (T) { // or "( T1, T2 )" as above
	Type     alignedMembers;
         TypeType alignedMemberFoos;
	T        buh;
}
</code>

..etc. Hope that helps.

Kind regards,
Alex
Jun 15 2007
parent Robert Fraser <fraserofthenight gmail.com> writes:
It will totally be configurable enough to set that style, and there will
definitely be more than one set of properties (it's based on the Eclipse
formatter, so you can set everything individually, but I'm adding some things
to make it easy to set everything at once and edit just what you want changed).

Alexander Panek Wrote:


 Robert Fraser wrote:

 Hi all,
 [...]
 Also, a more general question... would you ever consider actually USING a code
formatter/have used one in the past?


 
 Personally, I don't use code formatters as they tend to have only one 
 set of formatting properties, which makes it a bit of a pain in the ass 
 at times. The fact that Vim does not provide any (on-the-fly) code 
 formatting might also be an influence..
 
 Anyways, my formatting of code requires rather much space(s) and thus 
 might not be appreciated by anyone. Though, if you'd like to take a peak 
 on it, here are some files with hopefully interesting formatting :)
 
 http://trac.brainsware.org/libodf/browser/branches/d/odf/OpenDocument.d
 http://trac.brainsware.org/libodf/browser/branches/d/odf/Content.d
 
 Basically, everything that is not contextually connected is placed in a 
 new paragraph, which means:
 
 <code>
 set;
 of;
 instructionsContextA;
                          // teh space.
 set;
 of;
 instructionsContextB;
 </code>
 
 A function is always written as follows:
 
 <code>
 Type functionName (T) ( T1 a, T2 b ) {
 	/// code...
 }
 
 // or
 
 Type functionName ( T1, T2 ) ( T1 a, T2 b ) {
 	/// code...
 }
 </code>
 
 Classes are similar to that:
 
 <code>
 class Foo (T) { // or "( T1, T2 )" as above
 	Type     alignedMembers;
          TypeType alignedMemberFoos;
 	T        buh;
 }
 </code>
 
 ..etc. Hope that helps.
 
 Kind regards,
 Alex
Jun 15 2007
prev sibling next sibling parent reply Brad Anderson <brad dsource.org> writes:
Robert Fraser wrote:

 Hi all,
 
 Right now, I'm working on a code formatter for the Descent IDE
 (http://www.dsource.org/projects/descent ), and I'm planning to make a (or
 possibly more than one) "default" profile for code style. All this stuff
 will be configurable down to the tiniest detail (if you want spaces before
 the comma but not after in superclass/interface lists and after the comma
 but not before everywhere else, that'll be evry possible)


Awesome.

It will be possible to code in my style and then if committing to Tango, move
it over to Kris/Sean/Lars style.  I mean, that is, if they'd ever even want
the code ;)

[snip]

 
 Do you indent with tabs or
 spaces (or both?) What size tabs/how many spaces do you use?


I'm hoping all of this is configurable, including "turn tabs to spaces"

[snip]


 Also, a more general question... would you ever consider actually USING a
 code formatter/have used one in the past?


I used Jalopy a lot, until the one in Eclipse got to be "good enough" - still,
I miss it, because there were a lot more configurable options in Jalopy than
the current one in Eclipse.  Also, the author took it closed-source.  I toyed
with doing this exact project, but realized that I didn't know enough to pull
it off (way back then, maybe even now :) ).

BA
Jun 15 2007
parent Johan Granberg <lijat.meREM OVEgmail.com> writes:
Brad Anderson wrote:

 Do you indent with tabs or
 spaces (or both?) What size tabs/how many spaces do you use?


 
 I'm hoping all of this is configurable, including "turn tabs to spaces"
 


I rather have a function that turn spaces into tabs :P

joke aside, my codeing convention is as follows.

Hard limit of 80 characters per line.

Tabbs are used for indentation.

No alignment of code.

class Foo:Bar
{
        int baz(int a,int b)
        {
                switch(a)
                {
                        case 1:
                                return b;
                        case 2:
                                break;
                }
                return 0;
        }
}

Hope this helps.
Jun 15 2007
prev sibling next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:f4up7c$182q$1 digitalmars.com...

Braces on a separate line from anything else, match up vertically.  Braces 
don't match the end of the previous line's keyword or something weird like 
that (see the Tango source for details :P).
Indent inside every braced block (control statements, aggregate decls, 
function bodies etc.).
Indent cases, then indent their bodies, break on same level as body:

switch()
{
    case x:
        body;
        break;

    default:
        break;
}

Always use hard tabs set to 4.
Spaces around binary operators, no space between unary operator and operand. 
Spaces after commas, never before.  No space before colons and semicolons. 
No spaces with parens.

Almost never align declarations/initializers.  Very rarely align params in 
successive function calls, except when there are a lot of similar calls. 
Params always come on the same line as the function call, unless it starts 
getting really long (>110 chars or so), then I put a line break after a 
comma and indent one tab.  Same for all long lines, really -- the rest of 
the line is indented one tab from the beginning of the line.

Never use two blank lines, always one.  Always a blank line after a group of 
variable decls; always a blank line before a control construct.  Always a 
blank line between/after control constructs;  I'd never do something like:

if(..)
{

}
if(..)
{

}

Looks like an 'else' is missing before the second 'if' to me.


 Also, a more general question... would you ever consider actually USING a 
 code formatter/have used one in the past?


Yes, to clean up the horrible code everyone else besides me writes :D  I 
think most people would use it for that.
Jun 15 2007
prev sibling next sibling parent "Vladimir Panteleev" <thecybershadow gmail.com> writes:
On Fri, 15 Jun 2007 22:27:40 +0300, Robert Fraser <fraserofthenight gmail.com>
wrote:


 Right now, I'm working on a code formatter for the Descent IDE
(http://www.dsource.org/projects/descent ), and I'm planning to make a (or
possibly more than one) "default" profile for code style. All this stuff will
be configurable down to the tiniest detail (if you want spaces before the comma
but not after in superclass/interface lists and after the comma but not before
everywhere else, that'll be evry possible), but having some sensible defaults
would be a good thing.


Fraser, how about making your formatter attempt to detect the style from
existing code? I've seen some other code formatters do it, and if done right,
it could be a killer feature. Just feed it a file that's consistently formatted
with your style, and it would detect formatting rules from that file's existing
formatting. It would have to somehow infer rules that aren't present in the
given code - for example, if there is only one comma-separated list in the
example (say, an argument list), it would apply the same formatting to other
comma-separated lists.

-- 
Best regards,
  Vladimir                          mailto:thecybershadow gmail.com
Jun 15 2007
prev sibling next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
I used uncrustify for D.

If you are doing the code formatter as a descent plugin, please make
full functionality also available from commandline. So the code
formatter can be shared independent from the used IDE.
Jun 15 2007
parent BCS <ao pathlink.com> writes:
Reply to Frank,


 If you are doing the code formatter as a descent plugin, please make
 full functionality also available from commandline. So the code
 formatter can be shared independent from the used IDE.
 


ditto
Jun 15 2007
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Robert Fraser wrote:

 Hi all,
 
 Right now, I'm working on a code formatter for the Descent IDE
(http://www.dsource.org/projects/descent ), and I'm planning to make a (or
possibly more than one) "default" profile for code style. All this stuff will
be configurable down to the tiniest detail (if you want spaces before the comma
but not after in superclass/interface lists and after the comma but not before
everywhere else, that'll be evry possible), but having some sensible defaults
would be a good thing. 


I'd think it is better to have a couple of defaults, codeblocks for 
example does this. It's too personal anyway.

I use something like BSD style except no curly braces for single line 
scopes (if, else, foreach, ...):
http://www.prowiki.org/wiki4d/wiki.cgi?CurlyBracePlacement

If I had to pick two, I would support BSD and Stroustrup style of the 
above link, they seem to be the most common.

I've used a formatter once or twice to make someone elses code more 
readable (in my eyes), and perhaps if this thing will be so flexible I 
may use it to force some consistency upon myself.
Jun 15 2007
prev sibling next sibling parent reply Georg Wrede <georg nospam.org> writes:
Robert Fraser wrote:

 
 Right now, I'm working on a code formatter...
 
 So, what style do you code with (I know I'm not going to get a consensus...


I read the replies so far. All seemed to be reasonable and expected.


For myself, I have another wish:

I have to use two separate styles for coding. One for what I'm really 
doing, and another one for {publishing/lectures/review examples}.

((
Example, normally I'd write:

int foo(int a)
{
    return a + 2;
}

but when pressed for space (as on an overhead, or a text book), I'd write

int foo(int a) {
   return a + 2;
}

Here the difference doesn't seem grand, but imagine fifty lines of code, 
either it takes a page, or two, depending on style. More dead trees.
))

So, my wish is that you could have two separate styles stored.
Jun 15 2007
parent reply Ary Manzana <ary esperanto.org.ar> writes:
Georg Wrede escribió:

 Robert Fraser wrote:
 So, my wish is that you could have two separate styles stored.


You can. It will work exactly like the formatter in JDT. Check it there, 
in Windows -> Preferences -> Java -> Code Style -> Formatter. See you 
can create and save configurations.
Jun 15 2007
parent Georg Wrede <georg nospam.org> writes:
Ary Manzana wrote:

 Georg Wrede escribió:
 

 Robert Fraser wrote:
 So, my wish is that you could have two separate styles stored.


 
 You can. It will work exactly like the formatter in JDT. Check it there, 
 in Windows -> Preferences -> Java -> Code Style -> Formatter. See you 
 can create and save configurations.


¡Maravilloso!
Jun 16 2007
prev sibling next sibling parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Robert Fraser wrote:

 So, what style do you code with (I know I'm not going to get a consensus, but
 I'm looking for what's most popular)?


<snip>

In the style of BCS's answer, attached is a module depicting my style.


 Also, a more general question... would you ever consider actually USING a
 code formatter/have used one in the past?


I don't feel the need for one, or an IDE at all, so no.

-- 
Remove ".doesnotlike.spam" from the mail address.
Jun 16 2007
prev sibling next sibling parent doob <doobnet gmail.com> writes:
This is what I use in eclipse now for java and it's slightly modified:

/**
 * Group imports by library with a 
 * blank line between and a blank line before 
 * the next statement
 */
import lib1.foo;
import lib1.foo2;

import lib2.foo3;
import lib2.foo4;

/**
 * Indentation
 * a space before and after colon when extending or implementing
 */
class Example : Object
{
	// group variables by type with a blank line between if many and many of the
same type
	int[] myArray = [1, 2, 3, 4, 5, 6];

	int theInt = 1;
	int a;
	int b;

	char[] someString = "Hello";
	char[] str1;
	char[] str2;

	// use braces and not the colon style
	private
	{
		double aDouble = 3.0;
		double c;
		double d;
		
		// property variables ending with a underscore and then with the same name on
the functions names except the underscore
		char[] text_;
		char[] text2_;
	}

	const FOO = 0;
	const E = 1;
	const F = 2;



	 /*
	  * Properties
	  */

	 char[] text ()
	 {
	 	 return text_;
	 }

	 char[] text (char[] text)
	 {
	 	 return text_ = text;
	 }

 	 char[] text2 ()
	 {
	 	 return text2_;
	 }

	 char[] text2 (char[] text2)
	 {
	 	 return text2_ = text2;
	 }



	 /*
	  * Methods/functions
	  */

	/*
	 * A space before opening parenthesis, a space after commas,
	 */
	void foo (int a, int b, int c, int d, int e, int f)
	{
		switch (a)
		{
			case 0:
				Other.doFoo();
			break;		// break on the same indentation as the case

			default:
				Other.doBaz();
		}
	}

	void bar (List v)
	{
		for (int i = 0; i < 10; i++)
		{
			v.add(new Integer(i));		// no spaces before opening parenthesis in
function/method calls
		}
	}
}

enum MyEnum
{
	UNDEFINED (0)
	{
		void foo ()
		{
		}
	}
}

/**
 * If...else
 */
class Example
{
	void bar ()
	{
		do
		{
		} while (true);		// while on the same line as the closing brace


		/**
		 * Simple try, catch and final if possible
		 */
		try
		{
		}

		catch (Exception e)
			writefln(e.toString);

		final
		{
		}
	}

	/**
	 * Blank line after statements, simple if if possible
	 */
	void foo2 ()
	{
		if (true)
		{
			int i = 0;
			return;
		}

		if (true)
			return;

		else if (false)
			return;

		else
			return;
	}

	void foo (int state)
	{
		if (true)
			return;

		if (true)
			return;

		else if (false)
			return;

		else
			return;
	}
}

/**
 * This order in a module or class:
 * imports
 * blank line
 * class
 * variables
 * 3 blank lines
 * constructors
 * 3 blank lines
 * getters/setters/properties
 * 3 blank lines
 * functions/methods
 * 3 blank lines
 * listeners/inner classes
 * 
 * no line wrapping
 */

I have not commented every thing but the sample should give a quite clear idea
Jun 16 2007
prev sibling next sibling parent reply janderson <askme me.com> writes:
Robert Fraser wrote:

 Hi all,
 
 Right now, I'm working on a code formatter for the Descent IDE
(http://www.dsource.org/projects/descent ), and I'm planning to make a (or
possibly more than one) "default" profile for code style. All this stuff will
be configurable down to the tiniest detail (if you want spaces before the comma
but not after in superclass/interface lists and after the comma but not before
everywhere else, that'll be evry possible), but having some sensible defaults
would be a good thing. 
 
 So, what style do you code with (I know I'm not going to get a consensus, but
I'm looking for what's most popular)? You don't have to answer everything, just
give me a general idea; saying "I follow the Java conventions" or "I follow the
conventions at this link: [...] except for braces, which I always put on a
separate line" or "check out this source file: [...]" is fine. These are
"questions to get you/me thinking" ratehr than specific questions, so an
implicit "etc., etc." should be added to the end of every paragraph here.
 
 Where do you indent and where don't you (do you indent the body of every type?
Every function? Modifier blocks? Switch statements? Switch cases? Do you
un-indent the break on a switch case?)? Do you indent with tabs or spaces (or
both?) What size tabs/how many spaces do you use?
 
 Where do you put your opening braces (same line, the next line, or next
-line-indented?) Do you do this differently for different braces (i.e. next
line for declaration blocks but same line for statement blocks or something?)
 
 What sort of spacing do you like to use? Do you put spaces before and/or after
commas in lists? Do you treat different comma-separated lists differently? How
about around (before and/or after) parentheses? Do you put a space before
semicolons? Before the colon in switch cases/labels?
 
 Do you ever align your members, i.e.:
 int foobar = 1;
 int baz     = 1;
 (It's hard to show with variable-spaced text, but you get the idea). Do you
align parameters, and put them on separate lines?
 
 Where do you put your line breaks and empty lines? Do you like empty lines
before/after the module and import declarations? Do you put two blank lines
between every function? Do you like a blank line at the beginning of every
function? Do you put a simple (one-statement) if on one line or split it up? Do
you put new lines after closing braces for "else if", "catch"/"finally" and/or
"while" (in a do-while) statements?
 
 How about line wrapping? Do you always wrap your lines at a specific column
(i.e. 80) and do you like to wrap at specific places (i.e. don't strand the
type from it's name in an argument list)? Do you put every parameter on a
separate line?
 
 Again, it's all going to be configurable, but having a few sensible defaults
will probably be helpful. There won't be any comment formatting in the first
version, so don't worry about that part (they'll just be dumped as they are...
so will inline assembly).
 
 Also, a more general question... would you ever consider actually USING a code
formatter/have used one in the past?
 
 Thanks for your help,
 All the best,
 Fraser


I'm not sure this should be the default however it would be nice if you 
could alphabetize lists of methods.  Also it would be nice if you could 
sort properties by type, such that the largest types are first, for 
better alignment.

-Joel
Jun 16 2007
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"janderson" <askme me.com> wrote in message 
news:f51ll5$1hv6$1 digitalmars.com...

 Also it would be nice if you could sort properties by type, such that the 
 largest types are first, for better alignment.


This is (or at least can be) done by the compiler.  Class fields may be 
arbitrarily rearranged for optimal layout.  Struct fields, however, are 
always in the order and alignment that you specify.
Jun 16 2007
parent janderson <askme me.com> writes:
Jarrett Billingsley wrote:

 "janderson" <askme me.com> wrote in message 
 news:f51ll5$1hv6$1 digitalmars.com...

 Also it would be nice if you could sort properties by type, such that the 
 largest types are first, for better alignment.


 
 This is (or at least can be) done by the compiler.  Class fields may be 
 arbitrarily rearranged for optimal layout.  Struct fields, however, are 
 always in the order and alignment that you specify. 
 
 


The problem is, when its done by the compiler, you have problems when 
doing memory streaming operations on the data.  Of course u could always 
use a struct but then its still better if they are in the correct order.

-Joel
Jun 17 2007
prev sibling next sibling parent Knud Soerensen <4tuu4k002 sneakemail.com> writes:
It would be nice if you could specify one style to use in the editor
and one style of saving.

Else you might get problem with the version control system 
which might show more diff than it should.
Jun 17 2007
prev sibling parent reply Graham St Jack <grahams acres.com.au> writes:
Robert Fraser wrote:

 Hi all,
 
 Right now, I'm working on a code formatter for the Descent IDE
(http://www.dsource.org/projects/descent ), and I'm planning to make a (or
possibly more than one) "default" profile for code style. All this stuff will
be configurable down to the tiniest detail (if you want spaces before the comma
but not after in superclass/interface lists and after the comma but not before
everywhere else, that'll be evry possible), but having some sensible defaults
would be a good thing. 
 
 So, what style do you code with (I know I'm not going to get a consensus, but
I'm looking for what's most popular)? You don't have to answer everything, just
give me a general idea; saying "I follow the Java conventions" or "I follow the
conventions at this link: [...] except for braces, which I always put on a
separate line" or "check out this source file: [...]" is fine. These are
"questions to get you/me thinking" ratehr than specific questions, so an
implicit "etc., etc." should be added to the end of every paragraph here.
 
 Where do you indent and where don't you (do you indent the body of every type?
Every function? Modifier blocks? Switch statements? Switch cases? Do you
un-indent the break on a switch case?)? Do you indent with tabs or spaces (or
both?) What size tabs/how many spaces do you use?
 
 Where do you put your opening braces (same line, the next line, or next
-line-indented?) Do you do this differently for different braces (i.e. next
line for declaration blocks but same line for statement blocks or something?)
 
 What sort of spacing do you like to use? Do you put spaces before and/or after
commas in lists? Do you treat different comma-separated lists differently? How
about around (before and/or after) parentheses? Do you put a space before
semicolons? Before the colon in switch cases/labels?
 
 Do you ever align your members, i.e.:
 int foobar = 1;
 int baz     = 1;
 (It's hard to show with variable-spaced text, but you get the idea). Do you
align parameters, and put them on separate lines?
 
 Where do you put your line breaks and empty lines? Do you like empty lines
before/after the module and import declarations? Do you put two blank lines
between every function? Do you like a blank line at the beginning of every
function? Do you put a simple (one-statement) if on one line or split it up? Do
you put new lines after closing braces for "else if", "catch"/"finally" and/or
"while" (in a do-while) statements?
 
 How about line wrapping? Do you always wrap your lines at a specific column
(i.e. 80) and do you like to wrap at specific places (i.e. don't strand the
type from it's name in an argument list)? Do you put every parameter on a
separate line?
 
 Again, it's all going to be configurable, but having a few sensible defaults
will probably be helpful. There won't be any comment formatting in the first
version, so don't worry about that part (they'll just be dumped as they are...
so will inline assembly).
 
 Also, a more general question... would you ever consider actually USING a code
formatter/have used one in the past?
 
 Thanks for your help,
 All the best,
 Fraser


Regardless of coding style, I would like to see this available as a
utility in its own package, so anyone can use it.

The style I use is like this, with tabs converted to spaces and trailing
whitespace removed - but I aren't all that fussy. What I really want is
automatic code formatting so that I don't need to worry about formatting
at all.

void fooBar() {
    int   a; // aligned
    short b;

    if (blah) {
        a = b;
    }
    else if {
        a = 2 * b;
    }
    callStuff(long_parameter_name,
              another_long_parameter_name); // aligned
}
Jun 17 2007
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Hi, all! Thanks for your help. It looks like there's about 2 or 3 coding styles
that seem pretty popular, so I'll make a pofile for each o start with, and you
can customize it down to the smallest detail if you feel the need.

I can make it possible to execute the formatter from the command line. However,
it relies on other parts of the plugin, so I can't really make it completly
independent: you'll probably have to download JDK 1.5+, Eclipse, and Descent
and set up the options in the UI (unless you're feeling the desire to edit a
huge text file...)

The formatter itself prints everything token-by-token, so it'll only be able to
change around white space (and yes, it'll be able to change between spaces &
tabs). However, after the formatter is done, I'm going to work on a "code
clean-up" engine similar to the one in the eclipse JDT that can remove or add
curlies for single-line statements, add "in"/"const"/"final" wherever it can,
etc., etc... This requires a few other parts of the plugin, though, so it might
be a bit longer. Sorting members (either by type or alphabetically), is pretty
easy, though, so that might be the next project.

If you're interested, grab the SVN version of Descent; the formatter works (on
most code... it might throw a wierd exception once in a while; but I got it
working on all of Tango 0.98), so you can let it shred away at your code as
long as your code complies with DMD 1.007 (i.e. "inout" instead of "ref", no AA
literals (struct literals are OK, but they'll be mormatted as function calls
most liely), etc., etc.). It will pobably make it look worse, not better (esp.
switch case blocks; they still need some work), and the only part configurable
as of yet is the braces. There's no command-line version yet.

Thanks for all your help,
Fraser
Jun 17 2007
next sibling parent reply Brad Anderson <brad dsource.org> writes:
Robert Fraser wrote:

 I can make it possible to execute the formatter from the command line.
 However, it relies on other parts of the plugin, so I can't really make it
 completly independent: you'll probably have to download JDK 1.5+, Eclipse,
 and Descent and set up the options in the UI (unless you're feeling the
 desire to edit a huge text file...)


Hmmm... any chance you could write it in D, and use JNI to hook it up to
Eclipse?  That way, the command-line tool doesn't need all of the Java
toolchain.  I imagine, though that the ease of using the Java parser already
gives you too much convenience :(


Here's what I was referring to in an earlier post:
http://jalopy.sourceforge.net/

BA
Jun 18 2007
parent Robert Fraser <fraserofthenight gmail.com> writes:
Yup, I've seen Jalopy before.

Well, that _would_ have been an idea (using the JNI), but the formatter is
already about 80% done already in pure Java, so... And it uses the AST tree
Descent already generates (written in Java), so messing around with JNIifying
that doesn't sound very fun at all.

Brad Anderson Wrote:


 Robert Fraser wrote:

 I can make it possible to execute the formatter from the command line.
 However, it relies on other parts of the plugin, so I can't really make it
 completly independent: you'll probably have to download JDK 1.5+, Eclipse,
 and Descent and set up the options in the UI (unless you're feeling the
 desire to edit a huge text file...)


 
 Hmmm... any chance you could write it in D, and use JNI to hook it up to
 Eclipse?  That way, the command-line tool doesn't need all of the Java
 toolchain.  I imagine, though that the ease of using the Java parser already
 gives you too much convenience :(
 
 
 Here's what I was referring to in an earlier post:
http://jalopy.sourceforge.net/
 
 BA
Jun 18 2007
prev sibling parent Don Clugston <dac nospam.com.au> writes:
Robert Fraser wrote:

 Hi, all! Thanks for your help.
 It looks like there's about 2 or 3 coding styles that seem pretty popular,


My guess is, the primary distinction is between those who want to fit as many 
lines of code on the screen as possible, versus those who want more whitespace 
to emphasise structure. I think everything else is secondary.
Jun 19 2007