Anonymous user
Code Management: Difference between revisions
m
Misspelling of Windows Millennium
| [unchecked revision] | [unchecked revision] |
(→At the source level: Typo) |
m (Misspelling of Windows Millennium) |
||
| (4 intermediate revisions by 4 users not shown) | |||
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
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.
Line 19:
Although this is usually less important than the previous concern, you need to keep the way different versions are numbered consistent. Some number versions sequentially (e.g. ''0.1'', then ''0.2'', then ''0.3''...) while others increment the minor version (e.g. the ''2'' in ''1.2'') number sequentially for small updates and only increment the major version number (the first number in the version) only when they add a major improvement to the projects. Some also add revision and build numbers, which are incremented by some random number every time a change is made to a file, which gives weird version numbers such as ''2.2.11127.56150'', which are hard to remember.
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.
[http://semver.org/ "Semantic Versioning"] is an attempt to unify versioning schemes. You probably already use a scheme that is close to this one.
Line 59:
=== Version Control Systems ===
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
[[Category:Organization]]
| |||