I’m planning to get my MCSD certification next and the first exam I plan to take is the 70-483 which will test my knowledge of CSharp. To study, I got this free PDF: MCSD Certification Toolkit (Exam 70-483) (Which I wouldn’t recommend, but I haven’t found anything yet that I WOULD recommend, so this will have to do.) In this book (Chapter 5) and other places on the web, it makes this statement:
Dave's Notebook
Defining “Done”
A couple of weeks ago, I mention “definition of done” which many of my readers may have never heard of before. The phrase, “definition of done” comes out of the agile movement. But there is no reason why it needs to stay there. In fact, I would argue that many of the problems we have in the software industry are because most organizations only have one definition of done, “If we ship this today, can we make money?” When the Agile people talk about “definition of done” what they ultimately mean is, “if we were to ship this product today,and someone were to inspect what we’ve done, would we be embarrassed?” Definition of done, is about the quality of the code. When thinking about the definition of done, here are some items you might consider.
CSharp Numeric Overflows
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.
Are We There Yet?
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.
Avoiding Code Complexity
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.
What is SpecFlow…
…And why do I want it?
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.
I, J, and K Should Die
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.
DRY Programming
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?
TDD Saves Time – A Story
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.
Treat Warnings As Errors
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: