Did you know that when you are dealing with numbers, by default, .NET will do, or try to do exactly what you tell it to do? If you tell it to do the impossible, it will do the next most logical thing. It won’t throw any errors in the process.
No, neither did I. But then, most of the time I don’t write code where this would matter, and I bet you don’t either.
So here are some examples.
When my kids were young, my wife introduced a concept for this question that she got from her family that is so brilliant in its simplicity that I wonder that this isn’t common knowledge with all parents. Something they should tell you during Lamaze class. When the kids asked, “Are we there yet?” Which they did very infrequently, we would answer, “Just a few more units.” If you think about it, it is just about as helpful as any other answer we could have given them, “Just a few more hours.”, “Just a few more miles.”, “Sure, get out of the car.” (While continuing to drive the car down the road.) Or “Does it look like we are there yet?” What does the child want to know? Nothing, they are just expressing their displeasure at still being in the car.
A couple of weeks ago, I talked a bit about how we name things. Specifically, I talked about the very bad habit of using the variables i, j, and k as variables in our for/next loops. A few weeks before that, I talked about DRY Programming and the fact that not repeating ourselves extends much farther than most of us normally think when we are thinking about our code. Today I want to continue on the general theme of code quality by discussing code complexity.
That’s what I kept asking myself every time I saw this product. Well, the last time I looked, something caught my eye enough that I decided to download it and take a look. I’m really glad I did it. So, let me attempt to explain what SpecFlow is. First, while you can get SpecFlow+ Runner to run your test, this isn’t a completely new testing platform. Instead, it is a testing platform that works with whatever testing platform you are using to test your .NET code. So, it works with NUnit, MSTest, xUnit and MbUnit. This is good for my situation because any test I write with SpecFlow will continue to work with the tools I already have in place. Including my current test runners (ReSharper) and my Continuous Integration system (TeamCity). I wasn’t interested in adopting a platform that wouldn’t work with these two platforms.
One of the hardest things we do as programmers is naming things. But the easiest thing to name is counter variables and most of us do it wrong several times a day. Of course, I’m talking about the notorious habit of naming our counter variables I, J, or K depending on how far down we’ve nested our looping.
Today I thought I’d talk to you about the programming principle known as DRY. As you may know, DRY stands for “Don’t Repeat Yourself” and it shows up in a lot more places than you might expect. Even when you try really, really hard to not repeat yourself, you end up repeating yourself. You repeat yourself even when you think you aren’t. Lots of people repeat themselves. Do you know of any? Ok. I think you get the point. Just like it is silly for me to repeat myself over and over again, it is silly for you to write the same code, or perform the same steps, over and over again.
To drive the point home just a little bit more. Do you know what the acronym WET stands for? We Enjoy Typing. While it doesn’t capture all of what DRY is trying to combat, I think it hits about 80% of the issue. Have you typed something that is really similar to something you already typed?
I recently had an experience writing code that proved to me, once again, that using Test Driven Development really is faster than the way I have been working. You will remember a couple of weeks ago I presented a strategy for creating test scenarios where we need to test storing data to a database from a web page.
I used to ignore warnings when I compiled my code. Most of the time they never caused any problems and I was able to run my code. But recently I’ve gotten pickier about my code. One area I’ve gotten more picky about is compiler warnings.
Any code that I have direct control over now compiles cleanly. No errors and no warnings. This past week I found a perfect example of why. Given the following code:
With all this talk of test driven development, one has to naturally ask, “Where does the QA department fit in? Do they even have a role in the organization any more?” Well, the answer to that is, “absolutely but probably not the role they think they have.”
First, at the suggestion of one of my friends who now works at SmartBear, I’m going to experiment with creating audio of my post going forward. Obviously this will lend itself to some of my post more than others, but I think it is worth experimenting with. Those of you who’ve been with me since the early days remember that I use to produce YouTube videos occasionally. I haven’t done that in a while because the post production process for videos takes so long. I’m hoping that I don’t run into the same problem with producing audio. Anyhow, the point of creating the audio is that many of you don’t have time to read, but would have time to listen to something on the way to work. Assuming this experiment works out, you should be able to listen to the content on this blog during your commute, or anywhere else you are likely to listen to audio. If you’d rather listen to this post, you can scroll to the bottom of this post and click the “Play” button.