-
Notifications
You must be signed in to change notification settings - Fork 191
Description
In digging thought the code while debugging my usage of it, I've noticed a number of oddities that seem like things that could easily be cleaned up to improve the code readability.
Would PR's doing general cleaning be welcomed and actively supported?
In general, I think the sort of cleanup described below would improve the code by both making it more readable as well as by making it shorter (in a few cases, by a lot), but it would also be rather invasive in that it would likely touch a significant faction of the code which could cause merge conflicts and the like. That said, most everything I've see would be highly local and simple so any merge conflicts would likely be relatively trivial.
Examples:
- Inconsistent formatting:
The formatting style is rather non-uniform (e.g. if() and if () are both used, function argument sometimes skip spaces after the comma, most lines are under 80col but a few hundred are not, etc.). With tools like clang-format, it should be a rather mechanical task to identify the most prevalent patterns and apply them globally.
- Pre/post C++11 idioms:
The code uses post C++11 features like std::move() but also makes extensive uses of patterns rendered obsolete by C++11, in particular; iterator for loops rather than range for.
- Others:
- redundant lookups:
if (m.count(k)) return m[k];vs
auto i = m.get(); if (i != m.end()) return i->second;) - redundant constructor definitions (e.g. where
= defaultwould have the same effect) - redundant actions in destructor (clearing a
std::mapthat is about to it self be destructed). - etc.
- redundant lookups:
These are just the ones I've seen so far and I suspect if I dig, I'd find more: