[Mono-devel-list] mono style guidelines

[Ben Maurer]

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 () {}



>>> "Andreas Nahr" <ClassDevelopment at A-SoftTech.com> 03/04/04 11:50 AM >>>
Hi,

I wanted to mono-style some of the classes. However our current style guidelines are not really verbose on some topics, so some Style questions:

* What about the bracket style for Classes/ Namespaces? I would suggest:

namespace System
{
 [Serializable]
 public class ApplicationException : Exception
 {
  // Constructors
  public ApplicationException ()
   : base (Locale.GetText ("An application exception has occurred."))
  {
  }

because I think it is the most readable way, however some classes also use:

namespace System {
 [Serializable]
 public class ApplicationException : Exception {
  // Constructors
  public ApplicationException ()
   : base (Locale.GetText ("An application exception has occurred."))
  {
  }



* Comments about what kind of content follows (like the // Constructors above):
 Do we want to keep that? Put that in everywhere or leave as it is.
 What to do for new classes?



* Linebreaks: Should we do any linebreaks and if, at which column?
 Currently some classes do linebreaks, some do none at all and some do linebreaks sometimes.
 I would suggest not doing linebreaks unless a line gets terribly long (maybe more than 120 or 150 chars?)
 80 chars seems just about impossible if we suggest using 8-space-tabs. The general code already starts
 at charpos 32!


* How to break lines?

public int RegSetValueEx (IntPtr keybase, string valuename, IntPtr reserved,
 int type, ref int data, int datalength)

public int RegSetValueEx (IntPtr keybase, string valuename, IntPtr reserved,
                          int type, ref int data, int datalength)

The current mono style guidlines suggest the first option, however I've also seen the second one.
For the second one it has to be ensured that spacing is done by spaces and to by tabs, because this
will break appearance for people not using 8-space tabs.



* File-Ends: I would suggest files should end with exactly one empty line



* Another general suggestion: We should try to avoid having spaces at the end of lines or having spaces
 in empty lines



* Should Error messages (or msgs in general) generally end with an "."? They sometimes do, sometimes don't.



* What does an empty constructor/ method look like?:
public Foo ()
{
 DoSomething();
}

public Foo ()
{
}

public Foo () {}

public Foo ()
{}

I would suggest the first one because it is consistent with the rest. However I've also seen all three in mono.









Another general thing that I came up with is localization:
Currently we use Locale.GetText (string theText). This delivers (or should deliver) the localized version of the theText string.
Localized will probably mean: In the locale of the current user, right?

However what happenes in the following case:
Think about a multilanguage application. Every user gets (e.g. UI) - Resources in her language. However if an error occurs
the application will catch that and output it to a file, so that an administrator or developer can look at it later.
Effect would now be that this file contains localized!! messages in whatever languages. The poor admin might not even
be able to read all those languages.
So I would suggest to add an overload like Locale.GetText (string theText, bool systemLocale)
to add the option to suggest to mono that this message should be displayed in system locale and not in user locale. You could
even make this modifyable at runtime to determine if this should also display user locale (in a completely standalone scenario.)

Especially in the context of web - development this seems to make a lot of sense.
Candidates for systemLocale strings are especially the Exception error messages