| ""Do X, Y, and Z and your code will improve" is something only managers believe" The thing is, it is absolutely correct for some definitions of X, Y and Z. There are plenty of programmers in the workplace who just suck at constructing code. They don't know how to write good comments, format their code logically and consistently, use good variable and function names, etc. It goes even further: they do not understand why these things are important. I still see plenty of code like this: bool nothingToDo; // Is there anything to do .... if (nothingToDo)
{ // We don't need to continue
return;
}or if (time.elapsed() > 10) // If ten seconds or more have passed {...} Requests to refactor such code are often met with "This is trivial, just step through the code and figure it out", sometimes from senior programmers (at least in title). And these are not necessarily stupid people, they are often good programmers but not very good software engineers. Have you ever read some of the code open sourced by Google and found yourself thinking "Sheetz, this code is ultra clean"? I bet the people responsible for Google's coding guidelines have read Code Complete. I have been involved in writing coding standards a few times and I referred to Code Complete in each of those instances. I also completely disagree that this book was written for managers. A manager with no technical background is very likely to dismiss refactoring or code layout as wasted time. |
But they're very likely to throw the biggest "guaranteed to improve code" book they can find, with the biggest company name on it they can find (Microsoft), at all the programmers under them, whether or not it makes sense. And they're more likely to use the book dogmatically, rather than pragmatically, and much of the book seems structured to encourage this use.