Is it really any point in creating a method with one line in the body

  • Thread starter Thread starter Tony Johansson
  • Start date Start date
T

Tony Johansson

Hello!

Assume you have this statement
total = total + item.Quantity * UnitPrice;
in a loop and it occurs in several places in the code.
Is it then any point for example to create a method with only one singe line
of code like this one
private static double GetItemTotal(int quantity, double unitPrice
{
return quantity * unitPrice;
}

With this method you get this statement instead.
total = total + GetItemTotal(quantity ,unitPrice);

I just want you opinion about this.

//Tony
 
You can either encapsulate it, or if you need that logic more than once,
have it "spread out" all over the place multiple times.

The cost of software isn't development, its maintenance.

Repeat for emphasis:

The cost of software isn't development, its maintenance.


So when you're logic changes and you need to throw in sales tax (in your
dummy example)....you can either go 1 place to fix it, or you can go to N
number of places to fix it.
 
Is it then any point for example to create a method with only one singe
line of code like this one
Click to expand...

Absolutely. Even trivial code that's duplicated multiple times is asking to
be encapsulated (and can save you headaches later).
 
Assume you have this statement
total = total + item.Quantity * UnitPrice;
in a loop and it occurs in several places in the code.
Is it then any point for example to create a method with only one singe
line of code like this one
private static double GetItemTotal(int quantity, double unitPrice
{
return quantity * unitPrice;
}

With this method you get this statement instead.
total = total + GetItemTotal(quantity ,unitPrice);

I just want you opinion about this.
Click to expand...

I don't blindly subscribe to the "methods must be less than one screenful of
code" theory, personally, so I would not create a method simply to reduce
the size of another method. My main indicator as to whether I should pull a
piece of code out into its own method is simple: Will it be called more than
once?
 
Absolutely. Even trivial code that's duplicated multiple times is
asking to be encapsulated (and can save you headaches later).
Click to expand...

Furthermore, the JIT (or interpreter, for platforms that don't yet have
a JIT) can perform certain optimizations such as inlining of very short
methods, when inlining would be more efficient than a method
invocation. This permits you to spend a few seconds worth of time to
make code more readable by humans, and the environment will know what
to do with it.

Such methods are also useful when you have complex cases that you have
to evaluate within an if() or while(); instead of:

if(thing1 == true && thing2 == false && thing3 = 0) {
// ...
}

You can do something like:

if(thingIsSuitableForAction()) {
// ...
}

This is both self-documenting and makes it so that you can add
additional checks later (or remove checks) and not have to mess with
funky messes of stuff inside of flow control statements. One just has
to exercise care that they don't make the methods that are used in this
way terribly expensive. In other words, you still have to be smart
about the code that you write. Of course, a profiler will tell you if
you manage to really slow things down.

--- Mike
 
if(thing1 == true && thing2 == false && thing3 = 0) {
// ...
}
Click to expand...

That's a typo. I really need to switch back to a wired keyboard. This
thing is unreliable as all get out.

--- Mike
 
Assume you have this statement
total = total + item.Quantity * UnitPrice;
in a loop and it occurs in several places in the code.
Is it then any point for example to create a method with only one singe line
of code like this one
private static double GetItemTotal(int quantity, double unitPrice
{
    return quantity * unitPrice;

}

With this method you get this statement instead.
total = total + GetItemTotal(quantity ,unitPrice);

I just want you opinion about this.
Click to expand...

In addition to what everyone else has said on this, here are my 2c...

Apart from easing later maintenance when your total calculation
changes for whatever reason, there's one other aspect, that may not
apply in this particular case, but does nonetheless apply in general.
When you refactor some calculation, no matter how simple, into a
method, you have to give that method a name. If that name is
sufficiently descriptive, it additionally serves as documentation,
often making inline comments unneeded at the point the method is
actually used (since its name already explains what is going on
there).
 
Back
Top