How to Write Good Software
By Niko Rosvall, published 22/12/2014 in Development
Software must be free as in freedom
Good software is Free Software. I will avoid using the term "open source" as it doesn't cover a social side at all, which is equally as important, as the technology itself. You can read more about this from here.
Widely accepted tools and languages
Good software is written in language that is widely used. That guarantees that there are people who can read and modify the code. Good languages, for example, are C, Python and Java. There are of course exceptions where some less used language is a better choice.
Keep it simple
Good software doesn't do things it doesn't need to do. In other words there aren't unnecessary features. Implementing features that no one uses will only introduce bugs. Keeping things simple should be a top priority when designing software. Like Albert Einstein said; "Make things simple as possible, but not simpler."
Too much abstraction is bad. If you hide the code behind multiple levels of abstraction you will also hide the bugs. Too much abstraction makes the code hard to understand, makes it hard to follow the execution paths and it makes it hard to debug. Often it will also decrease performance. Abstractions over abstractions are often a problem found in enterprise software written in Java. Good software can be written in Java, but Java also makes it very easy to write horribly over complicated code. Same goes for C++.
Don't make it rocket science
Use variable names that has a real meaning. Don't use one character variable names. They're almost impossible to understand and to keep track of. There are one character variable names that are commonly accepted. For example in coordinates, it OK to use x and y. In for loops it's OK to use i, j and so on. Other than that, do not use them. Generally, in good software the code is structured in a clean manner and there are documented coding conventions available.
Documentation is important
Despite how boring it might be, good software is documented. Code has comments that are meaningful, software has manual pages which are installed with the software. For web applications, make the documentation available online.
Often developers think that it's enough to write the documentation once the software is done. That's completely wrong approach. Documentation must be a thing developers do while they develop the software. Documentation is part of the development, not something you do after the code is written.
Use a version control system
Good software uses version control system. Always. Nowadays, I will almost always recommend Git for version control, but there are cases where something like SVN does the job equally well. Version control makes it easy to roll back possibly problematic changes. Consider the following example what could (and will) happen without a version control system:
Developer A makes a change in a file program.c. The file program.c
is copied over to the source tree and the old file is replaced.
Later on a bug is found that originates in the changes developer
A made for the file program.c. Developer B,C etc. will have hard
time finding out what was the change developer A made. With
version control system this would not be a problem. Developer B
could easily see what the change causing the bug was. Of course any
smart developer team should have backups, so in this case they could take the
original backup before the change and use diff tool to see what the change was.
However, that takes time and is a hassle. Not to mention how error prone
it's to copy files over from backups and replace the files.
Extensibility
Extensibility is not strictly a requirement, but often it makes the software more useful. One good approach is to develop the software so that it can be used together with other programs. In fact, this was one of the main design principles of Unix.
Examples
The internet is full of software which is well written. Many standard Unix tools are well written, however some of them are not. One well written example is Memo, software I wrote.
If I would need to recommend a book to read, I would point you at The Art Of Unix Programming written by Eric Raymond.
Originally posted on www.ideabyte.net, December 20, 2014 by Niko Rosvall and kindly submitted to The Linux Rain.