Mar 1, 2012 Posted by John MacIntyre

My take on identifier semantics (Id vs No vs Code vs Key)

My simple conventions for these popular identifier names. I don’t believe they’re all the same, and should be used under different circumstances.

read more

Feb 24, 2012 Posted by John MacIntyre

Discovering Typemock

Frustration mocking static methods, the ridiculous hoops I was forced to jump through, and the clean implementation I was finally able to do with Typemock.

read more

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.

read more

Sep 10, 2010 Posted by John MacIntyre

Procedure Like Object Oriented Programming

In a previous post What’s wrong with the Nouns/Adjective/Verb object oriented design strategy, I talked about how verbs should be implemented in their own separate class instead of as a method strapped onto an entity class. In my opinion, it’s an appropriate way to work with processes and pass those processes around, while keeping code flexible, testable, and highly maintainable. But it has led to comments on Twitter and a link to one of Steve Yegge’s post Execution in the Kingdom of Nouns. Basically, Steve said that turning verbs into nouns was a bad idea (at least that’s what I think he was getting at, there were a lot of metaphors in there :-). It’s easy to see Yegge’s point of view, if you just leave it at that. After all turning your single line of code accessing those actions 1 commentData.Insert(cn);commentData.Insert(cn); into multiple lines of calling code, when you move the logic into its own class, 1 2 3 4 using (CommentInsertCommand insCmd = new CommentInsertCommand(cn)) { insCmd.Execute(commentData); }using (CommentInsertCommand insCmd = new CommentInsertCommand(cn)) { insCmd.Execute(commentData); } definitely sucks. So why not add a static method to the process class so you can access it with a single, procedural like, call? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 public class CommentInsertCommand : IDisposable { ....   public static void Execute(CommentData commentData, int userId, SqlConnection cn) { ValidateCommentParameter(commentData); using (CommentInsertCommand insCmd = new CommentInsertCommand(cn)) { commentData.CommentId = insCmd.Execute(commentData, userId); } }   protected static void ValidateCommentParameter(CommentData commentData) {...} }public class CommentInsertCommand : IDisposable { .... public static void Execute(CommentData commentData, int userId, SqlConnection cn) { ValidateCommentParameter(commentData); using (CommentInsertCommand insCmd = new CommentInsertCommand(cn)) { commentData.CommentId = insCmd.Execute(commentData, userId); } } protected static void ValidateCommentParameter(CommentData commentData) {...} } This way your call is reduced to 1 CommentInsertCommand.Execute(data, cn);CommentInsertCommand.Execute(data, cn); I think this has merit and is a clean way to manage your classes. It brings your object oriented code back to a more procedural level. One problem I haven’t quite figured out yet is the naming. To be honest, I’m a little uneasy about it. I should probably name it ‘Insert’, but that’s redundant with the class name and I’m not crazy about naming it ‘Execute’ or ‘Run’ either. I chose ‘Execute’ in this example so all XXXXCommand classes would be consistent across the application, and the name is consistent with the SqlCommand naming which is important since this class kind of emulates... read more

Jul 2, 2010 Posted by John MacIntyre

Visual Studio Bug – ‘if’ followed by a try / catch causes debugger stepping error

Yesterday I was debugging and stepped into a method. I wanted to get past my parameter validation checks and into the meat of the method, so I quickly, F10’d my way down the method, but I noticed a line of code was stepped on which should not have been touched. The code was a simple parameter validation like: 1 2 if (enumerableObj == null) throw new ArgumentNullException("enumerableObj");if (enumerableObj == null) throw new ArgumentNullException("enumerableObj"); with several similar parameter validation lines above it and a try/catch block containing the meat of the method below it. The odd thing was, I thought I saw the debugger step on the throw statement even though the enumerableObj should have had a value. I assumed I had somehow passed in a null value to the enumerableObj parameter and had nearly missed the problem in my haste. I had been moving quickly, so quickly in fact that I had stepped about 3 more lines into the method before I even stopped. To be honest at this point, I wasn’t even sure if I saw it step into the ‘if’ block, so I repositioned my debug cursor back to the ‘if’ condition, and stepped again. Sure enough, it stepped into the ‘if’ block. I assumed I passed in a null parameter, but when I evaluated enumerableObj, it was set, what’s more, evaluating the entire enumerableObj == null expression resulted in false, as expected. But why the heck was I being stepped into the ‘if’ block when the ‘if’ condition was false? I retried it again, just in case the enumerableObj had somehow been set as a result of a side effect somewhere, but even then, it still stepped into the ‘if’ block. So, I did the standard stuff; cleaned my solution, deleted my bin and obj directories, reopening the solution, restarted Visual Studio, & rebooted, all the while rebuilding and retesting the project with each change. Nothing seemed to work. I even cut & pasted my code into notepad, then cut & pasted from notepad back into Visual Studio to ensure there was no hidden characters in my files.* None of this worked, so I started commenting out code in the method, and eventually was able to isolate it to the above code failing if, and only if, it was followed by a try / catch block. Seriously! If the try / catch block was there, it would step onto the throw statement even though it should... read more

Mar 29, 2010 Posted by John MacIntyre

Hey #region haters; Why all the fuss?

I hear a lot of programmers saying #regions are a code smell. From programmers I don’t know to celebrity programmers, while the development community appears to be passionately split.* The haters definitely have a point about it being used to hide ugly code, but when I open a class and see this, it just looks elegant to me. Now none of these regions are hiding thousands of lines of ugly code, actually, most of these regions contain only 3 properties and/or methods and the last curly brace is on line 299. So the whole thing with 17 properties and methods including comments and whitespace is only 300 LOC. … really, how much of a mess could I possibly be hiding? To me, the only question is whether I should have this functionality in the ContainerPageBase or the MasterPageBase**. You may also notice the regions I have are not of the Fields / Constructors / Events / Properties / Methods variety. It has taken some time for me to accept that all data members (aka fields) do not need to be at the top of the class as I was classically trained to do and that perhaps grouping them by functionality is a better idea. This philosophy only makes regions that much more valuable. … is anybody still here? …. have I converted anyone? 😉 * These posts are fairly old, but in my experience in the developer community; the consensus hasn’t changed. ** The Database Connection & Current User regions may have some scratching their heads. There are valid reasons for them, however the Data Connection region will never be included at this level again. More on that in a future post. Copyright © John MacIntyre 2010, All rights... read more

Mar 17, 2010 Posted by John MacIntyre

7 Features I Wish C# Had

…I couldn’t come up with 10 things I hate about C#, so I’m going to settle for 7 features I’d like to see. There may be good reasons why we don’t have some of them, but here’s my list anyway…

read more