I'm currently reading the second edition of _Code Complete_ from cover-to-cover. More on that later, I'm sure - but for now I'll just say that you should read this right now if you haven't read it already. This is one of those books that you should really just leave by your dev machine.
In any case, Steve McConnell mentions the importance of making code readable throughout the book. This is far from profound, yet in practice I don't see it done very much. Frankly, if you examine your coding practices from a cost-benefit perspective, you'd be hard-pressed to find an instance where this doesn't make sense. It takes so little effort to make your code readable. It could even reduce the likelihood of creating bugs in your code.
The below is a less-than-ideal, contrived example - I think it communicates the point, though. What looks better, this...
protected override void OnLoad(EventArgs e)
{
int NumberOfVacationDays = 0;
if(Employee.Type == EmployeeType.FullTime)
{
if (Employee.Level == EmployeeLevel.Professional)
{
NumberOfVacationDays = 10;
}
if (Employee.Level == EmployeeLevel.Executive)
{
NumberOfVacationDays = 20;
}
}
if(Employee.Type == Employee.PartTime)
{
if(Employee.ExemptStatus == ExemptStatus.Exempt)
{
NumberOfVacationDays = 0;
}
if(Employee.ExemptStatus == ExemptStatus.NonExempt)
{
NumberOfVacationDays = 0;
}
}
}
or...
protected override void OnLoad(EventArgs e)
{
EmployeeType employeeType = New EmployeeType();
int NumberOfVacationDays = GetVacationByEmployeeType(employeeType);
}
//This method doesn't need to be in the same class...only for demo purposes
private int GetVacationByEmployeeType(employeeType)
{...}
Okay. You're either thinking one or more of the following right now:
Q. So what? You didn't reduce any of the code. What does this accomplish?
A. You're right. We haven't reduced code. In fact, we have done the exact opposite. We have reduced the perceived complexity though, because when Sam from down the hall needs to add some functionality in 4 months he'll know exactly what is being done without having to _mentally parse_ any code. Yes, of course he can read a few simple if blocks and deduce what's happening - there just isn't a reason to do this.
Q. You're adding more code and this could make the program perform worse.
A. In the most performance critical application (Hello NASA employees), maybe. For 99.9999% of us, you are not going to see improvements by reducing method calls. We're doing the logic somewhere and adding a method to the stack really won't change your life. I can prove it on an abacus.
Q. Okay, that's more readable...do I gain any other benefits?
A. Yes. You gain the gratification of knowing you've done something correctly. You really shouldn't have business rules/logic embedded in your event. What happens when you want to use the same logic in some other class/method/file/spacecraft? You're out of luck. It's easy to never think about this...or assume you'll never need to use this logic anywhere else. If that's the case, you should part out the logic into its own private, local method. That way if you ever need to reuse the method you can change the access modifier and move it to a class where it makes a little more sense.
As a additional side note, you should never ever have the business rule evaluation logic [as shown in the first example] in more than one location. If that's the case, you'll need to make changes all over place when the business rules change. And trust me, they're going to change.