…Please, namespace and/or prefix your stuff!
I love Spark and how well it works, but as a professional OO software developer I have to say the coding style used in the core and a lot of the community code sends shivers down my spine.
Namespacing is one thing. If you’re writing a library, use C++ and put your stuff in a neat namespace. And if your library has functions which are internal to that library, better yet, do not expose them in the headers. At least don’t pollute the global namespace.
namespace AwesomeLibrary {
int counter;
void doStuff()
{
counter++;
}
}
// Usage:
AwesomeLibrary::doStuff();
And if namespacing isn’t possible for whatever reason, please at least prefix everything that you’re exposing.
int AwesomeLibrary_Counter = 0;
void AwesomeLibrary_DoStuff()
{
AwesomeLibrary_Counter++;
}
The worst offenders here are the numerous enum
s, global functions, and worse yet, #define
s which are dangerously ambiguous and even look exactly like one another. (!!)
This is, honestly, kinda bad:
typedef enum
{
AUTOMATIC = 0, SEMI_AUTOMATIC = 1, MANUAL = 2
} System_Mode_TypeDef;
Firstly, it’s not namespaced. The enum typedef
has a name, but enum
s are not namespaces. All the values go to the global namespace.
Secondly, the values aren’t prefixed. What’s MANUAL? A manual what? A proper, expensive IDE might tell you when you hover over the symbol in your code, but I personally believe code should be readable enough in whatever text editor. A little verbosity is very preferable over constant uncertainty.
Thirdly, they look like preprocessor definitions, although (thankfully) they aren’t. I believe it’s very reasonable practice to reserve fully uppercase naming for preprocessor directives.
Much better (in C++):
namespace Spark {
enum SystemMode {
SystemMode_Automatic = 0,
SystemMode_SemiAutomatic,
SystemMode_Manual
};
}
// Usage like:
Spark_SetSystemMode( Spark::SystemMode_Automatic );
Alright, thank you for reading! Please do not take this as a personal attack of any kind. That is not at all what I’m going for. Every line of code in the Spark ecosystem is precious and much appreciated. This is merely a humble call for what I hope could be better mutual standards of code for long term prosperity.
I hope my writing was concise and reasonable. I’d be happy to discuss and answer any C+±specific questions should anyone have such.