Andreas Fritiofson wrote: > if I want to pass checkpatch, I have to fix the formatting of a > number of unrelated lines, so that it won't get inconsistent.
The lines being touched having fixed formatting would be enough to pass checkpatch. > Apart from being a PITA (I have better things to do), it obscures > the relevant parts of the diff and goes against the common practice > of separating formatting changes and functional changes into > separate patches. Indeed. Style fixes need to be separate. > I'm also getting problems with "visually pleasing" formatting > (subjective, I know) getting rejected by checkpatch. For example, > when I break long lines, I'd like to align the second and following > lines to, say, an opening parenthesis in the first line. I use > spaces for such alignment, while keeping the same number of tabs as > the first line, giving a good, consistent result, regardless of > tabsize settings. Eclipse does a very good job of doing this > automatically. However, checkpatch (with apparently no knowledge of > C syntax) complains that spaces shouldn't be used for indentation. Yeah, subjective. This particular style is common enough that I think we should consider teaching checkpatch about it. checkpatch does have some knowledge of C syntax. > Perhaps this kind of formatting is frowned upon, that's OK, I can > adapt. But I'd hate to have to write ugly code because checkpatch > is too crude a tool in relation to the weight of its report. The way forward is to agree on how we want to improve checkpatch, and then make those changes. > So, can we disable checkpatch checking at least until the entire tree > would pass in itself, No. > and/or dumb it down so it checks only basic, documented style > violations (braces placement, spaces in expressions and so forth)? > Possible? Desirable? checkpatch generally represents where we want to go, but since it was originally straight from Linux we may want to adapt it further. > I have a number of patchsets in the pipe, developed on separate > branches, each branch with a large number of "internal" commits > containing buggy code, bugfixes, dead ends, rewrites, unimplemented > stubs, reordered code and other messy stuff. Even if I manage to > rebase and squash them to neat patchsets, I think it's going to be a > lot of work to make each final patch pass checkpatch. So I'm inclined > to just squash everything to a single commit, amend it with fixes for > the formatting issues, and push. Nothing will get reviewed and merged if they are single commits, so please avoid that. Do squash into neat patchsets. As for the style issue, one suggestion would be to add a commit before your patches which changes files or functions you touch into checkpatch-friendly style. I would not be against allowing up to 7 spaces after a tab. > How do people manage this otherwise without spending hours? Of > course, one solution would be to have the discipline to make each > internal commit pass checks from the start, but then I would have > to spend more time formatting code than writing it. Not funny. Indeed, write correctly formatted code from the start. It can't be too difficult with the help of a modern or powerful editor? Personally I really hate typical IDEs which are very active in producing style, since they usually produce another style than what I want. Maybe there are good style settings in Eclipse. Dunno. //Peter ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
