Clean-Code | While I Compile

Oct 3, 2010 Posted by John MacIntyre

The UI programmers (not so) secret weapon

An Example: Suppose you had software which matches buyers and sellers, and new users are created via a ‘new user’ wizard[1]. Let’s say the wizard has 4 pages for Basic User Info, Review, Processing, and Completion Status Report. And there are 5 buttons; Cancel, Previous, Next, Run, and Finish. Cancel is displayed from the Basic User Info, Review, and Processing pages. Previous is displayed from the Review page. Next is displayed from the Basic User Info page. Run is displayed from the Review page. Finish is displayed from the Completion Status Report page. This isn’t difficult to manage the display from the events[2] right? Well … in reality, it doesn’t take much of a change for your simple display functionality to become … The Problem Manipulating application display during events quickly turns into a complex, bug riddled, difficult to maintain, mess. It may not seem like that big of a deal when you have only a few controls and a very simple (or no) workflow. Actually, you may argue, managing visual display in the events may even seem like the most efficient strategy. After all, you will never display, disable, or otherwise needlessly manipulate a control, but as your application grows more complex, this approach can leave you tearing your hair out[3]. This is especially true when you have multiple execution paths leading to the same event handlers with different state. What if you received a change request for the above requirements, where additional info is required for buyers or sellers, resulting in a new wizard page for each, and in addition to that, business sellers require a page to gather Tax Information? Your complexity has started to grow, resulting in buyers have a workflow of Basic User Info -> Buyer Info -> Review -> Processing -> Completion Status Report Individual sellers have a workflow of Basic User Info -> Individual Seller Info -> Review -> Processing -> Completion Status Report And commercial sellers have a workflow of Basic User Info -> Commercial Seller Info -> Tax Info -> Review -> Processing -> Completion Status Report Notice how these changes lead to different execution paths all arriving at the Review page. The question then, is; where does the back button on the Review page send the user? The back button requires logic to know which wizard page to display. It’s not difficult to imagine the need for logic to be added in more than one place[4], which can result... read more

Sep 14, 2010 Posted by John MacIntyre

What is too simple and small to refactor? (Clean Code Experience No. 2)

Shortly after reading Clean Code, I refactored the data access layer from a project I was working on, and was amazed by how much the code improved. It really was night and day. My first clean code refactoring experience was an obvious improvement.

I was still on that clean code high, when a little function entered my life that I was compelled to refactor. This one left me questioning the limits of what I should refactor and if my refactor even qualified as clean.

I’d like to share that second experience with you in this post.

My Clean Code Experience No. 1 (with before and after code examples)

Public Code Review Robert C. Martin was kind enough to review the code in this post at on his new blog Clean Coder. Be sure to read his review when you finish reading this post. Introduction After expressing an interest in reading Robert C Martin‘s books, one of my Twitter followers was kind enough to give me a copy of Uncle Bob’s book Clean Code as a gift*. This post is about my first refactoring experience after reading it and the code resulting from my first Clean Code refactor. Sample code The code used in this post is based on the data access layer (DAL) used in a side project I’m currently working on. Specifically, my sample project is based on a refactor on the DAL classes for comment data. The CommentData class and surrounding code was simplified for the example, in order to focus on the DAL’s refactoring, rather than the comment functionality. Of course; the comment class could be anything. Download the my clean code refactor sample project (VS2008) Please notice: 1. The database can be generated from the script in the SQL folder 2. This code will probably make the most sense if you step through it 3. This blog post is about 1,700 words, so if you aren’t into reading, you will still get the jist of what I’m saying just from examining the source code. What Clean Code isn’t about Before starting, I want to point out that Clean Code is not about formatting style. While we all have our curly brace positioning preferences, it really is irrelevant. Clean Code strikes at a much deeper level, and although your ‘style’ will be affected tremendously, you won’t find much about formatting style. My original code My original comment DAL class is in the folder called Dirty.Dal, and contains one file called CommentDal.cs containing the CommentDal class. This class is very typical of how I wrote code before reading this book**. The original CommentDal class is 295 lines of code all together and has a handful of well named methods. Now, 295 lines of code is hardly awful, it doesn’t seem very complex relatively speaking, and really, we’ve all seen (and coded) worse. Although the class interface does seem pretty simple, the simplicity of its class diagram hides its code complexity. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25... read more