Can you do better than returning a bool?

It’s very common to write functions that do something or check something and then return “ok” or “failed”.

When writing such functions one’s instinct is often to return a bool value. Let’s think of some hardware that monitors a digital input coming from a switch which is active when a valve is open.

We might declare the function as follows:

bool ValveLimitSwitchIsActive(void);

This is a sensible choice, the digital input can only be either active or inactive (any other condition must be a hardware failure) and our function matches this physical reality.

But what about if we want to check if the valve is open? We could declare a function as follows:

bool ValveIsOpen(void);

Great! we can now start to write code that works with the valve, using this function as required. All looks good? Perhaps not. Perhaps we have an operation on our plant which demands that the valve is definitely energised (could be safety critical) as well as being fully open. Perhaps we also want to monitor how long it takes for the valve to actually open. We could generate more functions:

bool ValveIsFullyOpenAndEnergised(void);
bool ValveIsEnergised(void);

but it all gets a bit messy….

How about

enum class TValveState {FullyClosed, Closing, Opening, FullyOpen};
// Opening == energised but not yet reached fully open limit switch

TValveState GetValveState(void);

This is good because all the valve checking is in one place. If the design of the valve interface changes we only have to modify this one function.

This still has good clear legibility at when the function is called; no one can be confused by:

if (GetValveState(void) == FullyClosed) { // do something here }

Because of this form of calling, the same technique is also very useful when dealing with functions that are harder to name in such a way that a bool return value makes sense. Consider a database update. We could have a function

bool UpdateDatabase(…); // returns true if update was successful

We call this using:

if (UpdateDatabase(…)) { // do something here – task }

This works, but if you come back to this code do you know if the task is executed if the update was successful, or if it was unsuccessful? The only way to be sure is to back to the body of the function UpdateDatabase – very bad from a programming maintenance perspective.

A simple improvement would be to write

bool UpdateDatabaseWasSuccessful(…)

but now you have a function name that suggests a status check on the database, it rather hides the fact that an action is actually carried out.

Much better is to use:

enum class TDatabaseUpdateResult {UpdatedOk, FailedToUpdate};

TDatabaseUpdateResult UpdateDatabase(…);

Now the call is fairly concise and very clear:

if (UpdateDatabase(…) == UpdatedOk) { // do something here – task }

Again, if we later decide to return more error information (perhaps different reasons why the update failed) we can simply add extra enum names.

We could even change the enum to a full blown class and return this, if we needed to.

It’s a good technique: use it!

Advertisements

Embarcadero RAD Studio Rio 10.3.1 is here !

Embarcadero have just announced the availability of RAD Studio Rio 10.3.1. This follows (fairly) hot on the heals of Rio 10.3 which was released in Nov 2019

This release has some minor new additions but is basically a bug fix release. You have to uninstall 10.3 and then install 10.3.1 using the same type of installer (either ISO or www) that you originally used for the 10.3 install.

Registered users can use the following download links

RAD Studio Rio

Delphi Rio

C++ Builder Rio

The “Community Edition” (free of charge (subject to restrictions on use) version) is available at

C++ Builder Rio Community Edition

Delphi Rio Community Edition

Where is Android in the World?

Jim McKeith has recently posted a webinar replay called “Get the most out of Android with 10.3 Rio”. It’s worth watching and it’s at.

Get the most out of Android with 10.3 Rio

In the webinar Jim points out that Android is now the most used operating system in the world (in terms of numbers of devices it is installed on). He also points out that Samsung are much more involved in the control and steering of Android then many people realise (most folk just assume Android = Google).

Samsung have the “Dex” scheme (short for “Desktop Experience”) which allows users to quickly and effectively turn their smart phone into a desktop PC. Clearly another attempt at encouraging the world to drop Windows.

What does all this mean to software developers?

The short answer is that any new projects that are likely to be “on going” (and professionally developed software that isn’t aiming to be “on going” is a contradiction in terms) should be designed with a view to migration from one platform to another being a genuine consideration.

How to Design a Good UI?

One could write books on this subject (and people have done so). Of course what is good for one person may not be seen as such by someone else. This is particularly so when designing UIs to be used by people with little or no familiarity with the digital world.

One of the problems is that a good UI is also a moving target.

I used to advocate Windows applications as being easy to use if you just followed the simple rules:

1) Tell the computer what you “thing” you want to do something to, by selecting it (often a single click with the mouse or a click and drag).

2) Right click and pick what you want to do with the pop up menu.

This scheme used to work with all good Windows applications. Sadly this uniform approach has gone and users (particularly those in the “addicted to mobiles” category) seem to be happy with the chaotic “every application has it’s own way” approach.

Thinking and planning the basic approach to your UI design must be sensible. I find that David Millington’s three postings about this subject are a good succinct set of documents to read and consider before starting a new project.

David Millington’s Good UI Design – part 1

David Millington’s Good UI Design – part 2

David Millington’s Good UI Design – part 3

Is C++ a rigorously typed language?

One of the recent Embarcadero “CodeRage 2018” webinars was about some of the features in C++ 17.

This included some talk about the “auto” key word and associated encouragement to use it. I’m less convinced about using this in a carefree manner. When you declare a variable or (in C++ 17) a return value who is the sensible person to choose what type it is? The compiler or you?

It’s a great typing saver when you are declaring an iterator for one of the standard library containers (eg a vector). So use it for this.

But I’m not so sure about using it in cases where some careless modification of code might unintentionally change the type of a variable or return value. I feel (because I am used to it) that the strong rigorous typing enforced by earlier C++ standards (before the introduction of the “auto” keyword) is an advantage of the language not a disadvantage.

So yes, use “auto” but only WITH CARE.

Embarcadero RAD Studio Rio 10.3 is here!

Embarcadero have just announced the availability of RAD Studio Rio 10.3. The road map published this summer promised this before the end of the year so they have delivered on time.

 This release has many major new features and enhancements. I talk more about this release in future postings here, but in the meantime to see “what’s new” information have a look at this link.

What’s new in Rio 10.3

More good things about Embarcadero C++ and Delphi Community Edition.

I mentioned the release of the free version of the Embarcadero C++ or Delphi development environment back on 19th July 2018.

This version is free to most people who make litte or no money from s/w development. There are full details of the precise license restrictions at the download links at the bottom of this posting.

This has gone down very well with hobbyists and open source enthusiasts and also allows “start up” companies to get going with a professional s/w development IDE and only have to pay when they start to make some genuine income.

Since it’s release two other advantages have occured to me.

a) Customers who are worried about ongoing support their software that I have supplied, should my company suddenly collapse (or be taken over) can now get hold of a genuine copy of community edition and can prove to themselves that the source code package I am supplying can actually be compiled and linked by someone else. I’ve always known this but now they can check for themselves. [This only applies to customers who are not in the software development business of course, but this applies to all of my company’s customers (that’s why they use my company)].

