Code Management: Difference between revisions

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.

The last concern is the method that is used to accomplish certain tasks that are used in multiple places across the OS. For example, the C language allows two syntaxes for incrementing the value of a variable which are equivalent (''var++'' and ''++var''), and the C++ language allows two ways toof allocateallocating memory (''new'' and the C standard ''malloc''). A good project has well-defined conventions that are followed throughout the project.

Fortunately, with the evolution of modern IDEs, following the coding conventions of a project has become a simple matter of setting up tethe IDE to use the correct encoding/tab policy/headers, and using the IDE's automated source formatting utilities to produce correctly formatted source files. Some IDEs can even create the heading comment block directly at the start of each source file you create, so that you only have to fill in the gaps.

Additionally, you may give each release a special name. Projects that use that strategy include Mac OS X (e.g. Leopard, Lion, Mountain Lion...), Android (e.g. Gingerbread, Jelly Bean, Ice Cream Sandwich...), Windows (e.g. MillenimMillennium, XP, Vista), and probably others I don't know about. Just pick the one you prefer, or something completely different, or even more simple, such as ''MyOS 1'', then ''MyOS 2'', then ''MyOS 3''... it's your project, after all!

A [https://en.wikipedia.org/wiki/Version_control Version Control system] (VCS) is a program that manages changes to your source files (for OSX users, this is much like Time Machine, but enhanced for source code). Concretely, you perform a ''commit'' operation after each significant change (e.g. after you rewrote your scheduler, or added a new driver, don't commit after each modified line), and the VCS will remember the state of the files before and after the changes. This means that if you change your mind and want to see your code again, then the VCS will be able to give it back. A VCS also enables you to generate ''patches'', which are files that contain only the differences between two versions of a same file.

But the main point in using a VCS is that it enables two (or more) persons to work on the same codebase at once without interfering with each other. A VCS also allows you to place your source code on the Internet and have your whole team co-operate using a single server. Many source code hosting websites (such as Google Code and SourceForge) support accessing your codebase through a VCS, and using such tools for your code gives you more chances to get people to contribute to your project.