You could disable the few rules that you disagree with and create new ones that match your own coding style.
http://scottwhite.blogspot.com/2008/11/creating-custom-stylecop-rules-in-c.html _______________________________________________________ Joshua Garvin On Thu, Sep 10, 2009 at 12:18 PM, Justin Clark-Casey <[email protected]> wrote: > Melanie wrote: >> I'm really not comfortable with such a straitjacket. Those rules are >> pretty harsh, and i hate typing "this." all the time. Most of our >> code follows most of the sensible rules most of the time, the >> nonsensical ones, like this.instanceVar, I don't think we need. >> Also, Microsoft Corporation really should not dictate coding style. >> >> +1 for discussion on style >> >> -1 on StyleCop. > > I have to agree with Melanie here. I personally quite strongly prefer the use > of m_ and constant use of "this." seems pretty ugly (though I believe Python > may > do this?). > > I think our code mostly follows the Microsoft rules but I like the room for a > bit of individual variation where it isn't disruptive. So I'm not a big fan > of > automatic stylers. > > I also don't think documentation rules would really help much - I think our > problem is a lack of documentation rather than its formatting. > >> >> Melanie >> >> >> Sean Dague wrote: >>> Stefan Andersson wrote: >>>> One of the biggest impacts on code is the transition from "m_" to explicit >>>> "this." and that commenting, regions and line break formatting is strictly >>>> governed. >>>> >>>> >>>> >>>> As you all know, I've been a proponent of "m_" but that's something I'm >>>> ready to lay aside to achieve consistent code style. I also know that there >>>> is reflecting code depending on the "m_" naming, but those projects can be >>>> excluded until we can get a fix for that. >>>> >>>> >>>> >>>> As StyleCop is implemented as a Visual Studio plug-in I guess code cleanup >>>> will have to be a voluntary effort by the Visual Studio developers. This >>>> proposal is more about embracing the StyleCop code style in itself. >>> +1 to conforming style here, honestly any set of consistant rules is >>> better than non consistancy, and if a tool from the windows side of the >>> house can keep us honest, more power to it. >>> >>> I personally never liked the m_ anyway, so it going to more explicit >>> nature would be fine with me. >>> >>> -Sean >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected] >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > -- > justincc > Justin Clark-Casey > http://justincc.org > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
