A Caught Return

[ad_1]

When John takes on a new codebase, he always looks for low-risk ways to learn the code by changing it. Things like beefing up the unit tests, tracking down warnings that have been left to languish, minor quality-of-life changes.

Well, a few years back, John inherited some C# code, and started tracking down some warnings. That lead to this method.

private void ClearAllFields()
{
	bool bReturn = false;
	try
	{
		bReturn = true;
	}
	catch (ApplicationException)
	{
		throw;
	}
	catch
	{
		throw;
	}
}

This doesn't ClearAllFields. It doesn't clear any fields. It doesn't do anything. I especially love the bReturn variable in a void method. I love the bonus exception handlers for an operation that couldn't throw an exception.

This kind of uselessness is scattered all over the codebase. Some of it may be vestigial- it used to do something, but gradually got whittled down to uselessness. Some of it likely was premature- they intended the method to eventually do something, but never got around to it. They certainly didn't track what was and wasn't implemented. The result is a minefield of half-finished, half-working code, where you never know if what you touch is going to cause problems later.

[ad_2]

Remy Porter

Source link