Change Details

Hi guys, I noticed the bitcoin sources inherited a rather questionable habit of using the postfix increment/decrement (VAR++/VAR--) EVERYWHERE. This is considered a rather poor habit in C++ circles and makes the code look less than awesome. For simple types like ints this shouldn't be a problem on modern compilers because they *should* optimize away the temporary rvalue created. However, for more complex types like iterators it can be a problem. As well as when switching out simple types for objects that implement operator++/operator--. In general, in C++, it's always been considered best practice to use pre-increment EVERYWHERE as it's a good habit to get into. As such, I was quite surprised when I saw that the bitcoin core developers hadn't heard of such a thing. I would like to some day (perhaps soon, after the hard fork?), run through all the sources with a massive regex search and manually (making sure nothing breaks!) switch all instances of VAR++/VAR-- to ++VAR/--VAR whenever it's equivalent to do so. This is in the spirit of promoting best practices in the codebase and to not make bitcoin look like amateur hour (which for the most part it isn't). And, going forward, we should strive to always use pre-increment unless the post-increment is actually needed for the logic of the code. So, I am creating a task for it, and I even volunteer to do it when the dust settles and no other high priority dev is going on (I await your ok to do it, basically). Thanks!

Hi guys, I noticed the bitcoin sources inherited a rather questionable habit of using the postfix increment/decrement (VAR++/VAR--) EVERYWHERE. This is considered a rather poor habit in C++ circles and makes the code look less than awesome. For simple types like ints this shouldn't be a problem on modern compilers because they *should* optimize away the temporary rvalue created. However, for more complex types like iterators it can be a problem. As well as when switching out simple types for objects that implement operator++/operator--. In general, in C++, it's always been considered best practice to use pre-increment EVERYWHERE as it's a good habit to get into. As such, I was quite surprised when I saw that the bitcoin core developers hadn't heard of such a thing. I would like to some day (perhaps soon, after the hard fork?), run through all the sources with a massive regex search and manually (making sure nothing breaks!) switch all instances of VAR++/VAR-- to ++VAR/--VAR whenever it's equivalent to do so. This is in the spirit of promoting best practices in the codebase and to make bitcoin not look like amateur hour (which for the most part it isn't). And, going forward, we should strive to always use pre-increment unless the post-increment is actually needed for the logic of the code. So, I am creating a task for it, and I even volunteer to do it when the dust settles and no other high priority dev is going on (I await your ok to do it, basically). Thanks!

Hi guys, I noticed the bitcoin sources inherited a rather questionable habit of using the postfix increment/decrement (VAR++/VAR--) EVERYWHERE. This is considered a rather poor habit in C++ circles and makes the code look less than awesome. For simple types like ints this shouldn't be a problem on modern compilers because they *should* optimize away the temporary rvalue created. However, for more complex types like iterators it can be a problem. As well as when switching out simple types for objects that implement operator++/operator--. In general, in C++, it's always been considered best practice to use pre-increment EVERYWHERE as it's a good habit to get into. As such, I was quite surprised when I saw that the bitcoin core developers hadn't heard of such a thing. I would like to some day (perhaps soon, after the hard fork?), run through all the sources with a massive regex search and manually (making sure nothing breaks!) switch all instances of VAR++/VAR-- to ++VAR/--VAR whenever it's equivalent to do so. This is in the spirit of promoting best practices in the codebase and to not make bitcoinn not look like amateur hour (which for the most part it isn't). And, going forward, we should strive to always use pre-increment unless the post-increment is actually needed for the logic of the code. So, I am creating a task for it, and I even volunteer to do it when the dust settles and no other high priority dev is going on (I await your ok to do it, basically). Thanks!