/* Read previous pid file. */
if ((i = open (path_dhcpd_pid, O_RDONLY)) >= 0) {
    status = read (i, pbuf, (sizeof pbuf) - 1);
    close (i);
    if (status > 0) {
        pbuf [status] = 0;
        pid = atoi (pbuf);

        /* If the previous server process is not still running,
           write a new pid file immediately. */
        if (pid && (pid == getpid() || kill (pid, 0) < 0)) {
            unlink (path_dhcpd_pid);
            if ((i = open (path_dhcpd_pid,
                           O_WRONLY | O_CREAT, 0644)) >= 0) {
                sprintf (pbuf, "%d\n", (int)getpid ());
                write (i, pbuf, strlen (pbuf));
                close (i);
                pidfilewritten = 1;
            }
        } else
            log_fatal ("There's already a DHCP server running.");
    }
}

The problem with this strategy is that, if the box dies, there’s a stale pid file left in /var/run/dhcpd.pid. This wouldn’t be so bad — the code above checks [using kill(pid, 0)] to see if there’s a process running with that pid. But when the box is restarting, there will be a bunch of processes all starting in similar sequence each time. So on one boot, you might see dhcpd with a pid of 1001 and ntpd with a pid of 1002. If the box dies violently (e.g. power cut), the dhcpd pid file will contain 1001. On the second boot, assume ntpd starts first and gets a pid of 1001 and dhcpd is 1002. Now, the kill(pid, 0) will succeed, making it appear that dhcpd is already running, and dhcpd will exit.

How to fix this?

