Coding standards are communication tools

I’ve been writing a lot of C code over the past few months. It’s been fun and I’ve learned a good amount about writing solid, low-level, procedural code. While cranking out code I’ve also been developing a simple coding standard, mostly for my own use and based on on the K&R standard. I’m not working with a particularly large group (and probably won’t be anytime soon) so I won’t be asking anyone else to follow these standards anytime soon. They don’t follow the rest of the code 100% either. But even being essentially the lone hacker on the project, I’ve found sticking to a standard helpful.

C is a great language but often I want to say things as part of the program that I can’t put in the code. For example, there are often things about variables that aren’t captured by the type and even if they are, I don’t want to have to look up the type every time I see the variable to get that information. But by following simple rules about how my variables are named, I can pack in a lot of information. For example, a plural name is an array, a name prefixed with num_ indicates that it holds the number of something in the system, a name prefixed with rv_ means that it stores the return value from a function (probably for error handling). Outside of variables, function names are verbs, locally defined types meant to be private are CamelCased, exposed types have a _t suffix. Of course, these don’t apply in all cases and some amount of discretion is involved.

Following a standard like the above has a double benefit: first I can think less when it comes to naming things and it prevents casual naming conflicts. Secondly, as I hinted to above, it’s a communication aid. There’s a certain amount of information that is encoded into the language’s syntax and semantics. This layer is checked and enforced mechanically at compile time. But a coding standard allows for a secondary, optional layer that can convey more information without expanding the language standard (and allowing teams and individuals to develop their own, suited to the task at hand).

Note that I’ve mostly talked about naming conventions and I haven’t said anything about formatting. Personally I think formatting conventions are less important and helpful. It can be annoying to read code that is formatted differently across files (or in the same file), but I think the benefits to be gained from consistent formatting are less than that for consistent naming. In fact, I think that formatting issues should be eliminated by having a tool that will automatically reformat code to a single standard. I have the Go language’s gofmt tool in mind, but I’m sure there are others. (This is also one of the pet peeves I have with Haskell: it’s apparently really hard to write an auto-indentation tool for its syntax)

One caveat is that I have no personal experience as to what effect a coding standard has across a large group. I’ve found two articles arguing against coding standards on teams, but they’re both far too emotional and hand-wavy for me to take them seriously. Personally I would be wary of a developer who can’t adapt to a coding standard in a reasonable amount of time. That being said, there are definitely more important things than adhering to a standard (getting working code for one). However, I do think that coding standards fit into a larger culture and system of good coding practices. These include things like code review, appropriate use of version control and proper communication channels to talk about bugs and feature changes.

To conclude, a coding standard can be a great tool for personal uses. In some ways it frees up my limited mental RAM to think about more important things. It also allows me to pack more information into my code, outside of what the language syntax or semantics allow. I’m less certain of the benefits for large groups and as Emerson puts it, a foolish consistency is the hobgoblin of small minds. That being said, I’d like to believe that a good coding standard (with formatting mechanically enforced) along with practices like code review can lead to a higher code quality.

Tsuyoku Naritai

Happy New Year, dear readers (albeit somewhat belatedly). I’ve been spending most of the last month traveling and spending time with family and friends. And now I’m going to tackle the matter that is on everyone’s mind at this time of the year: New Year’s Resolutions! Aren’t you all excited?

I’ve never been a fan of making a long list of resolutions on January 1. There’s an arbitrariness to it that I’ve never found appealing. I understand the need for a New Year’s Day for practical purposes, but it is really just another day. It doesn’t even commemorate someone’s birthday or a memorable event. Furthermore, grand announcements of how we’re going to change our lives have always seemed unnatural. Most of the changes in my life (and I’ve changed a lot over the last few years) have been sequences of events, opportunities and small decisions building up over time, not sudden all-changing promises.

All that being said, I am a fan of the general notion of self-improvement. A few months ago I came across the Japanese phrase “Tsuyoku Naritai” which translates to “I want to become stronger”. The original article by Eliezer Yudkowsky is worth reading and I won’t bother repeating it here. It focuses on the idea of improvement (getting stronger) as opposed to the idea of simply apologizing for weakness (and not doing anything about it). But the concept of Tsuyoku Naritai presents an interesting contrast to the idea of New Year’s resolutions.

I have always felt that resolutions were mostly external motivations: they embodied things that we thought we should change, that we were constantly being told we should change. By contrast I feel Tsuyoku Naritai is more intrinsic. It’s not “I should” or “I will”, it is “I want”. It acknowledges that we may not have strength now, but it declares that we want to gain it.

“Tsuyoku Naritai” is more general than most resolutions. While I’m all for specificity of goals, the start of the year might be the wrong time for them. Making serious changes takes a lot of willpower – something that we have a finite supply of. Deciding to change our diet, our exercise routine, our work schedule and how we spend free time all at the same time is a fool’s errand. The need for willpower can be mitigated by making use of habit – putting things on autopilot. But setting a new habit takes about a month and in that time we’re burning precious willpower reserves. We may be able to completely change all the spheres of our life over a year, but we certainly can’t do it all at the same time. Instead of making lots of specific promises at the start of the year, maybe it’s better to pick an over-arching theme. We can pick a goal a month that to devote our willpower to and set into a habit.

This year I don’t have a set of resolutions. I do have a list of things I want to accomplish over the course of the year, but I’m taking them one at a time. But in addition to those specifics I have a more general theme of wanting to be stronger – physically, intellectually, maybe even mentally/emotionally (though I’m not entirely sure what that would entail). Tsuyoku Naritai is my theme for 2013 and something I hope to revisit as the year progresses.

I hope you all have a happy and productive new year. Live long and prosper. Become stronger.