> are objectively less error-prone than alternatives. "Brace around > single statement" would have been the perfect example, except that I > already fixed it with http://review.gluster.org/#/c/8813/. Thus, > developers could be faced with page after page of style errors because > they *copied the style of surrounding code*. Also, these errors could checkpatch.pl is not really a tool to use for proof of correctness, it is a sort of enforcing to make coding consistent - what exists today in the codebase is due to the factor that we never had a conformant guideline and even if it did it wasn't enforced. In-fact we choose to be *Linux* style without having a guideline for much of GlusterFS history but at the same time on many occasions we weren't conformant and i don't know of any hard standard which was followed too for the last 8 years that i have been - it was largely word of mouth or a good practice. So choosing 'checkpatch.pl' from *Linux* is a valid tool, now if few things don't work for us then fix checkpatch.pl - it isn't a irrefutable file :-). The reason to have that in codebase is as the project gets bigger which is the case of GlusterFS it is better to have conformance with some guidelines. - New changes coming in should adhere to that. - Old changes if they are there and let them be. - If modified and checkpatch complains then fix it. Rejection happens way before you could even submit a patch, its sole reason is to not waste everyone's time giving "-1" for "no tabs, no whitespace, no this style" If its too much of a hassle then get rid of it, as i said nothing is irrefutable. -- Religious confuse piety with mere ritual, the virtuous confuse regulation with outcomes _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
