It's been about a month since I made a post about code review, so I thought I'd continue along that line a little further. I'm going to talk about some more stuff that I'm doing before actually submitting my code for review.

First off, I've been reading a book call Clean Code, and it has had a lot of good information on ways to improve your coding. To some seasoned developers, it all probably seems a little obvious. To less experienced developers, it probably seems incredibly over-specific. No matter which end of the spectrum you are on, it is still worth a read.

One of the more interesting concepts I got from the book is that our code should read like a narrative. That sounds kind of weird doesn't it? How can I make my code read like a narrative? It's simple actually (in understanding at least, but harder to put into practice). All of the code should make sense to the person reading the code, and things should be pretty much where you expect them to be. Simple right? Of course...

Try considering how you get there though as the coder/programmer/contstructor/etc. It's not obvious while you're writing it. The first step is understanding that your code well go through multiple drafts, much like a writing an essay or a blog post. Odds are, you'll end up writing all of the code in one place to make your fix or implement something new. In college or maybe to an inexperienced dev, "That's good enough. It works. Onto the next thing." A good writer never releases their first draft out, just like how a good developer never releases their initial draft as final code. There are exceptions to this, such as your one-line-fixes, but most siginificant and difficult work will have multiple drafts.

So I've made my first draft. Now I will start analyzing the code that I've put into my program. How many lines have I added to this function? Is this function still only doing one thing? Is the level of abstraction the same as other calls within the function? Do my variables names make sense? Should I make a new class out of anything? Is there any duplication? How many functions should this code be turned into? 

Woah, Boris! Calm down! Why am I being so anal about this? Because I have to be. My code needs to make sense, and it has to flow appropriately. I need to be able to look at this months down the line and understand what is going on. Simplifying the code by adding more functions with fewer lines should also make it easier to fix bugs down the line. When I need to deal with stack traces, it will also make it easier to identify what is going on.

It's an extreme attention to detail that will really improve the code. Now, when I'm looking at another developer's code, I look for these sorts of things. I will let them know if I don't like their variable names. For the love of god, please never use the name temp as a variable name! A name like temp proves you don't understand what you are coding. Even if it's a scratch variable, give a meaningful name. I digress...

Ultimately, this kind of all boils down to one thing. How much do you care about your work? How much do you care about this art? You can look at code where someone has been meticulous, and it inherently shows that they care about what they are making. It's something to be proud of and something others will admire. 

Write the narrative. Read it yourself. Share it with other developers. Give this a shot. See how it goes. It's not easy, but the legwork in the front makes things easier later on.