<snip> > > > > > > I often see people writing posts to this list stating that they are want to get started and want to contribute something. I suppose this thread provides a suggestion for them. Take the latest version of checkpatch .pl and reverse engineer from it an update to the coding style document that documents in plain, human readable English what that script implements. Seems it bit back asswards to me for the requirements to derive from a script that implements them, but that seems to be where we are at. The very fact that this thread even exists, that the original question needed to be asked demonstrates that there's something missing in the style document. > > > > > > > > If you look at things like MISRA-C - 200+ "Rules" to follow for safe code it turns out that basically nobody is able to write MISRA compliant code under consideration of all 200+ rules unless they have tools that tell them what is wrong with enough information that it can be fixed. And at the same time having those rules codified makes it hard (if not impossible) to update/maintain these rules - lots of which are actually out of date or overstated but now can't be "fixed" - It might help to have this up on a web-page/wiki somewhere - but if you put this into Documentation/CodingStyle at this granularity the rate of people reading and keeping it cache-hot while coding would sharply decline. > > > > I'm not familiar with MISRA-C (it appears to be a non-open standard from the wiki I just read about it, that in of itself demonstrates a problem with it if the wiki is correct), but at least it appears that it attempts to document a standard that various tool implementers can follow if they choose to do so. If people coding to it don't want to bother to read it, they can choose to rely on the tools and if and when the tools generate different results, then there is a written standard that can be consulted to determine which tool is broken. > > > > By what standard are changes to checkpatch.pl to be judged? > > > >MISRA-C is a closed standard - probably not a good example of a bad example :) > > > >putting the rules into a specification file would make sense but putting them into the CodingStyle directly I think would be problematic - my take on the CodingStyle file is to get the general rules clarified in a way that it can be remembered relatively easy but not overload it with details. > > > >most of the rules are outlined in the checkpatch.pl directly in one/two line statements for the rule that started this discusison. > > > ># at the beginning of a line any tabs must come first and anything # more than 8 must use tabs. > > > >so maybe a solution to the missing complete set would be to improve that in source description of each rule and add an option to checkpatch.pl to list all of the rules. Not sure if that makes sense but it would atleast keep things in one location. > > Still: > > > By what standard are changes to checkpatch.pl to be judged? > Documentation/CodingStyle is a sufficiently stable basis that the detailed checker rules can then be changed by the normal consent achieved by posting patches to checkpatch.pl to the appropriate maintainer+LKML. An evolutionary approach is more robust that trying to put it down in detail at one point - note that scripts/checkpatch.pl has had about 440 patches applied in its life-time - git log --pretty=format:"%s" scripts/checkpatch.pl | wc so one could speculate that any CodingStyle that wanted to put rules down in detail would end up being at least a few hundred rules long wich would be hard to keep synced in detail with an evolving script aside from being hard to use for daily work. Extracting the rule set so that it could be used by new developers would be sufficient to support new developers and doing that from checkpatch.pl directly would allow to keep it maintainable. thx! hofrat _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
