[Mono-list] Class Library coding standards

[John Barnette]

> > Strongly agree.  The benefits of having all the code in a repository
> > *formatted* in a certain way (as opposed to consistent variable naming
> > conventions, etc.) definitely exist, though.
>
> What are the advantages? I think that we're all adaptable enough
> to be able
> to read and understand code regardless of where we put our curly braces.

I'm inclined to withdraw my previous statement; my job requires a lot of
process-oriented hoops like consistent code formatting due to clients
looking over our shoulders, and I think that it's been too deeply ingrained
in me. ;-)

I *would* like to note, though, that the idea of parsing and emulating a
potentially different indentation and spacing style for potentially every
Mono file I edit makes me very unhappy; I know from previous personal
experience that I would be happier with an artificially imposed standard
than having to cater to 30 different people's versious of the OTBS.

And I, for one, *do* have trouble quickly adjusting from one spacing and
indentation style to another when reading; call me limited.

> > An approach I've used with great success before is linking a source code
> > beautifier to CVS commits.  That way, any time a source file is
> > added to the
> > repository, it's formatted consistently.
>
> This might be neat but wouldn't it make any commit you make
> instantly out of
> date and in need of merging the very next time you want to check in?

Yup.  Once again, while this worked for me on several projects, I don't know
if it's appropriate here.  I used it to indoctrinate a group of developers
into a consistent 'writing' style; not only did they see the style every
time they updated a file, but breaking the style (or not running a
beautifier before checkin) gave them a personal pain in the ass. ;-)

I admit it, I'm a sadistic manager. (grin)


~ j.