Writing better code; for fun and profit
There are 9 entries for the tag
CodeGaffes
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 ......
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: ......
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 ......
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 ......
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 ......
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 ......
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");} ......
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 ......
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 ......