I consider legibility to be one of the main goals of a code. Maybe your boss won’t agree with me at a first glance but, believe me, he should. Hours and hours of development are spent recklessly only to understand what another simple minded, careless programmer did. And sometimes it’s worse, because this programmer was you a couple of days ago.
I strongly believe that the goal of a code should be simple small functions doing exactly what they’re supposed to, no more, no less, as Einstein said “Make everything as simple as possible, but not simpler.”. Nicely named variables and functions, predicting each step of the logic, telling a nice story, following an impecable and consistent indentation. A code that in a blink of an eye you can notice that someone really cared about.
It’s almost impossible that when doing a code review you’ll agree 100% with the code someone else did. You always have your way of doing things, and usually they’re better, aren’t they? But still, even if you approve the code, you’ll probably finish thinking that you’d rather name a variable differently, or used other function to perform the same task, with the excuse of performance or legibility.. Yeah, we’ve all been there..
My suggestion is to always to code review your own codes. And then to code review it again, and again. Improve your code to a point you can’t imagine what else to change, and take it as a challenge.
The same way you’d change a lot of somebody else’s code, change yours, before somebody else does. Pursuit the goal of having someone doing a code review and being unable to improve it, not even indentation or naming. It’s gratifying.
This is really a hell of a job, and one could argue that it is unachievable, but it is surely a great path to improve your skills.
When suggestions arise, and they will arise, they’ll be better improvements to your software craftsmanship toolbox. And that is easy to see, because if you do have a code where you can’t imagine what else to improve, the simple task of convincing you to change something will be naturally harder, and good arguments will be necessary.
So instead of finishing the code review thinking “Yeah, I could have done the code this way, but I just didn’t want to..”, be honest with yourself and finish it learning something new, something that you won’t let happen the next time.