Remembering some obscure code, even if the code looks clean and short, you still can’t say anything about it without a test. What about that?
#include "my_library.h"
int main() {
double my_data = 36.7;
my_library::do_some_useful_work_with( my_data );
}
Say, you trust the person who wrote my_library.h and compile and run. Imagine, my_library is full of complex template-metaprogramming – the person is a genious anyway. And the code is clean, you can clearly understand what my_library::do_some_useful_work does – it clearly states so. But Then, your program somehow fails to works as expected. You look under the hood and see:
HideousHack() {
// Downloading the whole internet
// …
// Allocating a static 120TB buffer
// something else you’re surprised to see
}
// … extras
};
#define double HideousHack
[/cpp]
That’s just when you can still run through this one header. But if you’re including something more elaborate, consisting of recursive includes of obscure or generated library parts?
If you include (import, use, load …) something untested or something you can’t test easily, there’s no point in thinking, you know what’s happening from simply reading the code.
The solution strategy? Don’t trust, test if it’s important.
