good chemistry is complicated, and a little bit messy -LW |
|
PerlMonks |
Re: Silly code reviews and shiftby footpad (Abbot) |
on Jan 18, 2001 at 20:09 UTC ( [id://52787]=note: print w/replies, xml ) | Need Help?? |
I've found code reviews to be either excellent learning opportunities or exercises in political motivation.
As an example of the latter, I was once dinged in a performance review because I didn't "adhere to the organization's coding standards," as expressed in a third-party book authored by the company's owners. (Clearly, this wasn't Perl.) The main point under contention involved consistent use of capitalization, e.g. source formatting. The language in question used keywords to delineate blocks. In the example given, it was an IF/ENDIF block. I got dinged 10% (out of 100) because I typed "if...EndIf", instead of "if...endIf". (No, it wasn't any form of BASIC.) I lost another 10% because I didn't properly lock all the files being referenced. (The reviewer conveniently ignored the fact that I'd been after him to clarify his views on proper locking techniques for the previous nine months.) Of course, the whole exercise was really a way for the owner to justify a less than reasonable salary increase. This became even more apparent when the partner showed the reviewer several examples from "the book" where similar typos were made. It didn't have any effect on the review or my increase. I shortly left the organization. My point being that you should take code reviews in the spirit that they are given. If code reviews (and standards compliance) are part of your performance review, then you'd best make certain you do what you can to follow them. On the other hand, if they're meant as the educational opportunities that they were originally intended to be *and* performed by people you respect, then you'd best take any comments to heart. If you're part of a code review process, then it might be wise to think twice before flagging code as questionable. After all, there are (often) multiple ways to write an algorithm and that a certain amount of latitude needs to be made for personal style, knowledge, and coding practices. Mind you, I'm not referring to the most major blunders, such as not tainting, ignoring strict, or avoiding warnings. I'm referring to the little stuff (e.g. capitalization flaws, indenting three spaces instead of two, placing the opening brace of a block on the next line instead of the line initiating the block, and so on.) Finally, if you're a manager who uses code reviews as part of your performance review process, I would strongly suggest you:
In the end, individual programmers needs to find ways to balance personal style against the organization's needs for reliability, consistency, readability, and maintainability. On one hand, it's not worth trashing your opportunities inside an organization due to a stylistic difference of opinion. On the other hand, if you're constantly frustrated because you're trying to follow standards that strike you as superior to the ones in your organziation, then it may be time to either a) try to improve the local standards or b) consider different opportunities. Life's too short to be continually frustrated. --f
In Section
Meditations
|
|