As you may know, our approach to developing software is kind of agile development meets high assurance. What the heck? We are now engaged in prototyping and modeling, so the slider is to the agile development side. But the high assurance part will come. And when it comes, and when we want our code to be certified, then clearly coding standards (and many other matters) will come to the fore. But for the moment, as you take a look at the code that we have already put out there on github, and other code that it is on it's way, remember where we are in evolution. For now, we feel that coding standards are kind of a moving target and so we are not going to be draconian in our oversight of that. In fact I have to say that harder than following a particular set of coding standards is ensuring that software we design and write is as simple, clear and well structured as possible, and then some. Personally I place a higher value on that than on whether we use 2 or 4 space tab settings ;) The other point worth noting is that different parts of the overall election technology suite are subject to different degrees of review and certification. For example, it stands to reason that the code driving the design of ballots is different than the code tabulating the vote.

So as software engineers who care about their work and especially where we are working on something as important as elections technology you can count on us writing code that we can be proud of. You won't find us crying crocodile tears when some of our code comes into the public domain and is scrutinized - after all, that's what we've been all about from the very start.

codingstandards, elections, opensource