Return to Answer

No, it's not always a best practice.

You've already clearly illustrated that in your question. Why take the performance hit of a function call when you don't get any significant benefit by doing so? Granted, you may not need those few extra clock cycles, but why take them if you don't need to? ^*

All other things being equal, linear, line-by-line code is always easier to read than jumping around function calls. A non-trivial function call always takes parameters, so you have to sort all that out and make mental contextual jumps from function call to function call. Always favor better code clarity, unless you have a good reason for being obscure (such as obtaining necessary performance improvements).

So why is code refactored into separate methods then? To improve modularity. To collect significant functionality behind an individual method and give it a meaningful name. If you're not accomplishing that, then you don't need those separate methods.

^*_{Note to those of you who apparently don't get it; this statement is somewhat tongue-in-cheek, but true nevertheless.}

No, it's not always a best practice.

All other things being equal, linear, line-by-line code is easier to read than jumping around function calls. A non-trivial function call always takes parameters, so you have to sort all that out and make mental contextual jumps from function call to function call. Always favor better code clarity, unless you have a good reason for being obscure (such as obtaining necessary performance improvements).

So why is code refactored into separate methods then? To improve modularity. To collect significant functionality behind an individual method and give it a meaningful name. If you're not accomplishing that, then you don't need those separate methods.

No, it's not always a best practice.

You've already clearly illustrated that in your question. Why take the performance hit of a function call when you don't get any significant benefit by doing so? Granted, you may not need those few extra clock cycles, but why take them if you don't need to?

All other things being equal, linear, line-by-line code is always easier to read than jumping around function calls. A non-trivial function call always takes parameters, so you have to sort all that out and make mental contextual jumps from function call to function call. Always favor better code clarity, unless you have a good reason for being obscure (such as obtaining necessary performance improvements).

So why is code refactored into separate methods then? To improve modularity. To collect significant functionality behind an individual method and give it a meaningful name. If you're not accomplishing that, then you don't need those separate methods.

No, it's not always a best practice.

You've already clearly illustrated that in your question. Why take the performance hit of a function call when you don't get any significant benefit by doing so? Granted, you may not need those few extra clock cycles, but why take them if you don't need to? ^*

All other things being equal, linear, line-by-line code is always easier to read than jumping around function calls. A non-trivial function call always takes parameters, so you have to sort all that out and make mental contextual jumps from function call to function call. Always favor better code clarity, unless you have a good reason for being obscure (such as obtaining necessary performance improvements).

So why is code refactored into separate methods then? To improve modularity. To collect significant functionality behind an individual method and give it a meaningful name. If you're not accomplishing that, then you don't need those separate methods.

^*_{Note to those of you who apparently don't get it; this statement is somewhat tongue-in-cheek, but true nevertheless.}

No, it's not always a best practice.

You've already clearly illustrated that in your question. Why take the performance hit of a function call when you don't get any significant benefit by doing so? Granted, you may not need those few extra clock cycles, but why take them if you don't need to?

All other things being equal, linear, line-by-line code is always easier to read than jumping around function calls. A non-trivial function call always takes parameters, so you have to sort all that out and make mental contextual jumps from function call to function call. Always favor better code clarity, unless you have a good reason for being obscure (such as obtaining necessary performance improvements).

So why is code refactored into separate methods then? To improve modularity. To collect significant functionality behind individual methods. If you're not accomplishing that, then you don't need those separate methods.

No, it's not always a best practice.

You've already clearly illustrated that in your question. Why take the performance hit of a function call when you don't get any significant benefit by doing so? Granted, you may not need those few extra clock cycles, but why take them if you don't need to?

All other things being equal, linear, line-by-line code is always easier to read than jumping around function calls. A non-trivial function call always takes parameters, so you have to sort all that out and make mental contextual jumps from function call to function call. Always favor better code clarity, unless you have a good reason for being obscure (such as obtaining necessary performance improvements).

So why is code refactored into separate methods then? To improve modularity. To collect significant functionality behind an individual method and give it a meaningful name. If you're not accomplishing that, then you don't need those separate methods.