I wasn’t talking about the UI.
The UI is ane entirely different matter to the code itself.
The author doesn’t necessarily have to understand the words on the UI,
those can be translated as required.
But the author absolutely has to understand the code.
My point was that anything involving writing code in a foreign language is going to be difficult for the author to get their head around,
so while changing the names to something full length seems trivial for someone who speaks that foreign language (i.e. English),
it’s a lot less trivial for the person for whom it is a foreign language.
If I was writing a game where the variable names were in Japanese I could understand chosing to write (for example) コンシス instead of コンピューターシステム, because the latter would take me much longer to write and would be harder to remember.
Also I use a Japanese IME (input method editor) installed to be able to write hiragana and katakana,
so I suspect the reverse would be true for someone who writes primarily in Japanese.
I could be wrong, perhaps Japanese keyboards have an easier way to type English than western keyboards do for typing Japanese.
I could be underestimating @BlueMax’s understanding of English,
but I’d rather underestimate than overestimate.
It’s generally less effort for me to simplify my explanations than it is for non-native English speakers to understand colloquialisms, idioms, appreviations and esoteric technical language.
There are several main reasons for using
constexpr for constants:
- Explicit typing
- Macros do tend to have a type, but it’s less obvious, you have to check with
decltype if you want to know what the type is
- More self-documenting
- Macros are used for lots of strange things, but a
constexpr variable is only ever going to be a
constexpr variable, so it’s purpose is immediately obvious
- Scoping rules
- Macros don’t obey scoping rules because they only exist at tte preprocesing stage, the compiler itself never even sees the macros. This results in what I like to call ‘macro poisoning’ - you write a macro once and it infects the whole program. For an example, when I was writing FixedPoints, I had to write
roundFixed because I couldn’t write a function called
round because the Arduino writers made
round a macro.
- Can’t be redefined
- Macros can be redefined part way through a program, which can cause issues, whilst variables can only be defined once thanks to the one definition rule
- Better error messages
- As mentioned earlier, macros are replaced at the preprocessor stage, so by the time you get an error message the macro has already been substituted, which can result in some cryptic errors in some cases. With
constexpr variables this isn’t a problem, you get the proper variable name
constexpr fixes the shortcomings of plain
- In particular, you can’t
constexpr variable and
constexpr variables can be used in constant expression contexts, like template arguments and array dimension declarations.
A fine example of why
.ino files are a crime against humanity.
Ah, that would make sense. I had a feeling it was another item, but couldn’t see what.