[Muine] Proposal to Adopt MCS Coding Style.



The coding-style used by MCS (Mono C# Compiler) and Gtk# differs from
the coding-style used by Muine. I propose to adopt that coding-style
(available at http://svn.myrealbox.com/source/trunk/mcs/CodingStyle).

This coding-style change would only apply to portions of Muine written
in C# and would not be adopted on a wide-scale until the release of
Muine 0.8.0.

Your comments are greatly appreciated.

Major differences:

* 8-space tabs (current: tab characters)

Using 8-space tabs makes the code look more consistent on different
systems. Currently, aligning code requires the use of both tabs and
spaces which are visually indistinguishable. If we could use only tabs
to align things, this wouldn't be a problem but it requires both.

Read more: http://c2.com/cgi/wiki?TabsVersusSpaces

* Camel-casing for variables (current: underscores)

The Microsoft standard for variable names is camel-case
(variableNamesLikeThis). C-style underscore naming looks awkward in a
C# context.

* Condensed properties (current: always expanded)

Single-lines for very short property gets and sets would be allowed.

public int Number {
        get { return num; }
        set { num = value; }
}

* On<event> naming scheme for Event Handlers (current: Handle<event>)

The Gtk# standard for event handler naming is On<event>. If the widget
is not current class then On<widget><event> is used, these should not
be public. If you feel it should be public, consider splitting the
widget off into its own class.

* I<descriptor> naming scheme for Interfaces (current: <noun>Interface)

Muine just added SongInterface and PlayerInterface as part of
PluginLib. According to the MS guidelines, these should be named ISong
and IPlayer.

The "descriptor" could be a descriptive noun, noun phrase, or adjective.

Read more: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconinterfacenamingguidelines.asp

* C++-style comments (current: mainly C-style)

C-style comments ("/* ... */") look rather awkward in C++ and C#
settings. C++-style comments ("// ...") would be cleaner.

This does not apply to code commented out (e.g. because it does not
work correctly yet) where C-style comments are very useful for
commenting out a large chunk of code at once and are preferable to
"#if 0 .. #endif" constructs because comments are more likely to be
colorized in color editors. Also, using C++-style comments would help
this because C-style comments cannot be nested.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]