Hi, Before I present the ideas that Martin and I have been discussing recently regarding coding style, I would like to mention that for me, it is far more important that we agree on a _common_ style rather than _my_ preferred style. The goal here is to make the code more readable and to relieve the programmer from worrying about the size of the tab stops.
Not only are the style rules, themselves, important, but also the transition to them. We must have a clear transition in the revision control system to make it easy for developers when preparing diffs. Also, we need to coordinate with Sergei regarding his modifications that he would like to commit upstream. if, for example, we commit everything with new tab spacing before he commits, we'll never be able to sort out the diffs. So, yes, it would be nice to have a consistent style, but not at any price. As a basis for the discussion, I suggest that we start with "Perl Best Practices", by Damian Conway. If, however, there is a compelling reason to go against his recommendations, there should be no problem with that. To help the programmer follow the style recommendations, there are two basic types of tools: filters and checkers. A filter takes the source file and, usually in the editor buffer, rewrites the file using the style definitions. A checker merely checks the file against the style definitions, but makes no changes. It just complains when something is wrong. Both have their advantages and disadvantages. The filter is used for changing the white space of a file. It takes care of things like tab stops, whether conditionals are cuddled (i.e.: placement of those squiggly brackets around if and else) and basically lining up things to make them pretty. For this, I suggest perltidy (http://perltidy.sourceforge.net). I've been using it in VI and have been very pleased with it. It has even helped me find missing brackets in my code. The configuration file I use, .perltidyrc, is checked into the SVN and is based on Conway's book. See the comments in the file for more details. The checker, in contrast to the filter, does not change the contents of the source file. This is because it can check much more than just the line spacing. It can do things like enforcing standards for variable names or pointing out buggy coding practices. The checker that seems to be best suited is Perl::Critic. It can be run during the version control commit process, when running the test cases before release, or directly from the command line during development. Obviously, more effort may be needed to make the OpenXPKI compliant to the style definitions we establish. Fortunately, it is easy to set the threshold in Perl::Critic, allowing for a smooth transition. Please keep in mind, though, that our goal is not to establish some draconian policies regarding coding style. Instead, we are trying to make it easier for the programmers by improving readability and relieve them from worrying about white space. We also hope to improve overall code quality and identify sections that are potentially buggy. Regards, Scott
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------
_______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
