Keep in mind to create good subroutine

Perl
Subroutine
here

I've scribbled my thoughts on creating subroutine.

Heading

Understand the arguments and return values.
Create a small subroutine.
Give the subroutine flexibility.
Keep the call hierarchy shallow.
Create a subroutine that implements the function.
Be aware of the user.
Think about making the future easier.
We don't want a complete abstraction.

1. Understand arguments and return values

To understand the subroutine, it is enough to learn how to receive the arguments and how to return the return value. This is because there is no difference from the programming you have learned so far from receiving the argument to returning the return value. As soon as you learn how to handle arguments and return values, let's put them into practice.

The following four points are difficult when creating a subroutine.

What to make a subroutine
What kind of name to give
What to do with the argument
What to return

There is no subroutine that can be called the correct way of writing, so you need to think hard according to the situation.

2. Create a small subroutine

A small subroutine is a subroutine up to about 30 lines. Large subroutine are subroutine up to about 100 lines. Beyond this, the idea of subroutine is wrong. It may be overloaded with multiple features.

Subroutines that are too large cannot be reused because they do not realize one function. It will be a meaningless subroutine that just summarizes the processing. It's better to try to make small subroutine. I try to make small subroutine while being aware of realizing one function.

However, subroutine that are too large are not always wrong. If you use the subroutine very often, it makes sense. Sometimes it's okay to sacrifice reusability or functionality if it works well enough. However, avoid blindly creating large subroutine. Think about whether it really makes sense.

3. Make subroutine flexible

To make the subroutine flexible, use a hash as an argument to allow options to be specified. For example, you can specify the delimiter freely, whether to add a line break character to the output, and so on. Being able to change the return value by specifying an argument gives the subroutine flexibility.

However, if you make it too flexible, it will be difficult to create a subroutine. Think about whether that option is likely to be useful in the future. Adding options adds complexity to the logic and is costly to test. Consider future rewards that are worth the cost. If there is no reward, there is no need to make it an option.

4. Keep the call hierarchy shallow

It's best not to create subroutine that are too deep. Calling a subroutine from a subroutine and then calling another subroutine from that subroutine can significantly reduce readability. Only highly versatile and reusable subroutine can be called deeply.

Certainly, the deeper the subroutine call hierarchy, the more abstract the functionality. However, be aware that the cost of creating a subroutine is high. Abstraction isn't all good. The negative impact of lowering management costs and readability is also significant.

The following writing style is not recommended. Realize the subroutine as deep as func1. It can be func2 depth if desired. But don't go to the depth of func3. If func3 is a subroutine that is used many times in programming and can be reused, you may want to create func3.

func1 (); Call # func1

sub func1 {
  func2 (); Call # func2
}

sub func2 {
  func3 (); # func3 call
}

sub func3 {
  # Only really generic and reusable subroutine may be called deeper.
}

5. Create a subroutine that realizes the function

Subroutines aren't as often reusable as you might think. As you can see by actually programming, the programming you make first is not versatile. Because we don't program for general purpose. For example, if you want to process a particular text file and extract a particular string from it, you wouldn't be able to create a reusable subroutine. You can only have a special subroutine dedicated to you.

Still, subroutine are worth making. It's not good not to create a subroutine because it's not reusable. It is necessary to create a subroutine to realize one function. This will increase the readability of your code and create the possibility of subroutine reuse. At first, don't worry too much about creating reusable subroutine, but focus on creating subroutine that implement a single function.

6. User awareness

Subroutines are used to be used (including yourself, of course). This means that the name must be easy to understand. You have to know what kind of function you are realizing. The name must well describe the function. Think about whether the arguments are easy to understand and the return value is easy to understand.

When creating a subroutine, I think it's best to create it with the feeling that you're creating an interface for the user, even if you're the only one using it.

7. Thinking about making the future easier

To be honest, making subroutine is tiring. It takes time and effort. The program works without creating a subroutine. But creating a subroutine is an investment. An investment to ease the future. If you make it properly now, you can flexibly respond to future changes in specifications and changes in the environment. Therefore, even if it is troublesome to create a subroutine, let's be conscious of it.

In fact, there are many programs in the world that have the worst maintainability due to lack of technology for creating subroutine or neglecting to create subroutine. There are many programs that test manpower and guts rather than ingenuity and ideas. It's also one of the reasons programmers get tired.

I will try to create good subroutine for the bright future of programmers.

8. Don't ask for complete abstraction

The exact opposite is true, but a program that is too particular about subroutine creation and never completes is meaningless. The extent to which abstraction can be achieved depends on the technical capabilities for abstraction, the difficulty, and the time constraints.

In the first place, it cannot be abstracted without the technical ability to abstract it. Abstraction is not possible without the slogan to ease future maintenance. If the delivery date is just around the corner and you have to make and move it, you can't abstract it.

Abstraction is built on balance. Abstraction is usually a good thing, but if you ask for abstraction thoroughly, programming will stop there and you will not be able to achieve what you want to achieve. If programming isn't complete because of a lot of abstractions, I prefer to complete it. However, it is better to have a feeling of abstraction as much as possible.

Perl ABC