Geeks With Blogs
Dave Chestnutt: SparklingCode and CodeGaffes Writing better code; for fun and profit CodeGaffes There are 9 entries for the tag CodeGaffes
Perseverance – or – how to stop whining and embrace unit testing
We’ve all heard the mantra – Unit Testing is good for the soul. We hear about the goodness of things like JUnit, NUnit, and TDD from other people. But you’re not convinced. After all, it takes more time to write unit test code – and you’d rather get on with the next feature. Besides, whether it’s true or not, you certainly feel like your progress is measured by how many features you crank out. In my own journey, I found I went through three distinct stages to testing heaven. Look at my “diary” for ......

Posted On Saturday, March 28, 2009 2:43 AM

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

Gotcha! Visual Studio Pre/Post-Build Events
Visual Studio has a nifty feature called Pre-Build and Post-Build events. These are used to include extra DOS commands before or after the build. But there's a gotcha! And it will bite you when you least expect it. In Visual Studio, there is NO ERROR CHECKING except at the end of an event. Any errors that happen prior to the final step are lost. Keep reading to see a workaround. Setting Build Events Build Events are accessed by right-clicking on a Project in the solution explorer and choosing "Build ......

Posted On Tuesday, May 30, 2006 11:23 AM

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

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: Unreinforced Concrete Classes
One of the benefits of object oriented design, is that some problems show up during compile-time instead of at run-time. And you know that run-time issues always show up at the worst possible time, like at a customer site. This CodeGaffe happens when a programmer writes code that "enforces" something with comments, or Assertions. Have you ever seen a method defined in a base class with a comment or Assertion telling you to override it? Of course, if the subclass doesn't override it, you can be certain ......

Posted On Monday, January 16, 2006 4:51 PM

What are CodeGaffes?
In my company, I've been able to join various projects over the years. As a result, I'm usually modifying or adding to legacy code. Of course, in reality, all code is legacy code after about a week. In looking at code (written by others as well as myself) I sometimes see bad coding practices. These are always obvious in hindsight. In the spirit of blogging, I'm going to share these as CodeGaffes. Look to understand the reason why these are bad, as well as how to fix or avoid them. In a sense, these ......

Posted On Monday, January 16, 2006 4:26 PM

Copyright © Dave Chestnutt | Powered by: