Make the most of side-by-side code differencing

I'm constantly amazed how many developers shoot themselves in the foot by defeating the benefits of side-by-side source code differencing, which is perhaps the most routinely used technique in daily code development and maintenance with any VCS (Version Control System). In this post, I'd like to share a few tips for making the most of side-by-side differencing, which in my view should be adopted into every coding standard.

First of all, to benefit from side-by-side diff you need to limit the width of your lines so that you don't need to scroll horizontally to see all the code. Countless bugs slip into a VCS, because they are hidden off screen during the final merge and people are simply tired of constantly scrolling back and forth. (All GUI usability studies agree that horizontal scrolling of text is always a bad idea.)

Granted, the modern high-resolution wide screens offer a lot of horizontal pixels, but ultimately you'll always run out of the screen real estate if you allow lines to go on for miles. The column width must obviously allow comfortable viewing two code listings side-by-side, but you should also budget some horizontal space for the directory-tree view, vertical sliders, line numbers, and line margins, as shown in the screen shot below. I've been using the column width limit of no more than 78 characters. Your limit could perhaps be higher, but you must set such a limit and then enforce it without exceptions.



I can see two main reasons why people write very long lines. The first is long strings in the code. But C or C++ allow writing wide string constants in the following way:

char const s1[] =
    "This long string is acc\
eptable to all C compilers.";
char const s2[] =
    "This long string is permissible "
    "in ANSI C.";

 

In other words, you can either use a backslash '\' to terminate a string and continue in the next line, or you can terminate a string normally with a double quote '"', and an ANSI C compiler will concatenate such adjacent strings into a single zero-terminated string.

The second reason for long lines are preprocessor macros. Here again, you can use the backslash '\' to break up a longer macro into lines. For example:

#define err(flag, msg) if (flag) \
   printf(msg)

 

is the same as

#define err(flag, msg) if (flag) printf(msg)

 

The use of a backslash for breaking up longer lines brings up the issue of the end-of-line convention and the use of white space in your source code in general.

Let me start with the end-of-line convention. The issue here is that the backslash continuation won't work unless the '\' character is immediately followed by the end-of-line. Unfortunately, at lest two incompatible end-of-line conventions are in widespread use. The DOS/Windows end-of-line convention consists of the pair of characters CR-LF (0x0D, 0x0A in hex) to terminate lines. In contrast the UNIX™ end-of-line convention uses only one LF character (0x0A). As it turns out, Unix-like machines (e.g. Linux) are confused by the DOS end-of-line convention and will not correctly recognize the backslash-continuation, which looks like '\'-CR-LF (0x5C, 0x0D, 0x0A), instead of '\'-LF (0x5C, 0x0A).

My recommendation is to use consistently only the UNIX end-of-line convention, even on Windows machines. In my experience all Windows-based compilers have no problems with the UNIX convention, including the ancient tools from the DOS-era. As I mentioned, the converse is not true.

And finally, let me talk about the use of white space (spaces, tabs, end-of-line) in general. Obviously, to benefit from source code differencing you'd like to see only the relevant differences and differences in white space only are typically not relevant. Many code-differencing tools offer an option to ignore white space, but I would not recommend relying on it. Are files with different sizes really identical? And also, as I said before, extra spaces or tabs after the backslash, but before the end-of-line, are not allowed.

As far as tabs are concerned, I'd strongly recommend not to use them at all. Tabs are rendered differently by different editors and printers and bring only insignificant memory savings. Preferably, you should disable tabs at the editor level. At the very least, you should replace all tabs by spaces ("untabify") before saving the file. As for spaces, I recommend removing any trailing spaces that precede the end-of-line character (LF).

