| News | |
 |
Latest |
|
Archive |
|
Community news |
| Articles | |
|
C++ |
|
Communities and Content |
|
Databases |
|
Editorials |
|
Emacs |
|
General |
|
HTML |
|
Java |
|
Notices |
|
PHP |
|
XML |
| Links | |
|
Apache |
|
C++ |
|
Database |
|
General |
|
HTML |
|
Java |
|
Javascript |
|
Linux |
|
Object oriented programming |
|
Open source |
|
Perl |
|
PHP |
|
Python |
|
Ruby |
|
SOAP |
|
XML |
|
Suggest a link |
| About | |
|
Advertise on zez |
|
Contribute |
|
Contact us |
|
About zez |
Coding Standards - Part 1 - Introduction |
It's natural
Your personal taste in programming is in itself a coding standard. You don't randomly use constants with upper and lower case, you probably don't mix different styles of while-loops and you definitely don't use a different indentation for each line of code. (At least I hope you don't, for your own sanity's sake.) Standards are natural. Unfortunately, arguing about them is, too. Always remember, when you join an open source project it is common sense to follow that project's standards. If you try to force your standards on others you'll lose your write privileges faster than fast. That's one of the great advantages of starting a project, you get to do it the right way - your way.
Our example
I'll try not to talk too much about how great this standard is (it is of course the best possible standard, but, as I said, I'll try not to talk too much about that) but rather to stress the importance of having standards at all. Almost any standard is better than no standard. And again, this is a C++ example, but the principles and concepts here are valid for many, if not most programming languages.
Files
All filenames are lowercase. Header files are suffixed with .hpp, implementation files with .cpp. The advantages of using all lowercase filenames on a case-sensitive system like Linux is obvious. The use of the .hpp suffix enables us to differ between C and C++ header files.
Each cpp/hpp pair contains only one class, unless we are using private classes. If a header file contains constants and declarations that don't need external includes, as well as other declarations that do need external includes, then dividing this file to avoid too many dependencies could be a good idea.
An implementation file that has to be written differently for different platforms, is to be split into one file containing platform-independent code, and one file per platform containing platform-dependent code.
In the next issue of this article we'll be moving along to macros, indentation and brackets.
Comment List
There are no comments.
