On Fri, 13 Aug 2010, Blue Swirl wrote: > On Thu, Aug 12, 2010 at 6:56 PM, malc <av1...@comtv.ru> wrote: > > On Thu, 12 Aug 2010, Blue Swirl wrote: > > > >> Add a few rules, based loosely on libvirt HACKING. > >> > >> Blue Swirl (5): > >> CODING_STYLE: add preprocessor rules > >> CODING_STYLE: add C type rules > >> CODING_STYLE: add memory management rules > >> CODING_STYLE: add string management rules > >> CODING_STYLE: add rules for printf-like functions > >> > >> CODING_STYLE | 111 > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> 1 files changed, 111 insertions(+), 0 deletions(-) > > > > While intentions of this are good, i believe this goes too far, i doubt > > that the proposed additions are enforcable and have no doubts that they > > will be widely ignored and at the same time provide more grounds for > > whining. > > Then, either we add some kind of enforcement or we downgrade the rules > to recommendations or guidelines.
I'm fine with the latter. > > > Furthermore the existing code doesn't follow them, going out on > > a limb, it's more likely that one would look around the code he/she > > modifies and base his/her modifications on the surrounding code than to > > follow the style that conflicts with it. > > I'll try to remove the new stuff. > > On the other hand, it should be possible to introduce new rules in > general. We can explicitly state that old code does not follow this > rule, but patches to fix the problems are appreciated and immediately > applied. > > This also applies to the unfortunate situation with the braces rule, > which is constantly broken. -- mailto:av1...@comtv.ru
