7 Replies - 8751 Views - Last Post: 14 May 2012 - 10:58 PM

#1 hiddenghost  Icon User is offline

  • D.I.C Addict
  • member icon

Reputation: 39
  • View blog
  • Posts: 621
  • Joined: 15-December 09

Large or small methods?

Posted 12 May 2012 - 03:13 PM

I was wondering how every one decides how big to make their methods.

Do you try as hard as you can to make small methods?

I've been trying to make my methods as small as possible, and it's forcing me to make some interesting patterns.

For data that doesn't change I have been using self a lot more.
For variable data I've been creating a series of methods calls to allow breaking up the code into different methods.

I'll start with a largish method and then break that method down into smaller methods.

As a side effect this has helped me with learning visibility because every thing being dependent makes privileges really apparent.

I'm not sure if this will help with code maintainability, or I'm just having fun making something into a huge mess.

So far it looks pretty good. The methods describe exactly what happens with their name. The average length of a method body is 3 lines. Each does it's own job.

It's helped a lot with recursion by using trampolines.
I learned about trampolines from a link in the previous thread:
http://www.dreaminco...1&#entry1618128

That's kind of strange concept for me, but it seems to have merit.

Mostly I'd like to read what dream.in.code people have done as far as method size.

Is This A Good Question/Topic? 0
  • +

Replies To: Large or small methods?

#2 tlhIn`toq  Icon User is online

  • Please show what you have already tried when asking a question.
  • member icon

Reputation: 5316
  • View blog
  • Posts: 11,355
  • Joined: 02-June 10

Re: Large or small methods?

Posted 12 May 2012 - 03:57 PM

I never worry about size: Only purpose.

A method should have one purpose in life and not cause any side effects.

For example: CalculateSum(int x, int y)
This should ONLY do the calculation and return the result.
It should NOT ask the user for input, save results to a file, alter the GUI to display the results

Another example:
ProcessImage(bitmap somePhoto)
{
   RotateImage(somePhoto);
   CropImage(somePhoto);
   FixColor(somePhoto);
}

This method has one purpose: To direct the order of processing. It doesn't try to encompass all the functions it is calling within itself. Making it easy to read and understand, as well as easy to re-order the sequence of events.
Was This Post Helpful? 3
  • +
  • -

#3 RudiVisser  Icon User is offline

  • .. does not guess solutions
  • member icon

Reputation: 1001
  • View blog
  • Posts: 3,555
  • Joined: 05-June 09

Re: Large or small methods?

Posted 12 May 2012 - 05:28 PM

Agree with tlhIn`toq of course; this is entirely contextual.
Was This Post Helpful? 0
  • +
  • -

#4 hiddenghost  Icon User is offline

  • D.I.C Addict
  • member icon

Reputation: 39
  • View blog
  • Posts: 621
  • Joined: 15-December 09

Re: Large or small methods?

Posted 13 May 2012 - 01:05 AM

View PosttlhIn`toq, on 12 May 2012 - 05:57 PM, said:

I never worry about size: Only purpose.

A method should have one purpose in life and not cause any side effects.


That makes a lot of sense.
In this example:
ProcessImage(bitmap somePhoto)
{
   RotateImage(somePhoto);
   CropImage(somePhoto);
   FixColor(somePhoto);
}


You have the three methods inside ProcessImage. You could have all the code for those methods directly in ProcessImage.
Would you say it's better to call the methods/functions instead of just using the code directly inside ProcessImage?
In that example it seems obvious, but what if the calls inside ProcessImage were only being used by that method.
Was This Post Helpful? 0
  • +
  • -

#5 RudiVisser  Icon User is offline

  • .. does not guess solutions
  • member icon

Reputation: 1001
  • View blog
  • Posts: 3,555
  • Joined: 05-June 09

Re: Large or small methods?

Posted 13 May 2012 - 04:05 AM

View Posthiddenghost, on 13 May 2012 - 08:05 AM, said:

In that example it seems obvious, but what if the calls inside ProcessImage were only being used by that method.

Could you guarantee throughout the whole lifetime of your application (years?) that the actions are only going to be used in that single method?

Perhaps a slightly more complex example would be something that confirms an order, like this:
public function ConfirmOrder(Model_Order $order)
{
    // Construct an email
    $to = $order->email;
    $from = 'noreply@myawesomeshop.com';
    $msg = 'yada yada yada you got a new order';
    $email = new Email();
    $email->send($to, $from, $msg);
    // Update the database
    $db = Db::get();
    $db->update('orders', array('id' => $order->id), array('status' => 'confirmed'));
    $db->save();
    // Something else
}


