Background: I\'m working on an application that will manage backup generators. T
ID: 644867 • Letter: B
Question
Background: I'm working on an application that will manage backup generators. These generators need to be able to be "linked" together. For example, Generator B might serve as a backup for Generator A. If A fails, then the software turns B on. Or they might be linked in a load-sharing configuration, where Generator A and B run together, and share the load.
I'm making a function that will make the link, given 2 generators and the type of link desired.
public void LinkGenerators(Generator A, Generator B, Type linkType);
In writing my tests, I've come with a large number of invalid parameter configurations. My LinkGenerators function looks like this:
public void LinkGenerators(Generator A, Generator B, Type linkType)
{
if (linkType.BaseType != typeof(Link))
{
throw new ArgumentException("linkType is not a valid link type");
}
if (linkAlreadyExistsFor(A, B))
{
throw new InvalidOperationException("Link for A and B already exists");
}
if (A.Equals(B) || B.Equals(A))
{
throw new InvalidOperationException("A and B cannot be the same generator");
}
if (A == null || B == null || linkType == null)
{
throw new ArgumentException("Cannot pass a null argument");
}
.....
//Actually make the link after making sure all the arguments are valid.
}
Most of the LinkGenerator functions consists of verifying that the parameters are good. The actual link creation takes 2 lines of code. There's a bit of business logic (verifying that link doesn't already exist and that the generators are not the same) mixed in with a bit functional logic (making sure that the linkType derives from Link, arguments aren't null...), and makes me.......uncomfortable.
Is a long list of parameter checks an anti-pattern or a code smell? And if so, what can one do about it?
(Just to make this clear to close-voters probably misunderstanding the question: this is not a question about "coding style for conditions" like this one).
Explanation / Answer
When you need to check conditions that aren't business rules, that's where it gets suspect and a bit smelly. I try to avoid those where possible.
Some of your tests seem suspect:
if (linkType.BaseType != typeof(Link))
This looks like a check that should be made by the type system. i.e. its a type restriction and ideally your function signature should, as much as possible, only accept parameters of the correct type. How to do that depends on more details of what you are doing.
if (A.Equals(B) || B.Equals(A))
Why do you feel the need to check it both ways? If A.Equals(B) != B.Equals(A) you are in for a world of hurt.
if (A == null || B == null || linkType == null)
There is no way to tell which parameter was null from the resulting exception. It's also done after the other checks which means that you probably already caused an exception trying to dereference a null parameter.
I avoid null checks in general. Typically, they aren't that helpful because the code in question will end up throwing an exception after tripping on the null anyways and I haven't gained anything by strewing null checks throughout my code. If you do insist on a null check, I suggest extracting it into a utility function.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.