Open EveryNameIsTakenEvenThisOne opened 5 years ago
ENITETO is absolutely right. Style is subjective, so name your variables whatever you want. However, while everyone no doubt loves the hyper-terse, nonstandard, language-replacing syntax, preprocessor macros used to the extent seen in k.h
are near-universally seen as bad practice and are thus avoided. In theory, adding #include "k.h"
could completely change behavior in completely unrelated code elsewhere. This really, really goes against good practice in C++.
I concur. We have to be extremely careful when using k.h from C++. The way it stomps all over the global namespace is really problematic. In practice what we normally have to do is make is make a wrapper header that #undefs O, R, Z, P, etc and everything else we don't use.
I find it highly doubtful that any end users are going to make any use of things such as #define R return
in their own code. Perhaps we could have a cut down k.h that just includes the essentials.
I think we need a k-core.h
which does not include any macro of single character to make it easier to be used in real world projects. The old k.h
can still include k-core.h
to avoid code duplication.
The deliberate obfuscation of using single uppercase characters as macro names instead of meaningful identifiers makes it impossible to comingle k.h with any reasonable C++ program that uses templates in which template parameters are single letters such as T and U, which are extremely prevalent in the STL and in Boost and is generally accepted good practice for C++.