Geekswithblogs
There are 14 entries for the tag Geekswithblogs
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...
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...
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...
A Null Reference Exception bug is reported. You check the code and find the problem happened because a public field wasn't set. You avoid the bug by modifying the code to check for a null. And you make it home in time for dinner. Original Code: myClass.MyField.MyMethod(); // Gets NullReferenceException on MyField “Corrected” Code: // Avoids NPEif ( myClass.MyField != null ) { myClass.MyField.MyMethod();} Seems like a reasonable solution. But guess what–this is nearly always the...
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 http://geekswithblogs.net/d... Technorati tags: CodeGaffes, Geekswithblogs...
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...
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...
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...