Moreover, using non alphabetic or numerical characters is forbidden. The name must be a word or a group of words which describes the Class role and services. The package name must strictly correspond to the system folders tree, from the source folder root.Ī Class or Interface name contains only letters, begins by an upper case letter, and respect the CamelCase syntax. It's recommended to use short words, concatenations and abbreviations instead of group of words to limit the size of the package names. class extension.Ī package name contains only lower case letters, separated by dots. java extension, and the compiled files have the. The accented characters or any characters specific to a country or an alphabet are forbidden.Ī source file is strictly named as the public Class that it contains, including the case.Ī source file has the.
The names of classes, methods, variables, must not be too long (50 characters max.). It's the responsibility of any contributor to correct a file when he has to work on it, and this must be a part of the review process. In some specific cases, it can append that a rule can't be respected, but this must be explained and well-argued in the code comments.įinally, as the rules live with the project, some existing code may not respect new rules. The main objective is to build a code base which can live, be maintained and understood by any contributor, and not only its author. These rules can only have an added value if there are shared and applied. ARCH: Architecture rules, defining how the product components, features and plugins, must be build and configured.
COMM: Rules dedicated to the comment content and format.TIPS: Tips and tricks, best practices, etc.FORM: Rules defining the format of the code and its presentation.NAME: Rules related to the naming of the elements.Thus, each rule has an identifier, prefixed by its category. To ease the rules understanding, a classification has been made to organise them. To make those rules fullfilled by most of the contributors, they should be either automatable or trackable (i.e.: with a Formatter or with Checkstyle). Sometimes there are different ways to have the same result, then a rule can be added in this base to define the "Papyrus" code style. Others are not yet followed, but should be a good habit to avoid mistake when coding. Most of those rules are already followed by most of the contributors, and could seem obvious. This page is a starting point to discuss about those rules and practices. In order to make the Papyrus code more homogenous, it seems to be a good point to put some best practices down in writing. 1 Development Rules For Papyrus (DRAFT)ĭevelopment Rules For Papyrus (DRAFT) ContextĪs the number of contributors on Papyrus increased a lot this passed year, the code becomes heterogeneous with everyone touch.
0 kommentar(er)
