Node:Introduction, Next:How to Implement, Previous:Top, Up:Top
People often tend to judge the quality of software only by the number of it's functions, the beauty of it's user interface or the ease of it's utilization. But this is not the whole truth. Good software is more than that:
Good software is stable.
Well, actually this should be obvious: good software should have few bugs. (Oddly enough, some big and well-known software companies seem to be quite successful while not following this rule.) Of course, it is not possible to write 100% bug-free programs, but following a good coding style can save you from quite a few headaches.
Good software is fault tolerant.
This is even a higher aim than stability: not only that a program should not have bugs itself, but it should also be as tolerant as possible of failures of linked systems. A library function should always behave as reasonable as possible even when it is passed invalid parameters, and programs should give correct and meaningful error messages when the underlying software or hardware does not act like it should. Achieving this is not that hard, when you keep a few basic rules in mind.
Good software is reusable.
Some people think that reinventing the wheel over and over again is a basic requirement for a working software industry. However, other people don't. They try to build their code in a way that parts of it can be reused by other projects. But there are a few things to consider when you want your code to be really reusable.
Good software is maintainable.
Maintainability is not a question of simplicity. Even complex and powerful programs can be wonderfully maintainable, if you only take the necessary measures right from the start.
Good software is understandable.
What? Not only the original author of a program should be able to understand it, but everybody else looking at the code, too? Hey, that can't be right! That would mean that others can learn from my code! That others could even change my code, improve it, fix bugs, take over maintenance ... but wait! Couldn't that be a good thing, too?
Of course, there are a lot of things to do when you want to write good software. One of these things is that you should follow some standards in your coding style. To propose such standards, is the purpose of this guide. How to Implement deals with the proper way of implementing functions, not regarding naming conventions, code formatting and the like. Following the rules from this chapter will change how your software behaves, and make it more stable and fault tolerant. How to Code contains recommendations on how to translate an algorithm into code of a computer language. Whether or not you follow these guidelines (which are about modularity, naming conventions and all that sort of stuff) will not necessarily have impact on the functionality of your software, but on the reusability and the maintainability. How to Format gives you hints on the formatting of the code. This section deals with all the parts of the sourcecode that the compiler actually ignores, but help to make your software maintainable and understandable, like comments, whitespaces and indenting.
This text mainly concentrates of writing software in the C programming language, but most of the principles explained here can easily be translated to other languages.
This is not a replacement for the GNU Coding Standards (which you can find at http://www.gnu.org/prep/standards.html). This document does not deal with the specific issues about writing free software, and the very specific issues about writing software that should be incorporated into the GNU system. However, the above arguments probably make clear that only free software can be really good software, and therefore it is recommended that you read the GNU Coding Standards, too. In any case this document tries to not contradict the GNU Coding Standards.
This document is the result of a free documentation project. You can improve it if you want. Please look at http://www.freesoftware.fsf.org/style-guide for more information about this project.