The last couple of code reviews of my work lately have turned up some common code smells: function names that don't adequately reflect behavior; misplaced functions; and sub-par function decomposition.
I don't think I'm the only developer afflicted with the bad naming, since it's one of the two hardest things in computer science. However, the function placement and improper decomposition are a signal to me that I have a clarity problem.
I've been building software for almost 12 years, and I take my coding very seriously. I'm pretty sure I have OCD tendencies, especially when it comes to code. Ever have to shut off your car when you realize that the emblem on your key is facing the wrong way? I have :).
My desk is littered with programming books like Pragmatic Programming, The Practice of Programming, Clean Code, Refactoring, and Domain Driven Design. But despite my years of development and many programming books I've read, I still find software development challenging.
Writing simple, clear code is hard. It takes a lot of practice to get good at.
I think that in order to write clear code, you need to have clarity. You need to get your mind right.
In general I code using a make it work, make it right, make it fast approach. When I'm starting a new feature, I start out by roughing in a working prototype, to determine roughly what code needs to be written, and where it needs to go. At this point, I'm not really concerned with naming things, since it's still a sketch, that will change many times. I don't want to waste a lot of times to come up with good names during the first pass.
For me, the code is too viscous at this point to spend a lot of time on names, since functions are being added, renamed, removed often. I give rough names, pretty much the first name that comes to mind, because it's most likely going to change anyway.
After getting the prototype feature complete and all tests passing, I start refactoring, cleaning up the design, eliminating SOLID violations, duplicated code, etc. Once I'm satisfied with the overall look of the code, I get a code review.
My last couple of reviews of my work turned up the same problem. Lack of clarity. Primarily function names don't do what you would expect just reading the name. Ward Cunningham definition of clean code, code that does pretty much what you expect it to, is always in the back of my mind. The problem seems to be that the function name meets this criteria to me, but not to someone else.
Having the clarity discussion during code reviews has resulted in better intention revealing names.
In general I code using a make it work, make it right, make it fast approach. When I'm starting a new feature, I start out by roughing in a working prototype, to determine roughly what code needs to be written, and where it needs to go. At this point, I'm not really concerned with naming things, since it's still a sketch, that will change many times. I don't want to waste a lot of times to come up with good names during the first pass.
For me, the code is too viscous at this point to spend a lot of time on names, since functions are being added, renamed, removed often. I give rough names, pretty much the first name that comes to mind, because it's most likely going to change anyway.
After getting the prototype feature complete and all tests passing, I start refactoring, cleaning up the design, eliminating SOLID violations, duplicated code, etc. Once I'm satisfied with the overall look of the code, I get a code review.
My last couple of reviews of my work turned up the same problem. Lack of clarity. Primarily function names don't do what you would expect just reading the name. Ward Cunningham definition of clean code, code that does pretty much what you expect it to, is always in the back of my mind. The problem seems to be that the function name meets this criteria to me, but not to someone else.
Having the clarity discussion during code reviews has resulted in better intention revealing names.
Comments
Post a Comment