Function names as signaling
In most web applications there’s a host of functions (or methods if speaking in the object-oriented world). It’s widely recognized, that it’s probably a good idea to name them something, which may suggest the purpose or functionality of what the function is doing, but often developers seem to fail at making a stringent naming convention. Before starting on your next big development adventure, here are a three suggested rules for naming functions.
1. It’s more important to have a suggestive name, than a short one.
Never call a function something short but meaningless. Instead use CamelCase and make a sentence suggesting what the function does.
- Bad examples found in live code: “process”, “fixit”, “cleanup”.
- Good examples: “saveToDatabase”, “convertIpnumberToDomainName”, “calculateTotalPricing”.
2. Use prefixes on functions
Reserve common names (more if you like) for specific type of functions. Here are a few suggested rules:
- “get”-functions should always retrieve and return data - never print data.
- “print”-functions shoudl always print data to “standard out”.
- “set”-functions should ways set data to an object (and choose if “set” also saves data or not).
- “save”-functions (if set-functions doesn’t save properties) saves all current properties to the persistent storage (usually database).
3. Reuse data model objects in function names
If you’re data model (or object model) already contains names of entities, reuse these in function names. If a table is named “Travel”, call the function “saveTravelRecord”, Not just “saveDataRecord”. Make consistent use of the same names, field names, properties and other entities found in the application. Using the same name for the same object all across the application, may seem obvious, but somehow developers seem to find slightly different names for the same object again and again.
While the three above tips may seem simple, do check your code and see how many places they are broken. I’ve seen countless times, and getting it right from the beginning would have cost a small effort, refactoring the code years later is a much bigger effort.