Tagged: Best Practices

When to abort a thread

When is it OK to abort a thread is a question that comes up every so often. Usually everyone jumps on the bandwagon that you should never ever do a thread abort, but I don’t agree. Certainly there are times when it’s valid and if you understand what you are doing then it’s ok to use.

The reasoning behind never using thread abort is because calling abort on a thread issues an asynchronous exception, meaning that exceptions could happen where you think there never should be exceptions such as dispose methods or finally blocks. This post describes what happens with thread abort and I found it to be a good read.

But, I still don’t think you should never use thread abort. The big issue is what if you don’t have access to the code that is running in the thread? If a 3rd party library is blocking your app … Read more

Configure all the things

I personally think that just about everything should be configurable, unless it’s absolutely never going to change. Even then, make it configurable, because it may change in the future. Think about your favorite command line tools, and the extensibility they have. They’re powerful because they are dynamic. They can be configured for a myriad of options and scenarios.

Configuration doesn’t just imply things that are public to users, like the background color or autosave frequency, but it can expose non-compile time settings that help you tune your application to unknown environments. Most software can’t possibly be tested in every environment that it will be used. However, if you make your code flexible and configurable, you can minimize damage and buy yourself some time when things go bad. You can possibly even find a configuration that works around the problem. Configuration can improve someone’s experience by modifying assumptions you made while … Read more

Run with real data

This article was originally published at tech.blinemedical.com

More often than not the test data in development environments is full of garbage. Most applications have a baseline set of test data, just enough to get the database to function. As engineers develop they tend to make heavy use of “asdf” and “dfkkfklkasdflsaf,” combined with a liberal sprinkling of lorem ipsum and other nonsense, to populate new data. This is fine to get started, since frequently as you develop you need to wipe the dataset clean and start over but this false data gives an incorrect view of the applications interface and performance. No client is going to have 5 “asdf” fields as their data. Instead, visible fields get stressed and assumptions about how your application handles data are challenged. You may not have expected a particular combobox to display a 200 character item, but that’s … Read more