[Mono-devel-list] mono style guidelines

[Ben Maurer]

VS.net indenting is not very flexible. It is either all or nothing wrt hanging. I think they are fixing this in whidby, with a new set of options.

I dont undersand the ecma style, it actually seems to be worse than `miggy style' (aka, only do next line on method/.ctor).

Really, it is not that big of a problem. Unless a piece of code has such bad style that it is dificult to maintain, lets not bother fixing it.

I would *MUCH* rather have a new piece of code, a bug fix, a perf boost than a file which is beautified.

This reminds me alot of lawns --
Some people beautify their lawn to perfection. So much so, that they dare not walk on the lawn at the risk of bending a blade of grass out of the perfection which they shaped it to.

Likewise, some people format their code so much that another person dare not patch it at the risk of disturbing the style.

Code is not poetry, it is now a lawn. It is a functional object. When style can be a component of function (eg, if you need to format the code because it absolutely cant be read due to its uglyness), that is a good area to fix. When style takes from function, stay clear.

-- Ben

>>> Fawad Halim <fawad at fawad.net> 03/04/04 12:31 PM >>>
The ECMA docs seem to use

class Foo
{
    public int Bar() {
    }
}

but most of the C# code done on VS.NET has

class Foo
{
    public int Bar()
    {
    }
}

because VS.NET defaults to that.

Would it make sense to do a GNU indent profile for mono-style?

-fawad

Ben Maurer wrote:

>I think the most endorsed style is:
>
>namespace T {
>     class Foo {
>          public void Blah ()
>          {
>              if (foo) {
>              }
>          }
>          public int Bar {
>              get { return 1; }
>          }
>     }
>}
>
>The *ONLY* place where teh brace goes on the next line is for a method/.ctor
>
>I don't think //constructors above should be used. If you really need something, use #region.
>
>Linebreaks should be at the writer's discression. In general, they should not be done at column x, but rather at a point where it increases readibility.
>
>File-ends is a trivial issue, i dont care :-).
>
>Avoiding spaces at the end of a non-empty line is a good thing. For ws only lines, either way should be fine.
>
>Error messages is a trivial problem.
>
>Empty ctors should not exist if they are not needed (remember there is a default public ctor). Otherwise, i would suggest
>public T () {}
>
<SNIP />