Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
AlmondSauce859833dOh, all the time. There's a certain "macho" factor some devs have about using weird & wonderful features to prove they understand things rather than because it makes the code clearer, and the same factor for over-engineering something hideously just "in case we need to make this major change in the future".
If you have a good code review process, it should knock most of the worst cases of that on the head.
IntrusionCM182333dSimplicity is an art that can be teached.
There are some things that bother me...
- a regular review should have a fixed time frame (this depends heavily on the project)... If there is none, experiment and set one for yourself. Reviewing drains the mental state, without breaks it will take you far longer and be more frustrating than it has to be.
- when you think someone pulled a stunt, talk with him. Please, be nice and gentle, if he / she behaves like an arse, don't step down on their level. There is a lot to learn from each other.
- complicated code can be good. Sometimes it has to be complicated. Document why it has to be this way.
Usually complicated means that someone tried to hard or misunderstood something... Which should be fixed....
Best example here are hand-rolled functions (eg. recreating existing functions, not using new language features and so on). Fixed because especially hand-rolled functions or "stuff reimplemented" tends to be buggy like hell (non obvious corner cases, memory leaks, ...).
So Yeah. I definitely feel ya.
Reviewing complex stuff can be fun when the other programmer isn't an narcisstic arsehole, as one can learn a lot.
If the other programmer is an arsehole, there's usually a lot of frustration, anger and pain involved.