A C++ Software Development Tip – * = multiply and pointer

When developing C++ code it is very common to declare a pointer to a variable of a specific type (either as a local variable, a class member or (hopefully more rarely) a global variable.

Consider the following two exactly equivalent lines

TMyType *Variable; // no space between the * and the variable – *** preferred ***

TMyType * Variable; // space between the * and the variable

Similarly when using the value pointed to (dereferencing) consider the following two exactly equivalent lines

TMyType X = *Variable; // no space between the * and the variable – *** preferred ***

TMyType X = * Variable; // space between the * and the variable

In each case we prefer the first of the two lines. Why? because the second form looks too much like the multiply operator (z = x * y).

It is very important to be consistent throughout all your code. Knowing that we always use the first form allows us to use a search on “*Variable” and find ALL the instances where the pointer is dereferenced.

 

Advertisements

A Note For Managers – How To Manager Software Engineers

If I have a person sawing a log for me and it takes them three quarters of an hour to saw through three quarters of a log I can reasonably assume that it will take an hour to finish the job. Given this information I can also assume that if there are ten logs that require sawing and one is done each day (so the person sawing is fresh each time) then each day I need to allocate one hour to the sawing task.

How can we software engineers explain to our managers that software development is not like sawing a log?

Firstly it’s exceedingly hard to know how far through the software you are at a given time.

Secondly you can’t usually predict when the next time consuming challenge is going to hit you. Some parts of a design may go smoothly but then the development may uncover something that had not previously been considered and the sensible engineering solution may well be to re-write (or at least refactor) some of the earlier design that may have been considered “finished”.

With larger projects this unpredictably does tend to even out so that you can (with experience) make estimates of the time needed to get a software system to a point where it is useable.

But I’ve just been asked how long will it take me to fix an issue with a particular type of output on a particular type of device. Once I find how to make the change it will be a ten minute fix. But how can I estimate how long it will take to find (or even if it is actually possible?). How much of the device manual will I have to read and understand in order to find the correct method to achieve the result ? And how much of the code will need to be redesigned to accommodate the required change(s)? And if the documentation is poor (as it usually is) how much experimenting / testing will be required to get it working?

So what do I do ? Quote a short delivery time and then look a fool (and perhaps upset the customer’s planned schedule) if it takes three times as long as I said ? or quote a long delivery time and get the reaction “how long? just to do that simple job! ”. Best is to try to get managers to read and consider this blog !

A Software Development Tip – !!!

When developing code it is a frequent occurance that you write something as a quick “get it to compile” fix whilst your mind is focused on the key part on which you are working.

Let me offer an example. Whilst developing a TCP/IP interface to a set of remote digital and analogue i/o you come across a need for a function to extract a set of characters that are specific within a string. You might quickly write a function with a prototype:

String ExtractSpecificCharactersFromString(String IncomingString);

 In order to keep going on the main code you are writing on you may quickly write a dummy function body:

 String ExtractSpecificCharactersFromString(String IncomingString)
{
  return String(“D0=0xf5c9”);
}

 This allows your code to compile and it retuns a sample data String that allows you to start testing your code, all of which is good!

 But there is a real danger that “dummy” code like this can get left in genuine code for too long. You end up creating your own bug: “I am sure that digital output byte is set to 0xf500, so why does it keep reading as “0xf5c9?”

 Having wasted time as a younger programmer chasing these self inflicted bugs I have adopted a procedure where I reserve a comment statement with three consecutive ’!’ characters specifically for tagging code that is still to be written. For the above example create the function body as:

 String ExtractSpecificCharactersFromString(String IncomingString)
{
  return String(“D0=0xf5c9”); // !!! still to be written
}

 Then at regular “low concentration” moments you can go back to the code and search for the character string ”!!!! in “all project files” (using the Embarcadero C++ search terminology here) and quickly find all examples of dummy code where you know further work is required.

 I chose ”!!!” for this task as it is a string which is exceedingly unlikely to appear in genuine C++ code. Choose something else if you like but whatever you choose stick with it!