The Novice Expert

The biggest problem in software is bugs. No genius in that statement. No amazing insight into the science of software development. However, in my experiences about 75% of the bugs that I found (written by me or by others) came down to small pieces of code that failed to do their expected, simple tasks.

These days I spend my time working on a large system with a lot of lines of code. We have tight schedules and huge expectations. All the folks on my team are expected to produce code and ensure to the best of their abilities it is bug free. But how can they do that? Simple - we use unit tests.

I was first introduced to the concept of unit testing years ago when working on a medium sized Java project. We used JUnit for our stuff. In order to get up to speed I read Kent Beck’s book Test Driven Development. After a while I was writing what I thought were pretty good unit tests. These would run every time the build server ran or I decided to run them manually. It would test a few points that I wanted to verify. It was good but not even close to what is expected of me now.

In the current software development team every time we add a class or extend an existing one we must add one or more unit tests to the respective test fixture. Every class has a test fixture associated with it. It has been drilled into our heads. In fact, when bouncing through the code, if we find a class without unit tests we go after the guy responsible (in fun way mind you). Just as a point of interest our current system has around 6000 unit tests that we run almost daily. My team consists of 6 people. It is not unusual for us to add 20 to 40 unit tests a week.

The biggest problem we face when writing unit tests is what to test. It is very easy to undershoot or overshoot the unit test goal. You can undershoot it by not testing all the possible code paths that can be traversed in a method. You can overshoot it by verifying that the compiler is doing its job when it creates a new object. The real answer is that you want to test the expectations of every method in your class. To me this implies testing all possible ways your code can be executed. This means the happy paths as well as error paths and exceptions that can be thrown by your methods. One way we balance things is to use a tool that shows what lines of code were hit in a unit test. (We use TestMatrix from ExactMagic).

After spending time using unit tests to ensure my code is functioning as expected I have found it second nature to implement them. In fact I feel weird if I don’t have unit tests for code I’ve written! I can now confidently check in code knowing that, at least at the class or method level, I have verified that my stuff works as I intended. This confidence in our code derived from unit tests has a profound affect on the team. We reach each code complete milestone knowing that we have truly done our best to ensure as many bugs have been eradicated as possible before we hand things over to our QA team.

As I probably have said somewhere in another post I have been working in the software industry for almost 20 years. A great deal of my time has been spent working with C/C++, CSharp and Java. However, along the way I have also learned languages like Python and Perl. I have learned about Tcl/Tk, Objective-C, JavaScript, HTML. I’m in the process of learning Ruby and a few others. There’s a lot to be said about learning more than one language.

When you only know one language you box yourself in. For example, I could solve almost any problem in C/C++. I’ve spent a long time using other add-ons to C/C++ to improve my ability to quickly bring up my code (namely things like STL, WTL, MFC, etc…). However, while C/C++ can do a lot it does not mean it is the right solution for many things these days. In fact, I have switched to doing more CSharp and Java than C++. The reason for this is that these languages are more geared to solving web-based problems.

As I expand my knowledge of a variety of languages I realize that each of them has its purpose in the software space. Some languages are given to performance, others are given to providing simple frameworks to allow quick application/web-service bring-up.

Take-away: Knowing more than one language is crucial in any aspect of the software industry because it allows you to choose the right language to solve a particular problem.

In my current job we do a lot of JavaScript work which makes calls to a web service using monorail. In our products we have a lot of JavaScript objects we pass as request objects to the web service. These requests are subsequently processed and the results are serialized into a new set JavaScript objects. We use JSON for the serializing and de-serializing of the JavaScript objects which result in strings that represent our objects being passed back and forth between the client and server (for more information refer to the JSON site).

Once the strings are on the controller side of the server we have to do a lot of parsing and processing of text we expect to see coming through the JSON de-serializer. When we’re done we have to re-serialize information with some of the same strings used on the de-serializer side. All of this means that we have a lot of commonly used strings.

Managing the large number of strings representing object names and property names on the incoming and outgoing JSON can be quite onerous. For this reason, when handling strings we create a constant variable that represents each necessary string. This means that the string is assigned its text in one place. In all other places where the string is used we use the constant instead. For example, suppose we had an object called RequestObject. We would then have the following code in some well-known file that contains all string constants:

public const string RequestObjectName = "RequestObject"; There are three primary reasons why this is good design. The first two are obvious, but perhaps the third one is not quite so obvious:

• All uses of the RequestObjectName ensure that the string is used consistently across the code base. There won't be errant typos that can cause nasty JavaScript/JSON bugs
• Using string constants means that changing the actual text of the string is simple because it's only done in one place.
• If you make a mistake in typing the name of the constant the compiler will tell you that you have made a mistake. This is not the case if you misspell a string literal.

Take-away: using string constants is beneficial in several ways and should be used when a given string is used in more than one place.

I remember a job way back when where one developer would always look at my code and decide he could do the same job better by simple reducing the number of lines. “Hey JB! I did the same thing as you did but in only 10 lines of code!”. I like to think that he was trying to optimize the performance of my code. But the truth is, what he changed did not make my code faster - only more confusing. To make matters worse (or better if you like the language) this was all done in C. C is a language that lets you get into all sorts of trouble. There’s even a site and competition devoted to this practice: The International Obfuscated C Code Contest. However, in the real world, obfuscating code for the sake of saving lines can be a bad thing.

The Ternary Operator - ?:

The ternary operator ?: is available in many languages - most notably C/C++, CSharp and Java.
The following is an example of the operator:

int finalCount = (list != null) ? list.Count : 0;

