1. Setters that do more than SET
All property setters should validate their input and set the value of other properties. This will remove the burden of validation from other developers.
private string _id;
public string Id
{
get
{
return _id;
}
set
{
_id = value.ToString();
_AnotherPropertyValue = value.ToString();
}
}
private string _AnotherPropertyValue;
public string PropertyValue
{
get
{
return _AnotherPropertyValue;
}
set
{
_AnotherPropertyValue = value;
}
}
Workaround: Property getters and setters should only save and return values. Getters and setters should not validate against null, perform regular expression checks, or typecast. Additional logic can take place in business logic classes. Setters that do more than set also cause issues during unit testing. What goes in, must come out.
2. The Golden Hammer
Whenever implementing something new, remember the last successful (or similar) experience and reuse. There is no doubt about it. What worked for you in the past, will continue to work for you now.
Workaround: With the Golden Hammer approach, your solution is the hammer and every project you come up against is a nail. If you find yourself trying to implement an exact replica of a solution that you built in the past, chances are that you will miss some requirements or pigeonhole yourself into somewhere you do not want to be. Instead, step back, learn what the functionality of the system must be, and compare/contrast the differences between past experiences.
3. Swiss Army Class
Just as in bloated class, minimize how many separate classes your code must deal with. If you know all of the different functional areas your application needs to cover, extract them to an interface. Using interfaces will allow you to switch out the implementation types without changing your code. Just make sure that you keep your number of implementation classes low so that it is more maintainable. If necessary, make the lone class implement every interface in the project.
Workaround: Focus on keeping the implementation of your classes very specific to single units. If you feel the need to implement multiple interfaces to create a hybrid of a few simple interfaces, this is perfectly acceptable.
4. Yet Another Damn Layer
Encapsulation is one of the greatest features of object oriented programming. If you can find a way to make existing code more generic so as to make it easier for implementation efforts (and less code writing!) you should do so. Create a generic interface that will take care of defining all of the different functionality in one call.
Workaround: Encapsulation should be used to hide any of the internal mechanisms of a separate software component. Good examples of this are code that is used to perform common tasks such as logging, serialization, or instrumentation metrics.
5. Unit Testing and Stale Data
Since testing is usually a hassle to go through, try and spend as little time doing it as possible. It already takes long enough to set up the tests and the test data. Try not to worry about clearing out the test data since it is only in the development environment.
Workaround: Unit tests should take care of setting themselves up and tearing themselves down. Unit testing should and can be a full-time job position as it should account for every possible variation of data input and output that can occur. If you can not write your unit tests to clean their test data up, then they should use in-memory data providers so as not to impact any other users in the same environment.
* DISCLAIMER * Please note that my views are that of the Workaround type method and this article is meant to prove humor at what can go wrong when unsafe practices are used. Also keep in mind, I’ve probably done each and one of these plenty of times in my career.
Important lesson for those who prefer using GUIDs as record identifiers.
