Readability is one thing. But there is more to modularisation than just this. (Semi-modularisation is maybe more correct for functions.)

In functions you can keep some variables local, which increases reliability, decreasing the chance of things getting messed up.

Another pro of functions is re-usability. Once a function is coded, it can be applied multiple times in the script. You can also port it to another script.

Your code now may be linear, but in the future you may enter the realm of multi-threading, or multi-processing in the Bash world. Once you learn to do things in functions, you will be well equipped for the step into the parallel.

One more point to add. As Etsitpab Nioliv notices in the comment below, it's easy to redirect from functions as a coherent entity. But there's one more aspect of redirections with functions. Namely, the redirections can be set along the function definition. Eg.:

f () { echo something; } > log

Now no explicit redirections are needed by the function calls.

$ f

This may spare many repetitions, which again increases reliability and helps keeping things in order.

Readability is one thing. But there is more to modularisation than just this. (Semi-modularisation is maybe more correct for functions.)

In functions you can keep some variables local, which increases reliability, decreasing the chance of things getting messed up.

Another pro of functions is re-usability. Once a function is coded, it can be applied multiple times in the script. You can also port it to another script.

Your code now may be linear, but in the future you may enter the realm of multi-threading, or multi-processing in the Bash world. Once you learn to do things in functions, you will be well equipped for the step into the parallel.

One more point to add. As Etsitpab Nioliv notices in the comment below, it's easy to redirect from functions as a coherent entity. But there's one more aspect of redirections with functions. Namely, the redirections can be set along the function definition. Eg.:

f () { echo something; } > log

Now no explicit redirections are needed by the function calls.

$ f

This may spare many repetitions, which again increases reliability and helps keeping things in order.

See also

• https://unix.stackexchange.com/a/483304/181255

Readability is one thing. But there is more to modularisation than just this. (Semi-modularisation is maybe more correct for functions.)

In functions you can keep some variables local, which increases reliability, decreasing the chance of things getting messed up.

Another pro of functions is re-usability. Once a function is coded, it can be applied multiple times in the script. You can also port it to another script.

Your code now may be linear, but in the future you may enter the realm of multi-threading, or multi-processing in the Bash world. Once you learn to do things in functions, you will be well equipped for the step into the parallel.

Readability is one thing. But there is more to modularisation than just this. (Semi-modularisation is maybe more correct for functions.)

In functions you can keep some variables local, which increases reliability, decreasing the chance of things getting messed up.

Another pro of functions is re-usability. Once a function is coded, it can be applied multiple times in the script. You can also port it to another script.

Your code now may be linear, but in the future you may enter the realm of multi-threading, or multi-processing in the Bash world. Once you learn to do things in functions, you will be well equipped for the step into the parallel.

One more point to add. As Etsitpab Nioliv notices in the comment below, it's easy to redirect from functions as a coherent entity. But there's one more aspect of redirections with functions. Namely, the redirections can be set along the function definition. Eg.:

f () { echo something; } > log

Now no explicit redirections are needed by the function calls.

$ f

This may spare many repetitions, which again increases reliability and helps keeping things in order.