1. Explicitly put the pid file under /tmp. Getting this right is fussy — make sure you avoid the race conditions associated with creating temp files. Use dhcpd’s “-pf” flag to tell it where to use the pid file. This avoids spurious “already running” messages, because dhcpd will never read a pid from an existing pid file. [You could also just remove the /var/run/dhcpd.pid file, but I'd rather explicitly provide the path in my startup script in case some dim bulb decides to change the compiled-in default.]
2. Be careful in your restart code to kill any existing dhcpd (assuming you really want a new dhcpd), or avoid trying to start a new one (assuming you want to use an already running dhcpd). pgrep(1) and pkill(1) will be useful here.

In researching this, I saw this bit of wisdom from Henning Brauer: “pid files are useless.”.

I heartily agree…

1. The array definition will be more compact and easier to see all at once.
2. Defining actions in an array enforces uniformity.
3. You can put checks in the code to automatically verify that the array definition is complete. (I.e. verify it contains a definition for every item it should have.) Yes, some tools can do this for certain types of switch statements. Using an array-based check is more portable and more foolproof.

If you have a switch statement of mostly cut and paste cases, you can probably convert it to an array very easily, and then rewrite the switch statement to look up the value in the array and do whatever thing is supposed to be done, either via function pointers or by using an associated value from the array.

I did this on a horrible switch statement once. Dozens of cases, 80% were nearly identical but the few that weren’t were awful to untangle. Once I pulled the case bodies into separate functions, put function pointers into a table, and replaced the switch body with a lookup loop it was much cleaner. The code for the odd cases was eventually pushed out (it was a symptom of bad design). The whole exercise enabled another round of changes that allowed the functions for the case bodies to be collapsed back into the table — we ended up removing an entire unnecessary layer of indirection and made the design much easier to grok.

If you are the manager, and you outlast the team, you’re going to pay for low quality code when you try to bring in new people and they end up breaking everything becuase there’s no tests to check their bug fixes and/or enhancements.

If you are a surviving member of the team, you’re going to pay with huge headaches because you’ve got to fix code where you have no idea what might be broken as a result.

Change is scary when you don’t have automatic tests. Just suck it up and write the tests!

1. Source control. This almost belongs in the “if you don’t have it, you aren’t making software” category. There are so many free and simple to use tools that it is ridiculous to not use source control. Pick one of: subversion, git, or any of the dozens of other free tools and use it. I guess I’d say “if you don’t have it, you are making a mess”.
2. Bug/issue tracker. Trac is a decent tool for keeping tabs on development tasks and bugs. Bugzilla is ok too. If you have a budget, there is an apparently infinite set of commercial systems available of varying quality. Almost anything is better than a list of scribbles on your whiteboard.
3. Backup server. You can do software without it, but the odds are against you lasting long.
4. Build system. Automated nightly/continuous builds are awesome. Whether you DIY, install something free like hudson, or purchase a commercial system, this is a key piece of making sure that the software maintains at least a minimum level of quality (i.e. it is always buildable). After having worked on a couple of teams that didn’t have such a system, and the build was always broken, I would never work without it again.
5. IM / Jabber. Especially with a conference server where the rooms are archived and available via the web. Searchable is nice, but making them available where they can be grepped isn’t bad either. I didn’t become convinced of the value here until last summer.It sounds like an extra distraction and sometimes it can be, but you can turn it off when you’re heads-down coding. And it has the potential to reduce the number of interruptions from people walking into your office with questions that could have been answered in an IM. It’s lighter weight than email and rooms are broadcast by nature so you don’t have to spam a huge list of people to find the answer you’re looking for.
6. Email lists. Must have web-browsable archives; the list without this has much less value. Search would be a nice bonus, though I haven’t seen it done well. This lets teams communicate a bit more formally than IM and provides a record of certain discussions and decisions.
7. FTP server. Bonus points for a TFTP server. Maybe it’s because of the nature of embedded software, but every team I’ve been on has always had to fling around large files and images. Email is horribly inefficient for this. Also, most of the products I’ve worked on needed an FTP (or TFTP) server to boot from. You’re likely to install something on your development machine, which is fine, but it’s convenient to have a central team/company internal server so you can just tell someone that a file is in your public directory on “the ftp server”. Microsoft shops and folks that don’t need to boot via FTP can probably get away with samba shares.
8. Doc server. Wiki is probably the best way to go if your team doesn’t have to produce overly-formal documentation. Wikis and formal document control systems that I’ve used have had horrible search, which sucks but I haven’t found a great solution. In the past I’ve done this with a combination of a formal doc tool plus a blog for the informal “howto” kind of notes that are always needed.
9. Code review. I can’t say I’ve worked anywhere that had a dedicated code review tool. However, when all of the development machines are on NFS so that everyone has a view of your workspace, IM fits the bill reasonably well: post a review request to the chat room with the path to your changes and get an ad hoc on the spot code review. With some discipline and a supportive culture this works very smoothly. (This arrangement could probably be done with an internal pastebin, which I haven’t listed here as must-have since I haven’t really seen it used.)

What would you add to this list? Any other tools or systems that, if missing, would make you think twice about taking a job?

Given typical defect densities, any non-trivial design or code is going to contain some errors. Even seemingly trivial maintenance fixes are likely to be defective.

It’s your job as a reviewer to find as many of these defects as possible. If you’re not finding defects, you’re wasting your time on reviews.

That “one simple step”? Remind yourself that there are almost certainly defects in the work product you’re reviewing, and then find them. It’s all about attitude.

His simple example is the 13-letter word “lexicographer”. To you and I (assuming you speak English and have a decent vocabulary), it is easy to remember. We don’t have to remember 13 letters, we just remember the whole chunk. But when presented with “trgdpxhdewfwm” for 3 seconds, you probably can’t remember more than half a dozen letters.

Another example is that chess masters can recall board positions after being shown a chess board with pieces on it for just a few seconds. They do this by chunking sets of pieces together — almost like “words” — whereas novices will try to remember individual pieces (“letters”).

It struck me that programmers do the same thing when reading and writing code.

The coding standard helps us, by telling us where the chunks are and how to draw the boundaries between chunks.

If you have a coding standard.

And apply it consistently.

When you choose names at random, you destroy your short term memory. You become a crappy programmer, and you drag everyone around you down too.

Quick example in C. Assume you’re writing a small module for checking environmental status.

BOOL isOverTemp();
BOOL isUnderTemp();

int GetCurTemperature();

BOOL env_isOverVoltage();
BOOL env_isUnderVoltage();

Anyone writing this pile of gibberish should be fired excommunicated.

Why?

For starters, I just wrote it, and I can’t now remember which was camel case and which was underscored. Also: which one was abbreviated?

Before you object that this is a contrived example, two points: (1) yes, it is contrived, that’s the point of an example, and (2) I have worked with far worse on an almost daily basis — the example above is fairly tame.

On the other hand, if you know the coding standard has some simple rules — and they are followed uniformly — you can easily remember the function names.

1. Initial 2-3 letter module prefix (“env” for this example).
2. All functions are lowercase with underscores.
3. No abbreviations.

Then we have:

BOOL env_is_over_temperature();
BOOL env_is_under_temperature();

int env_get_cur_temperature();

BOOL env_is_over_voltage();
BOOL env_is_under_voltage();

Now, when you’re writing, reviewing, or maintaining code, you don’t need to constantly refer to the header or documentation to get it right. A simple three-line coding standard just boosted your memory capacity by over 643%.

(In the interest of full disclosure: I made that number up.)

I realize that implementing even this simple three line standard is controversial because all the camel case folks are pulling out big sticks and the underscore people are grabbing rocks. To which I say: just flip a coin and enjoy the extra brain power. Adopt a three-line standard, follow it, and save the curly-brace debate for the next major coding standard revision.

Why do this? Well, for one thing it makes code reviews easier when everyone follows the same conventions. It also makes maintenance easier.

1. pep8.py is a style checker that enforces the rules of PEP 8. The “official home” (?) at browsershots.org was dead as I was writing this. (Thanks GitHub!) Run pep8.py on your code and it will tell you where you’ve drifted from the standard.
2. pylint is lint for python. It provides more functionality than pep8.py, but is not a strict superset. (pep8.py is pickier about whitespace issues.) Pylint is also configurable to enforce various naming rules. Like most lints, the SNR is pretty low, but you can turn off most of the noise and get a reasonable signal for the things you want to check.
3. Subversion (as well as most other tools) can be configured to run a script every time you check in code. Run one or both of the above tools in the pre-commit hook and bad code will be rejected. (I’d be wary of doing this with pylint unless you’ve got the categories of “noisy” warnings turned off.) I don’t have anything cookbook for this yet, but I’m working on it…

This is a really broad way to divide the world, but I see two important categories of build scripts. (By “build script” I mean Makefiles, SConsfiles, Ant files, and their ilk).

1. Build scripts intended for in-house use, never seen by outsiders.
2. Build scripts that you distribute to external users.

Both sets of build scripts are important. Let’s consider the build script (or Makefile system, or whatever you’re using) as a software system independent of the software that is being built. Its primary requirement is to reliably convert your source code into an executable. Any decent build script has numerous other requirements, most of which are probably implied. I have never seen a written requirement for the numerous build scripts I’ve written. I have only rarely heard them discussed — and never actually posed as “requirements”.

I have, always taken the following meta-requirements for granted. Based on my experience with some fairly awful build scripts, I guess these aren’t universally acknowledged.

• The build script should build all the “normal” executables with a single command.
• The build script must encapsulate all environment variables within the script. (This is a corollary of the above.)
• The build script should not unnecessarily rebuild source code in a directory tree that has previously been built. (This is make‘s raison d’etre.)
• The build script should be documented. It doesn’t have to be elaborate, but a five-line comment at the top of the script describing the available command-line variables would be nice.
• make clean or its equivalent must work reliably.
• It should rarely be necessary to run make clean.
• Bonus: the build should be parallelizable, to be able to take advantage of multicore machines and/or distributed builds.

Back to those two categories. If you screw up an in-house build script, it’s primarily your team that’s going to suffer. I’m not aware of any bugs from SQA or Customers on projects I’ve been on that were traced back to a build script, but I can see where it could happen. Mainly what I’ve seen is developers habitually wasting time rebuilding source that should not need to be rebuilt. The worst offender in this respect was a build script that forced a “make clean” at the beginning of every build. In the immortal words of Dave Barry, I’m not making this up. Really.

(Actually, I think it was even worse when I was dealing with a build script that required a “make clean” every time around but didn’t have it coded into the script!)

I can’t say I have a completely clean conscience in this area: I wrote a big pile of Makefiles for a past employer in which I unknowingly used features (bugs?) of a specific version of GNU Make that were “fixed” in a subsequent version. As time went on it became (a) a much bigger task to fix the Makefile code that used the “feature” and (b) harder to keep the specific version of GNU Make that worked with the Makefiles! I imagine they’re still stuck with this situation… sorry guys.

In the second category, when you toss a slapped-together build script to your unsuspecting users you do all of human society a disservice. Now they are not only wasting their time fighting with a bad build script, but they often have the disadvantage of being unable to contact the author directly for support or commiserate with other experienced users of the system.

So do us all a favor: if you don’t know what you’re doing when you start to write your next build script, please ask for help. Otherwise we’ll have to resort to some sort of professional licensing scheme for build script authors.