It's still not that big, but it would make more sense to separate out the email and database updating into two separate methods. What if you had an administrative order approval at some point that shouldn't send an email? Yes you could pass a parameter to the ConfirmOrder() method but what if it grows with more actions (sending a notification to stock room etc)? You couldn't keep adding parameters. If all of the actions are separated out you're free to pick and choose (and use!) whichever portions of it you want for other parts of your application, and the actual action of "confirming an order" is simply a wrapper that performs these distinctly different sub-actions to perform the ultimate task.

So let's say your order looks like this:
public function ConfirmOrder(Order $order)
{
    $this->SendUserConfirmationEmail($order);
    $order->SetStatus('confirmed');
}


You also have a method that sends a stock notification to your stockroom for confirmed orders, but your store used to be manual approval. You don't want to remove manual approval, simply have it do it automatically for any new orders! If (in an MVC application for example) you had a notification action that contained all the code to make a request to the stockroom server, then you'd probably end up copying/pasting the code into your ConfirmOrder() method and it would end up massive. If your MVC app called $order->SendStockNotification(), then you can quite simply copy that over to your ConfirmOrder method.

This post has been edited by RudiVisser: 13 May 2012 - 04:08 AM

Was This Post Helpful? 1
  • +
  • -

#6 hiddenghost  Icon User is offline

  • D.I.C Addict
  • member icon

Reputation: 39
  • View blog
  • Posts: 621
  • Joined: 15-December 09

Re: Large or small methods?

Posted 14 May 2012 - 01:14 AM

Is true.
What if the code for those calls would be only called once.

Say, if the the two functions were for a database class, and I somehow new they would be used once because they only contain string parts of some sort, or maybe they are wrappers for database query parts.
Was This Post Helpful? 0
  • +
  • -

#7 RudiVisser  Icon User is offline

  • .. does not guess solutions
  • member icon

Reputation: 1001
  • View blog
  • Posts: 3,555
  • Joined: 05-June 09

Re: Large or small methods?

Posted 14 May 2012 - 05:51 AM

If all of those methods were called from just 1 other place it wouldn't matter, it's still 1 method to perform 1 specific purpose, and you have the option to easily reuse it in the future if at all necessary.

I've always followed the Linux Kernel Coding Style for functions (and comments, and a few other things!), which says this:

Quote

ould be short and sweet, and do just one thing. They should
fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24,
as we all know), and do one thing and do that well.

The maximum length of a function is inversely proportional to the
complexity and indentation level of that function. So, if you have a
conceptually simple function that is just one long (but simple)
case-statement, where you have to do lots of small things for a lot of
different cases, it's OK to have a longer function.

However, if you have a complex function, and you suspect that a
less-than-gifted first-year high-school student might not even
understand what the function is all about, you should adhere to the
maximum limits all the more closely. Use helper functions with
descriptive names (you can ask the compiler to in-line them if you think
it's performance-critical, and it will probably do a better job of it
than you would have done).

Another measure of the function is the number of local variables. They
shouldn't exceed 5-10, or you're doing something wrong. Re-think the
function, and split it into smaller pieces. A human brain can
generally easily keep track of about 7 different things, anything more
and it gets confused. You know you're brilliant, but maybe you'd like
to understand what you did 2 weeks from now.

In source files, separate functions with one blank line. If the function is
exported, the EXPORT* macro for it should follow immediately after the closing
function brace line. E.g.:

int system_is_up(void)
{
return system_state == SYSTEM_RUNNING;
}
EXPORT_SYMBOL(system_is_up);

In function prototypes, include parameter names with their data types.
Although this is not required by the C language, it is preferred in Linux
because it is a simple way to add valuable information for the reader.

Was This Post Helpful? 1
  • +
  • -

#8 hiddenghost  Icon User is offline

  • D.I.C Addict
  • member icon

Reputation: 39
  • View blog
  • Posts: 621
  • Joined: 15-December 09

Re: Large or small methods?

Posted 14 May 2012 - 10:58 PM

Thanks RudiVisser.
I use linux, and I like a lot of the philosophy that goes behind it.
Maybe I should have looked at that first.

Since it's open source it makes since that there would be clear coding standards.
Lots of people that don't know the writer directly could read the code.
That being said anything I've written in bash is hard to read. Que sera sera.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1