As most of you know, the code above says that if list is null then finalCount will get 0, otherwise it will get the value of list.Count. Sounds pretty good and saves a lot of space. So what’s the problem?

My basic problem with the ternary operator is that it is less clear and no faster than the if-else counterpart. Consider the following:

int finalCount = 0; if( list != null ){ finalCount = list.Count; }

To me the latter example is much clearer when first looking at the code. Now consider plowing through hundreds of lines of code. Wouldn’t it be better if small things like the ternary operator were removed in some places to make the surrounding code easier to comprehend quickly?

Don’t get me wrong. The ternary operator has its place. It’s just that, imho, it’s over-used and abused.

Explicitly scope your code

Several languages support some list of implicit features. In many of these languages one of the features is the implicit scoping of a line following statements such as if/else, while, for, etc… An example of this implicit scoping is:

int i; for(i = 0; i < 10; i++) printf("i = %d\n", i);

This is what I consider a dangerous feature of the language. I’ve seen too many cases where a line of code was added that was intended to be included in the for loop. The code ended up being:

int i; for(i = 0; i < 10; i++) printf("i = %d\n", i); fprintf(filePtr, "i = %d\n", i);

However, the second line will not be executed in the for loop. This is because the implicit scoping feature only includes the one line following the for statement. The proper code would be to use braces to explicitly show the intended scoping:

int i; for(i = 0; i < 10; i++){ printf("i = %d\n", i); fprintf(filePtr, "i = %d\n", i); }

Ok, so I’ve shown an example where implicit scoping can lead to a potential bug. But take the first example where only one line existed in the for loop. What is the argument for not explicitly scoping the code in the first place. Again, imho, using the explicit scoping clearly defines the intention and makes the code more readable (plus more easily modified in the future):

int i; for(i = 0; i < 10; i++){ printf("i = %d\n", i); }

Take-away 1: Don’t rely necessarily on cool or implicit features of a language as they can lead to code that is harder than necessary to read (especially by other code spelunkers).

Take-away 2: Ignore this post and other common sense ideas if you want to maintain job security around a code base that only you know.

If you have been working C# you might have come across the ability to create nullable types. The nullable operator ? can be used to allow intrinsic types to have a null value.

The MSDN documentation states the following which is important when evaluating a nullable type:

When performing comparisons with nullable types, if one of the nullable types is null, the comparison is always evaluated to be false. It is therefore important not to assume that because a comparison is false, the opposite case is true.

(click here for the full MSDN documentation on this)

For example, the following shows how an int variable can be assigned the value null:

int? n1 = null; This can be used to make assignment cases easier to do (though not necessarily easier to read): int? c = null; // d = c, unless c is null, in which case d = -1. int d = c ?? -1; The example above is based on the int type. One could argue that the above code is good or bad. However, the real problem of nullable types comes when using a nullable bool (or what folks around me have dubbed the null-a-bool).

The Null-a-Bool

Now let's examine the ability to make a boolean value nullable. To decare a nullable bool the same syntax as that for the int above is used: bool? b = null; Now you can use the following operations for booleans: bool? b = null; // set b to some value if( b != null ){ // b as true or false } Now that I've described how a nullable bool can be used I can pose my question. Why the !@$# whould you ever use a nullable bool!? The purpose of a boolean value is very clear. It has one of TWO possible states - true or false. If the purpose for the nullable bool is for performance - come on! If it's for coding convenience that's a lame excuse. After reading books on writing stable source code and plowing through many code reviews I've learned that anything that gets in the way of clearly understanding what a block of code does is not good. All the nullable bool does is confuse the issue and make code harder to read and understand.

1st Take-away: Do NOT use nullable bools. You can write anything in such a way as to avoid obfuscating the code that someone else will possibly need to understand (unless you're striving for job security). Null-a-bools serve no good purpose that I can determine.

2nd Take-away: Do not fall into the trap of using a feature of a language simply because it exists. Sometimes it's better to keep things simple and straight-forward as possible.

Recently I was shown some C# code that attempted to take a date/time string and convert it to a DateTime object. The following is the method that was written: /// <summary> /// Generates a DateTime from a Month, Day, Year values. /// </summary> /// <param name="Month">A month</param> /// <param name="Day">A day.</param> /// <param name="Year">A year</param> /// <param name="referenceDate"></param> /// <returns></returns> public static DateTime DateFromMonthDayYear(string Month, string Day, string Year) { if (string.IsNullOrEmpty(Month) || string.IsNullOrEmpty(Day) || string.IsNullOrEmpty(Year)){ return DateTime.MinValue; } int MonthInt = Convert.ToInt32(Month); if (MonthInt < 1 || MonthInt > 12) { return DateTime.MinValue; } int DayInt = Convert.ToInt32(Day); if (DayInt < 1 || DayInt > 31) { return DateTime.MinValue; } int YearInt = Convert.ToInt32(Year); if (YearInt < 1900 || YearInt > DateTime.Now.Year) { return DateTime.MinValue; } return new DateTime(YearInt, MonthInt, DayInt); } The problem is not that the code won't work (tho it has issues too). The problem is that the C# DateTime object already has a method to do this: DateTime convertedDate = DateTime.Parse("Thu, 01 May 2008 07:34:42 GMT"); This information was found on MSDN's page of the DateTime class's methods documentation. (Click here to read this documentation).

Take-Away: Refer to the language documentation first to help solve problems. A graceful solution probably exists for most common tasks.

The Novice Expert is now on-line. For information about this site please read the About page. If you have any questions send them our way on the Contact Us page.

Thanks for visiting! - jb