Too Many Dependencies
You know you have too many dependencies when you find yourself writing code that looks like this:
public Helper Helper {
get { return Helper; }
}
You know you have too many dependencies when you find yourself writing code that looks like this:
public Helper Helper {
get { return Helper; }
}
One of the coveted principles in the programming arena these days is the DRY Principle. DRY simply means “Do not Repeat Yourself.� In other words, if you find that you’re writing the same code constructs over and over, it should probably be abstracted into a separate callable construct.
Yesterday I was discussing this with a friend and he indicated that he likes hard and fast rules. For him, if the same piece of code appears three times, he refactors his code and keeps things DRY. (Refactoring and DRY are often two sides of the same coin.) Standards like this are helpful because they keep things from being interpritive—subject to any indivdual programmer’s feeling on the matter.
I have a saying I will often use when discussing standards.
“The value from having the standard is greater than the standard itself.�
What does this mean? Simply, a bad standard is better than no standard at all. It matters less what you decide to standardize on, than the fact that you have those standards and they drive your team.
If you find areas of your development process that aren’t well defined or subject to interpretation, try to put some teeth to it. Figure out what works for your team and get things spelled out in a concrete way. A wiki is an excellent tool for collecting all of this type of information. Don’t let the process hamstring you, but get it consolidated and in one place and build on it over time.