bloggo ergo sum

I just discovered the POCO library. It’s pretty neat-looking: it has a number of components that provide functionality that goes beyond the standard C++ library, such as threading support, networking, XML reading/writing, etc. The cherry on top is that not only is it similar to boost in terms of functionality, it seems smaller, more portable, and more easily targeted for embedded systems. Great, right? Read on…

However (begin rant), the style of the library really turns me off. Hugely. I haven’t even read all of the style guide (which is somewhat oppresive), but two big things I discovered right away:

• Camel-case is used, much like in Microsoft’s MFC
• Tab characters are used in the source code

I suppose tabs being used in the sources is pretty inconsequential for normal users of the library – although its annoying just to know that they exist.

The naming conventions though, are another animal altogether. Some of you reading this might be thinking to yourself “Holy cow! Who cares? Don’t sweat the small stuff!”. With most things, I am inclined to agree, but not on this.

Conventional style for a particular programming language is usually either defined or employed by its standards and standard libraries. This is true of Java, C, C++, C#, PHP, Scheme – you name it (there may be exceptions), and it also goes for indentation, brace placement, spacing, etc, etc, although I’m mostly concerned with naming here (everything else can be fixed by indent scripts if necessary). Take C for example. The standard C library uses almost all lowercase names, and those names tend to be brief (abbreviated if necessary), like ‘strncpy’ or ‘memset’. Structures tend to be named similarly: ‘pthread’ and ‘fileattr’, which sometimes get typedef’d to ‘pthread_t’ or ‘fileattr_t’ so that it’s clear you’re using a data structure. Most systems’ libc uses this style as do other POSIX-related libraries. Products like WindRiver’s VxWorks that deviate drastically from this convention (WindRiver in particular basically just made up their own style – to heck with convention; Microsoft was almost as bad) are an abomination to code consistency and elegance.

C++ also has its own style – the standard library (also – incorrectly – known as the stl) exhibits this. Names are typically longer than in C and multiple words are typically separated by the underscore character rather than abbreviated, although abbreviations are appropriate sometimes to keep lines from getting too long. class names are not capitalized except in the rarest circumstances. Namespaces should be used and follow the same guidelines for naming.

Why is this important to me? It’s important because you want your code to have a consistent visual style. Much of the style can be pretty arbitrary, and that’s fine. Brace placement and the width of your indent are less important to me. Even if you don’t like the way someone else chooses those elements of style, they can be changed pretty easily. Naming is not like that, and choosing non-standard (or non-conventional, if you prever) naming makes code harder to read and maintain. When I write C++ code, I want it to all look as much like the standard library as possible, with few exceptions. Then, when I want to use a library like POCO, my coding style is all blown to heck because somebody over there decided to make their own rules. Microsoft is probably the primary guilty party in this respect because of the style they chose for MFC and the ATL, as well as the Win32 API.

POCO is even internally inconsistent. On their website, they state that they have goals to:

• Don’t reinvent wheels that have already been solved, particularly in the standard library (i.e., “thou shalt let std::string be thy string”)
• Have consistent style.

Choosing to not reinvent implementations that work but also to ignore the conventional style (like Microsoft did) are contradictory.

Anyway, this isn’t to say that POCO shouldn’t be used. I’ll probably use it sometimes. I was just *very* annoyed by C++ code that uses the camel-case naming style.