---- Colleague's code. Am I allowed to pick holes in it?
rocknbil - 5:57 pm on Oct 5, 2010 (gmt 0)
another developer here at work...
Which is it, friend or co-worker or both? How you approach it depends on the delineation.
... leave it pinned up on our manager's office door?
No! :-) I'll reserve my opinion as to what this would show, just don't. :-) Let's not forget most office printers have hard drives in them, if it came down to it you would be revealed. If you stand behind your convictions, you need to do just that.
As a programmer myself, I *beg* for input on improvement and excellence, anyone who loves what they do would do the same. But first, take a step back . . .
I think it could have been done better.
Ask yourself, does this thought come from your ego or solid facts that you can document and reference? This is a really hard one to face sometimes, if you can reference documentation your case will be much more acceptable than "I think it can be done better." Write them down if you need to. Some good examples might be
- these lines of inline execution code are repeated in several places throughout the application. They would be more useful and can be re-purposed if moved into a single function. - you are doing a textual database query for *this* value when a numeric one on an indexed column would be more efficient. - The redundant use of headers for 1000 pages is difficult to maintain, let's move those into an SSI or PHP include and do redirects to make them easier to modify.
Maybe some specific examples will help members here to provide input on whether you're on the mark or not. An example . . .
Things like using interfaces
When all is said and done, don't confront, call a meeting with everyone and discuss. "Here's what I'm thinking John, this area could use improvement, be more efficient. What does everyone think?" Be open to "no." You may be right, but you may not be.