Pointer to functions

[KevinHall]

I might, it depends on the situation. But at least the post-increment operator or pre-increment operator have a meaning behind their use. It is not pointless to use either one of them. you could not just omit one of them entirely from a situation and still get them same result. Using void to indicate no parameters in C++ is a huge waste of time and code space, which leads me to my next point...

But pre- and post- increment operators are different in that there is a real run-time difference. There are many people who use post-increment operators all the time in for loops:

for (int i=0; i<max_value; i++)

but then use the same syntax for iterators:

for (my_containter::iterator it=aContainer.begin(); it!=aContainer.end(); it++)

but this has hidden run-time penalties. See this FAQ for more information.

Studies have shown that fixing run-time problems after development are 10 to 1000 times more expensive than problems caught at development time (I'd put 'void' in the latter case since there is no run-time difference.) Thus any problem related to pre- and post- increment operators can be immensely more expensive than 'void'.

Now, I'm all about following Knuth's law, but this is an optimization that can be easily avoided by following the right style. My recomendation: Only use post-increment operators where the code is cleaner by using them.

That being said, I wouldn't refuse to hire someone because the code they developed in the past used too many post-increments. I might mention the problems during an interview and see if they would be willing to change the way they code. Regardless, I would show them the project's coding style document before they started developing and make sure to note the pre- vs. post- increment section and then expect them to follow the style guide thereafter.

I will even take this one step further. Let's say somehow a programmer did get hired into my company that did this without me knowing. After a while, I would notice he used such notation. I would keep track, over the weekly/bi-weekly pay period, of how many times he used the word void in a no argument function signature. Then, I would figure out on average how long it takes him to type void each time. I would multiply the two together to find out how much total time he has wasted typing void in such situations, multiply it by his hourly rate, and deduct it from his paycheck.

That sounds very exteme to me. This should be easily taken care of by showing the programmer a document outlining the code style guidelines for the project. Mistakes will happen, but you correct him (or her). But if after time, they cannot follow directions, then that represents a deeper problem -- and that problem I would be unwilling to work with long-term.

I am sure others feel the same way, but about other aspects of the language. Like people using void main() instead of int main(), etc, etc. It's just the way I feel about it.

I don't think there should ever be a single style-related restriction to hiring someone. If the developer is talented -- they should be able to adapt to new guidelines. Follow up on that. If, in the interview, they explain that they won't follow any other guidelines than their own, then yes, don't hire them. But people can and do adapt.

- Kevin