Obviously, you can and should automate the source code cleanup. I use the QCLEAN utility (available here under the GPL license) for cleaning up the code from tabs, trailing blanks, and to enforce the Unix end-of-line convention. The simple console QCLEAN Windows executable scanns recursively all source files (.C, .CPP, .H, .ASM, .S, Makefile, etc.) down from the directory in which it is invoked. The following two listings show a code snippet before and after cleanup with the QCLEAN utility (spaces are shown as dots, tabs as \t, DOS end-of-lines as \r\n, UNIX end-of-lines as \n).

before cleanup:

.\t...\r\n
class.Foo.:.public.Bar.{...\n
public:.\r\n
\tFoo(int8_t.x,.int16_t.y,.int32_t z).//..ctor..\n
....:.Bar(x,.y),.m_z(z)....\n
....{}.............\n
.\t..\n
....virtual.~Foo();\t... //.xtor........\r\n
....virtual int32_t doSomething(int8_t.x);.//.method..\r\n

 

after cleanup with QCLEAN:

\n
class.Foo.:.public.Bar.{\n
public:\n
....Foo(int8_t.x,.int16_t.y,.int32_t z).//..ctor\n
....:.Bar(x,.y),.m_z(z)\n
....{}\n
\n
....virtual.~Foo();... //.xtor\n
....virtual int32_t doSomething(int8_t.x);.//.method\n

 

Object-based programming in C

Embedded developers abandon C++ in droves. According to the 2007 survey published in the ESD magazine, the C++ use declined by one-third compared to year before, which was offset by an equal rise in popularity of C—the only viable alternative in embedded.

Even though the last year was most dramatic, the trend has been actually continuing for a number of years. This couldn't go unnoticed by UML tool vendors, who desparately have been trying to cater to C programmers. For example, you can check out the DDJ article "UML for C Programmers" (which seems to be pretty exact re-print of the Embedded Systems Conference paper "UML for C-Based Embedded Systems"). To my surprise, nether this article, nor the ESC class mention any well-known techniques of mapping objects and classes to C. I’m sure that it is not what UML vendors like. After all, UML is crippled without objects. (The only real meat remaining are state machines.) But I suppose that the marketing departments of I-Logix/Telelogic have done their homework. Apparently embedded developers don’t like to hear about objects anymore.

I find this really disturbing. It seems that "object" and (pardon my language) "class" are becoming dirty words in the embedded circles. C++ decline is one thing. But abandoning objects is a different story. Aren’t we throwing out the baby with the bath water?

One would assume that the 21st-century software developers have objects in their bones and everyone knows how to program with objects in any language, including C. Apparently increasing number of us don’t know that object technology is a way of design, not the use of any particular language or tool. Most design and implementation techniques now associated with C++, Smalltalk, or Java, actually long predate these languages.

So here is how you implement a Point class in C (a Point that you can put on a screen):

typedef struct PointTag {
    int16_t x;   /* x-coordinate */
    int16_t y;   /* y-coordinate */
} Point;

void Point_ctor(Point *me, int16_t x, int16_t y) {
    me->x = x;
    me->y = y;
}

void Point_move(Point *me, int16_t dx, int16_t dy) {
    me->x += dx;
    me->y += dy;
}

int16_t Point_dist(Point const *me, Point const *other) {
    int16_t dx = me->x – other->x;
    int16_t dy = me->y – other->y;
    return (int16_t)sqrt(dx*dx + dy*dy);
}
. . .

/* example of using Point objects */
Point foo, bar, tar;  /* multiple instances of Point */
int16_t dist;

Point_ctor(&foo, 0, 0);
Point_ctor(&bar, 1, 1);
Point_ctor(&tar, -1, 2);

dist = Point_dist(&foo, &bar);
Point_move(&tar, 2, 4);
dist = Point_dist(&bar, &tar);
. . .

 

You can create any number of Point objects as instances of the Point struct. You need to initialize each point with the "constructor" Point_ctor(). You manipulate the Points only through the provided functions, which take the pointer "me" as the first argument. The "me" pointer corresponds directly to the implicit "this" pointer in C++.

Moreover, you can as easily implement single inheritance. Assume for example, that you need to add a color attribute to Points. Instead of developing such a colored-Point from scratch, you can inherit most what’s common from Point and add only what’s different. Here’s how you do it:

typedef struct ColoredPointTag {
    Point super;    /* derives from Point */
    uint16_t color; /* 16-bit color */
} ColoredPoint;

void ColoredPoint_ctor(ColoredPoint *me, int16_t x, int16_t y, uint16_t color) {
    Point_ctor(&me->super, x, y); /* call superclass’ ctor */
    me->color = color;
}

...
/* example of using ColoredPoint objects */
ColoredPoint p1, p2;
int16_t dist;

ColoredPoint_ctor(&p1, 0, 2, RED);
ColoredPoint_ctor(&p2, 0, 2, BLUE);

/* re-use inherited function */
dist = Point_dist((Point *)&p1, (Point *)&p2);

 

As you can see, you implement inheritance by literally embedding the superclass (Point) as the first member of the subclass (ColoredPoint). Such nesting of structures always aligns the first data member 'super' at the beginning of every instance of the derived structure. This alignment is guaranteed by the C standard. Specifically, WG14/N1124 Section 6.7.2.1.13 says: "... A pointer to a structure object, suitably converted, points to its initial member. There may be unnamed padding within a structure object, but not at its beginning". This alignment lets you treat a pointer to the derived ColoredPoint struct as a pointer to the Point base struct. All this is legal, portable, and blessed by the Standard.

With this arrangement, you can always safely pass a pointer to ColoredPoint to any C function that expects a pointer to Point. Consequently, all functions designed for the Point structure are automatically available to the ColoredPoint structure. They are all inherited.

There is really nothing to it.

Is Eclipse The Emperor's New Clothes?

"Many years ago there was an Emperor so exceedingly fond of new clothes...

...one day came two swindlers. They let it be known they were weavers, and they said they could weave the most magnificent fabrics imaginable. Not only were their colors and patterns uncommonly fine, but clothes made of this cloth had a wonderful way of becoming invisible to anyone who was unfit for his office, or who was unusually stupid.

...so off went the Emperor in his new clothes that were nothing at all. Everyone in the streets and the windows said, "Oh, how fine are the Emperor's new clothes! Don't they fit him to perfection? And see his long train!" Nobody would confess that he couldn't see anything, for that would prove him either unfit for his position, or a fool. No costume the Emperor had worn before was ever such a complete success."

--Hans Christian Andersen, "The Emperor's New Clothes"

To me this little story has a lot to do with Eclipse (www.eclipse.org), which apparently is taking our industry by storm. Obviously, I must be the poor fool, unfit to see the remarkable benefits of Eclipse, but as an embedded developer I really, honestly don’t.

Admittedly, I'm a very naïve user of Eclipse, with experience limited just to two tools: the Altera Nios II Integrated Development Environment (IDE) and the Texas Instruments Code Composer Essentials for MSP430. Both these tools are based on Eclipse, and because of this both are just terrible.

I'm really not impressed with the CDT (C/C++ Development Tooling). The CDT workspaces, project files, and makefiles are notoriously difficult to move from one development workstation to another because they contain absolute paths. Even for the simplest project the CDT manages somehow to produce hundreds of files in a directory tree 3-level deep. You tell me how am I supposed to save this in any VCS (Version Control System).

The make process takes ages.

But probably, the worst part is the GDB interface to the remote target. Not only is the connection flaky and dreadfully slow (no comparison at all to other commercial offerings.) The target connectivity spawns some GDB server processes that tend to be "pigs" (i.e., take 100% of your host CPU, even if not talking to the target.) This isn't the highest level of professionalism...

Sure, the CDT allows you to forego the automatic makefiles generation and use external Makefiles instead (which I would actually recommend). In principle, I could also go ahead and fix any problems in Eclipse, the CDT plugin, or the GDB server, because they are all available as open source. But, then I must ask if Eclipse is really such a great productivity booster? Don't I really have a bigger fish to fry than fighting the tool?

So, as it stands, the Eclipse Emperor is naked for me.

What do you think? What are your experiences with Eclipse in the embedded system space?

Embedded Software Crisis or Embedded Software Glut?

I’ve been listening to the recent webcast "Solving the Embedded Software Crisis" (see also Rich Nass’ column "The need for more programmers" in the May issue of the ESD magazine). Of course, the main thrust of this particular webcast (as well as the ESD column) was the use of code generating tools (such as LabView from National Instruments, the sponsor of this webcast) to alleviate the allegedly looming crisis.

But tools or no tools, the real problem in my view is not so much with creating new code, as it is in getting rid of the old code.

In every company I worked for, we had to maintain just one broad code base for all products of that particular division of the company. We only kept adding to this code base, as new features, product variants, and entirely new products were released. But we never removed anything. Needless to say, the code was a kitchen sink of everything that the company ever did, including prototypes and dead ends. Most of the stuff was long obsolete, but it lived on in our code forever.

Adding code is easy. Removing dead code (without breaking the actually used parts of the code) is hard. But without the mechanisms for dropping the old baggage, we face a real Software Crisis.

Yet most managers don’t get it. I remember one day my boss came to my desk wanting to know how much code I have just cranked out. I proudly showed him that I managed to actually remove an ugly function. He was clearly disappointed in my negative productivity.

From all my experience, I’m convinced that getting rid of code is more important than creating new code. As I said, it’s not easy, but rather requires careful planning and actual design for obsolescence. In the future installments of this blog, I plan to provide a few concrete design strategies to allow easy (or at least easier) removing of obsolete code. Stay tuned.

Agile Embedded Development

Silicon Valley finally seems to be taking a serious look at "agile development" as a competitive advantage. Articles like “Reinventing the Software Development Strategy” by John Seybold give us a glimmer of hope that maybe software development doesn’t always need to be a “death march” of missed schedules, but rather can actually be fun.

If you accept arguments made in Seybold’s article (and many other articles and books about agile development and extreme programming), then you must look at testing in an entirely new light. Testing is not some pain-in-the-neck chore performed long after the design and coding by the most junior and inexperienced team members. Rather, continuous testing is the primary activity that drives everything else that’s going on in the project. In fact, if you truly put so understood Testing (with capital T) at the center, the whole agile process falls out more or less automatically from this single principle.

Testing, in the agile sense, has been notoriously difficult in the embedded space. The desktop guys have powerful, commodity hardware with plenty of standard development tools. We embedded folks, on the other hand, by definition work on some custom design interfaced to proprietary, often buggy (or not even yet existing) hardware.

But it doesn’t mean that embedded developers cannot dramatically improve Testability of their software. If you truly, seriously think about Testing, you need to bend everything in the project toward the Testing, not the other way around.

Let’s start with the design. Everybody knows that modular software with independently testable pieces is good. The trick, of course, is to build it that way.

The conventional approaches, unfortunately, aren’t helping here. Take for example a traditional RTOS. The natural units of decomposition are tasks. But when you try to unit-test any real-world task, you quickly notice that it is hopelessly intertwined with other tasks by means of semaphores, shared resources, mutexes, condition variables, event flags, message mailboxes, message queues, and so on. Surely, traditional RTOSes provide no shortage of mechanisms to tie the application in a hopeless knot.

Experienced embedded gurus know to be wary of most of the RTOS mechanisms, and strictly build applications around the message-passing paradigm. Strict encapsulation is the name of the game. A task hides all its internal data and resources and communicates with the outside world only by sending and receiving events. Such systems use only a tiny fraction of the RTOS, namely message queues, and have really no need for all the other tricky RTOS mechanisms. Software components designed that way are not only easier to unit-test. They are also safer, more reusable, maintainable, and extensible.

But at this point I need to ask the nagging questions. Why structuring all systems that way is not somehow enforced in the RTOS itself? Why RTOS vendors bend over backwards to keep adding even more ways to couple the tasks?

The second aspect of software development that can make or break any successful Testing strategy is the error and exception handling policy. I’m really amazed how much complexity is added to the code by "defensive programming" techniques that somehow attempt to “handle” erroneous situations that never should have occurred in the first place, like overrunning an array index or dereferencing a NULL-pointer. The problem is that defensive programming hinders Testing... and demoralizes the testers.

You see, defensively written code accepts much wider range of inputs than it should and by doing so hides bugs. Your tests don’t appear to uncover evident errors. Yet such tests don’t build much confidence in the system, because the code might be wondering around all nights and weekends silently sweeping the errors under the rug.

A much better alternative is to confront errors head-on, by liberally using assertions (or more scientifically the Design By Contract philosophy). Testing a piece of code peppered with assertions is an entirely different experience than “defensive” code. Every successful Test run means that the program passed all its assertions. Every Test failure is much harder to dismiss as “not reproducible”, because you have a record in form of a file name and line number where the assertion fired. This information gives you an excellent starting point for understanding and ultimately fixing the bug.

And finally, Testing almost always requires instrumenting the code to give the tester additional visibility into the inner workings of the software. Unfortunately, in many embedded systems even the primitive printf() facility is unavailable (no screen to print to). Obviously, you can do much better than printf() (e.g., see the Quantum Spy software trace facility).

As you can see, Testing in the agile sense requires serious upfront investments and rethinking many of the time-honored embedded practices. You can no longer build a system without accounting for Testing right from the start.

What do you think about agile embedded software development? What do you do to improve Testability of your systems?

What Embedded Programs have to do with Hollywood?

I still remember the "Triumph of the Nerds" PBS special, where Steve Jobs recalled his early days at Apple and how the young Apple team picked up the brains of scientists at the Xerox Palo Alto Research Center (PARC) . Steve explained how PARC researchers showed them three revolutionary things: (1) the graphical user interface (GUI), (2) computer network, and (3) object-oriented programming. Out of these three things, Steve confessed to have understood only the first one at the time. This alone, however, proved enough to launch the Mac, and the rest is history.

I believe that the embedded industry still hasn’t learned from PARC even as much as Apple did some three decades ago. The question standing in my mind is: Why most embedded programs aren’t structured the same way as virtually all GUI programs are?

If you’re baffled why I am comparing embedded systems to GUIs, consider that just about every embedded system, just like every GUI, is predominantly event-driven, by nature. In both cases, the primary function of the system is reacting to events. In the case of embedded systems, the events might be different than GUI (e.g., time ticks or arrivals of data packets), rather than mouse clicks and button presses. But, the essential job is still the same: reacting to events that come at difficult to foresee order and timing.

Even the earliest GUIs, such as the original Mac, or the early-days Windows, were structured according to the "Hollywood principle", which means “Don't call us, we'll call you". The “Hollywood principle” recognizes that the program is not really in control—the events are. So instead of pretending that the program is running the system, the system runs your program by calling your code to process events.

This reversal of control seems natural, I hope, and has served well all GUI systems. However, the concept hasn’t really caught on in the embedded space. The time-honored approaches are still either the “superloop” (main+ISR) or an RTOS, none of which really embodies the “Hollywood principle”.

It really takes more than "just" an API, such as a traditional RTOS. What you typically need is a framework that provides the main body of the application and calls the code that you provide. Such event-driven real-time frameworks are not new. Today, virtually every design automation tool for embedded systems incorporates a variant of such an event-driven framework. The frameworks buried inside tools prove that the concept works very well in very wide range of embedded systems.

My point is that a Real-Time Framework (RTF) should, and I believe eventually will, replace the traditional RTOS. What do you think?