Code Management: Difference between revisions

→‎Consistency in the codebase: C++ comments are // and c is →‎...: not the other way 'round
[unchecked revision][unchecked revision]
(→‎Consistency in the codebase: C++ comments are // and c is →‎...: not the other way 'round)
Line 5:
 
=== At the source level ===
In a large project, it is important that all source files be written the same way. It starts with the coding style. Everybody has his own and likes to use it, but large projects need to impose one coding style for the whole project, or people willing to contribute will spend all their time deciphering the coding styles of the others, and lose any will to help out, resulting on your project to be abandoned. Most projects also impose that each source file contains a heading comments which typically contains a description of the file's purpose, its filename, and its licensing conditions (or a reference to the license, in case of long licenses like the GPL). Additionally, projects should impose other aspects of the coding standard, such as the tab policy (the way indentation is performed through tab characters or spaces, and how many spaces per indentation level), the preferred comment style (either C++-style ''//'' or C++-style ''/* ... */'' for which purpose), or the encoding (pure ASCII, UTF-8, etc.) of all source files.
 
Perhaps the most essential thing to define is the naming convention (that is, how functions, structures, types, macros, variables etc. are named) in the interface (see [[#Interfaces, Implementations, and Black Boxes|Interfaces, Implementations and Black Boxes]] below for more details). This is less important for internal (e.g. ''static'' in C) functions which are not exposed, though it's good practice to keep the same standards everywhere.
Anonymous user