Taking a closer look
You can use functions to:
- Encapsulate several lines of code into a single statement.
- Simplify code.
- Most importantly, think of the application as a symphony of smaller applications in harmony.
For developers who come to PHP from compiled languages such as C/C++, PHP's level of performance comes as a shock. User-defined functions are expensive in terms of CPU and memory resources. This is mainly because PHP is interpreted and loosely typed.
To wrap or not to wrap
There are developers who wrap every function they use just because they don't like the name and there are others who don't prefer using wraps at all.
Wrapping existing PHP functions without adding or complementing existing functionality is a strict no-no. Besides increasing the size and the execution time, such renamed functions can sometimes prove to be management nightmares.
Inlining functions in code results in unintelligible code and even bigger management horrors. The only benefit you may gain by doing this is faster code.
The wiser way is to define functions only when you need to use the code multiple times and there are no PHP built-ins for the task you want to achieve. Renaming or limiting use to only when it's required are your choices.
The chart in Figure 1 shows you a rough idea of the give-and-take relationship between manageability and speed versus the number of functions you use. (I won't indicate the units here because the numbers depend on individual and team capabilities; the relationship is the important visual data.)
Figure 1. Manageability / speed vs. number of functions
Naming functions
Just as I mentioned in Part 2 of this series (see Resources), using a common naming convention throughout is imperative for efficient code management.
Two other practices to consider:
- The name you choose should provide a good hint about what the function does.
- Use prefixes that indicate the package or module.
Suppose you have a module named user that contains user-management functions, then the function names (such as usr_is_online() and usrIsOnline()) are good candidates for a function that handles checking if the user is currently online.
Contrast this with a function name such as is_online_checker(). The catch is to use verbs rather than nouns because functions always do something.
How many arguments?
There is a good chance that you'll use functions you've constructed.
Even if this is not the case, you'll probably want to maximize the
reach of your code. To do this, you and other developers will want to
stay with functions that are easy to use. No one likes to use functions
with cryptic and hard-to-follow arguments, so write easy-to-use
functions.
Choosing a name that explains the purpose of a function (as well as reducing the number of arguments the function takes) is a good way to ensure ease of use. What's the magic number for the number of arguments? In my opinion, more than three arguments makes a function less memorable. Complex functions that take many arguments can almost always be broken down to simpler ones.
Nobody likes to use a kludge.
Write quality functions
Say you want to set the header of an HTML document before pushing it
off to the browser. The header is all the stuff between the <head>...</head> tags.
Assume that you want to set a title and a meta tag. Instead of a setHeader(title, name, value) function that does it all, using setTitle(title) and setMeta(name, value) separately is a better solution. This sets the title and the meta tags independently of each other.
On
further thought, a header can have only one title tag, but it can have
multiple meta tags. If you need to set multiple meta tags, the code
will have to call setMeta() multiple times. In that case, a better solution is to pass setMeta()
a two-dimensional array with name-value pairs and have the function
loop through it -- performing all the activities simultaneously.
In general, simultaneous functions such as this one are preferable. It's always better to call a function once with all the data it needs to process rather than to call it multiple times and to feed it data incrementally. The idea is to write a function to minimize calls to it from other code.
In this light, our setHeader() solution was really a kludge. We can obviously refactor setHeader() to setHeader(title, array), but then we must also consider the lost ability to set the title and meta tags independently of each other.
Also, a header can contain more tags than just title and meta in real-world environments. If more tags need to be added, you'll have to change setHeader() and alter all other code that depends on it: In the latter case, you'll just have to write one more function.
The following equation holds true in all programming languages:
memorable name + unambiguous arguments + speed and efficiency = quality function that holds good in all programming languages
View Develop Rock Solid Code In PHP: Part 3 Discussion
Page: 1 2 3 4 5 Next Page: Orchestrating functions with the layered approach