b) Anyone applying for a job at my company can now be asked to get a copy of Community Edition and be asked to develop or debug code using their copy as part of our interveiw/selection process.

Community Edition is great: Here are the links, if you are new to Embarcadero products go get it now!

C++ Builder Community Edition

Delphi (object pascal) Community Edition

Embarcadero release updated product “road map”

Embarcadero continue to add innovative features to their RAD Studio (C++ Builder and Delphi) product. They have just released an updated product road map which shows their plans for the rest of 2018 and the start of 2019.

 The introduction of C++ 17 support and the improved support for high DPI screens are two of the many features mentioned.

 For full details of the road map go to

Road map (Aug 2018)

For convenience we reproduce a copy of the road map here:

EmbarcaderoRoadMapAug2018

Embarcadero release free C++ and Delphi IDE for students, home users and open source.

Embarcadero have anounced new editions of their C++ IDE and Delphi IDE. Known as “Community Edition” these are free licensed versions of the “Professional edition” for students, home users, open source developers and anyone who programs but does not generate an income. There are accurate details of the restrictions on use at the links below.

 This is a very positive move by Embarcadero. It makes it easy for anyone to experience first hand the quality of their products. It can’t help but increase the popularity of the Embarcadero C++ and Delphi programming environments.

 Here are the links, if you are new to Embarcadero products go get it now!

 C++ Community Edition

Delphi (object pascal) Community Edition

Error codes from functions

Many functions in third party libraries, APIs or in your own code often return some kind of error indication as to the success or otherwise of the function call.

Always check errors when a library (or other) function returns an error (even if you are going to ignore it !).

Why do we make this statement? For all the following reasons.

a) It documents in your source code the fact that the function returns an error (you may decide to check this later).

b) It makes it easier to check the error status when you are debugging your code as/when it doesn’t work.

c) It makes it easier to add error checking at a later date.

d) It encourages you to think “should I be really ignoring the error code returned by a function” at the time that you write your code. In most cases the answer to this question is probably “no”. Checking errors almost always adds little to code complexity and often saves time in the long run.