This is not the kind of information you will learn at university or a conference. This can change your professional attitude, so read on.
From the very beginning of our programming education we are talked into thinking like a compiler. We gradually develop the thinking that in order to write a decent piece of code we need to ask ourselves questions like these below:
- how is this thing going to be evaluated by the computer?
- will this index ever go out of array boundary?
- can this variable overflow under any circumstances?
- will this statement correctly modify / concatenate / process these numbers / strings?
- is it then this pointer that is going to point at the result when the function returns?
While I recognize genuine reasons why people think they should turn their compiler mode on while working, I also think there is more value in asking ourselves completely different questions, like these below:
- does the piece of code I've just written remind me of any of the code smells I read about?
- will it confuse others when they need to read it or modify it?
- is there feature of my code that would be error prone to others when they modify it?
- is my function / method design going to cause, indirectly, code duplication or other code smells in other parts of the codebase?
- have I covered this piece of code with Unit Tests to the extent that nobody is afraid of modifying it in the future?
- do I still see a potential for refactoring?
I'm not blaming the laymen though - after all that's the attitude that is expected and required of everybody at universities and then when applying for a job and even later when one already has years of experience...
But now you can no longer claim you didn't know. Tomorrow, when you sit at your desk, do something to advance in your professional career: when you write a piece of code, ask yourselves questions from the second list.