[Mono-devel-list] Patch for System.Data.Common and System.Data.ProviderBase

Atsushi Eno atsushi at ximian.com
Tue May 24 12:12:07 EDT 2005

Hi Kosta,

I don't think there is a corresponding term for this '_' matter in
our coding guideline. The absence of rule sometimes implies that
it was not ruled because it should not be ruled. Sometimes we can
infer rules from existing sources. If we haven't prefixed '_' for
fields, then that's not kind of rule in our long coding history.

It is still possible to create further rules in the future, but
for now there is another rule that should be applied here:

"If you are modifying someone else's code, try to keep the coding
style similar."
(excerpt from http://www.mono-project.com/Coding_Guidelines )

I don't think "having '_' everywhere" rule is enforceable. Some
people want to maintain field names equivalent to that of MS.NET
to enable runtime serialization interoperability.

Atsushi Eno

Konstantin Triger wrote:
> Hello Uma,
> You are absolutely right: having the same code base is very important. 
> We think exactly like you do and all this effort is made in order to 
> have the same code base. ProviderBase is the last namespace which we 
> merge. Very soon after that we will add our "private" connected mode 
> implementation into ".jvm" folders and completely switch our development 
> to SVN.
> The code styling is a very important issue. Good style just prevents 
> bugs and makes development faster and easier. Any notes about bad code 
> styling in our patches are welcome and will be fixed immediately.
> Regarding the "_" prefix, well, I think omitting it IS a very bad style. 
> Just because we already solved bugs (not in System.Data) related to 
> misuse of private fields. The fact it's not in use everywhere in mono is 
> bad in itself. We strive for better in System.Data, like Suresh said me 
> :-).
> In addition, on this occasion I would like to talk about reformatting of 
> the code. There are many places where the files are DOS styled, spaces 
> used instead of tabs etc. It just makes the maintainance more difficult, 
> IDEs driving crazy, diffs and patches not working... I think that if we 
> can make one special effort for fixing that, without changing the logic, 
> we all will benefit in the long term.
> Regards,
> Konstantin Triger

More information about the Mono-devel-list mailing list