Geeks With Blogs
Dave Chestnutt: SparklingCode and CodeGaffes Writing better code; for fun and profit CodeGaffes Coding Practices - both good and bad.
Look to understand the reasons why these are recommended or bad. In a sense, these are like design patterns, only in miniature. By and large, they apply to all three languages, C#, Java, and C++.
Path.Combine() - parameters are mis-named
The CLR is full of surprises. Microsoft has a built-in System.IO.Path class, to deal with all the path parsing issues we often run across. One of the most useful methods in there can get rid of all the special case code we write to combine path strings. How many times have you written something like this to combine two path strings -- taking into account whether you need to add a slash between the path strings or not: String path1 = @"C:\ABC"; // may or may not end in a slash String path2 = @"DEF"; ......

Posted On Tuesday, March 13, 2007 4:09 PM

CodeGaffe: Copy & Paste (and ReSharper to the rescue)
I use a coding tool called ReSharper - and I was pleasantly surprised the other day when it pointed out a copy & paste bug that was waiting to explode. You see, copy and paste programming is so very easy to do - that we all do it. Even the best of us accidentally leave in duplicate code snippets from time to time. Why Cut & Paste is so bad There are two big reasons why this is an anti-pattern: If the code you cut and pasted has a bug in it (and it invariably will), what do you think are the ......

Posted On Monday, December 11, 2006 12:22 PM

Intentional Programming
Christopher Diggins has an interesting post on Intentional Programming. This is a new way of applying top-down design. It's a very good idea: you write your code nice and clear, with calls to sub-methods that "do the right thing" - sub-methods that you'll write later. The advantage of this is that your code will be quite readable. And since our code always lasts much longer than we ever intended, clear readable code is more maintainable (and likely to haveless bugs, too). An idea well worth thinking ......

Posted On Thursday, November 9, 2006 10:28 AM

CodeGaffe: Checking for Null Fields is BAD
The other day, I had to fix a particularly nasty bug with a NullReferenceException. During the process, I came up with a couple alternatives to fix it and decided to document why Checking for Null Fields is BAD Technorati tags: CodeGaffes, Geekswithblogs ......

Posted On Saturday, October 21, 2006 5:10 PM

CodeGaffe: Commented Out Code
We all have old code snippets in our code base. Whether it’s a method that’s no longer used, or a few lines that we’ve replaced - our code has sections commented out. When should we remove them? How should we comment them out? If you’re not careful, commented out code can cause future problems. Read on. Code Gaffe #1: Sneaky Commented out code Commented out code should be, well, really commented out. Really comment it out Don't put a /* at the top and */ at the bottom of code you want to remove: ......

Posted On Sunday, August 20, 2006 4:16 PM

SparklingCode: Count the cost with Line Numbers
One of the benefits of using modern editors is that it's really easy to navigate your code base. If you're looking at a method call, for example, you can use a keystroke combination to jump to the method definition. But there's a drawback to this. If you're not careful, as you add new code you can end up with monster methods, or monster-sized classes. Let me ask you this - what do you think the maximum size of a class should be? 100 lines? 500 lines? 10,000 lines? While we won't agree on an exact ......

Posted On Monday, January 30, 2006 6:46 PM

CodeGaffe: Clueless Comments - Never Say Never
I was fixing a bug the other day, when I ran across this comment (marked in red): if (condition1){ //… some useful code …}else if (condition2){ //… some useful code …}else{ // this can never happen} My first thought was, if this can never happen then why not throw an exception in case it does? So I added a line to throw an exception. if (condition1){ //… some useful code …}else if (condition2){ //… some useful code …}else{ // this can never happen throw new ApplicationException("this can never happen");} ......

Posted On Wednesday, January 18, 2006 5:45 PM

CodeGaffe: Avoid .NET “partial” classes in C# and VB
Microsoft added a new keyword to C# and VB for 2005 (CLR 2.0): partial Don't use it. partial is used to physically break up a class definition into multiple files. When the compiler sees the keyword partial it finds all the related partial files in order to compile the class. This makes it possible to split the code for a single class across multiple files. By and large, though, this is a bad idea. Let’s look at why that is. If you find yourself typing"p-a-r-t-i-a-l" Stop! Reasons Given To Use the ......

Posted On Wednesday, April 5, 2006 6:34 PM

CodeGaffe: Really Private Data
Today's CodeGaffe is something I see all the time. It creeps into your code over time. Here's the scenario: Your class has grown from its humble beginnings, and there are now fields in your class that should not be used by some of your methods. In essence, you want some of your data to be private from part of your class. As in "really private". If you've ever found yourself thinking, "Most of this class shouldn't access field foo,” then you've experienced this. Here's an example I ran across recently ......

Posted On Thursday, February 16, 2006 8:10 PM

CodeGaffe: Surprising Assignments
This CodeGaffe covers two similar problems. The first one involves Booleans, while the second covers any variable type. Here's some code that contains 2 bugs in one line. This is a practice to avoid. Can you spot the 2 bugs? if (m_condition = true) { // *** DON'T DO THIS! // do something} If you had any trouble spotting the problem, that's because you're normal. And if you didn't have any trouble, that's because you were looking for a problem. If you didn't know there was anything wrong with that ......

Posted On Monday, February 6, 2006 5:35 PM

Copyright © Dave Chestnutt | Powered by: