Sadly there is a ton of badly written code out in the wild. Hardware related code, seem to suffer more in this regards. I imagine, many developer in this segment are unwillingly to invest time in quality or are just inexperienced.

Even if you are dedicated in reliable and high quality code, you will probably run into the situation, where you have to use a library with really low standards.

Strategies

There are a number of strategies to deal with this code:

Rewrite the library.
Refactor the code.
Wrap the library.
Wrap the interface.

Rewrite the Library

This is actually the best you can do and it is also the most time-consuming approach. Yet, write the code from scratch will give you several benefits:

You will perfectly understand how the original library and the accessed hardware works. Actually you have to understand it, otherwise you are unable to rewrite the code.
The new code will be modern, fast, reliable and in your coding style.
If you open source the new code, you will give people an alternative and a better example how to implement something the right way.
You can also selectively remove unwanted/bloated parts from the original code, which can reduce the overall binary size of the final project.
It will also give you the option to implement a proper error handling in the new code.

If you have the time and motivation to rewrite the code, do it!

Refactor the Code

Changing the code, without changing the functionality is called code refactoring. This is a good strategy, a compromise, between rewriting and wrapping. Usually you will just go, line by line, through the original code, modernise it and cleaning it up.

First you replace macros (constants, header guards) with modern C++ equivalents.
Next you reformat the whole code and make it readable.
You add missing API documentation.
Now you rename methods and variables in the code in a proper and speaking style.
You split large methods into smaller ones and make everything modular and nice.
etc.

At the end, you will have a library which is modern, readable and therefore easier to handle and use.

Wrap the Library

If you can not bear how something looks, just wrap it nicely. This is a very effective strategy for code. Because the compiler will resolve the wrapper code, there is no disadvantage for this approach.

Often there are macro definitions or other declarations (functions, operators, etc.) in the global namespace which creating troubles in you code. Your wrapper solves all this issues and provide a better API to your code.

The illustration above illustrates the basic principle. Only the wrapper code includes the API of the bad code and has to deal with the problems of it. The rest of your application will access the wrapper, and therefore using proper code.

	// LevelMeter.h:

	#pragma once
	#include <cstdint>

	namespace lr {
	namespace LevelMeter {

	uint8_t getValue();

	}
	}

	// LevelMeter.cpp

	#include "LevelMeter.h" // first!
	#include "haxor_lvl_mtrV9.h" // bad code… 😛

	namespace lr {
	namespace LevelMeter {

	uint8_t getValue()
	{
	struct LVL_METER_VALUE value;
	auto result = haxor_level_mrt_get_value(&value, nullptr, nullptr, nullptr, 1, 8, 9, nullptr);
	if (result != 1) {
	return 0;
	} else {
	return value.z.value.w;
	}
	}

	}
	}

view raw

LevelMeter.cpp

hosted with ❤ by GitHub

In the hypothetical example above, you can see a simple wrapper for a single function. The header LevelMeter.h is clean, proper C++ code. In the implementation of your wrapper, you deal will the dark side and all quirks of the badly written library.

This will not prevent linker problems if there are variables with the same name. Because you properly place your code in namespaces and avoid global variables, you are on the safe side. 😉

Wrap the Interface

As a quick fix it is often helpful just to wrap the interface, speak include file.

	#pragma once
	#include "MCU.h"
	#undef macro1
	#undef macro2
	#undef macro2
	#undef macro2
	#undef macro2

view raw

MCUWrapper.h

hosted with ❤ by GitHub

This is a good solution for complex headers causing problems. Instead of including the original header, you just include the header wrapper. Your wrapper will clean-up (undef) macros after including the bad header file.

Wrapping the interface is only helpful for problems with macro definitions. Strange operators, function or class definitions will still influence your code.

Conclusion

Despair is no strategy. 😉 Take one of the actions above to solve your problems. Never let badly written code influence your own sense of quality and style while writing code. Be a role model! Always show how well written code shall look like.

If you have questions, miss some information or just have any feedback, feel free to add a comment below.

Have fun!

How to Deal with Badly Written Code