The RESTful API has a funny place in the software development world: it’s widely regarded as the best general-purpose pattern for building web application APIs, and yet it’s also nebulous enough of a concept to cause endless disagreements within teams over exactly how to implement one.
Do I make my endpoint
/companies/123/? How about
/locations/?company=123 ? How do I handle versioning the API? Why shouldn’t I send a POST request to trigger an action on the server? If a backend task can take many seconds to process, how do I represent that in the API?
A couple of years ago, I developed an ‘operational support system’ for anaesthesiologists
working in the OR. Other than the main goal of enhancing Patient Safety by helping the
docs remember to do all the things they need to do before, during and after a surgery, the
requirements for the product were quite vague. This wasn’t particularly surprising to me
as this concept, though not new, had never been implemented as a computer system that could
be used in operating rooms and while certainly ‘technical’ to some degree, my customer was
not versed in software development and really didn’t have many expectations beyond the
implementation of his core concept. Anyway, with that comforting level of detail, I set out
to design a system that would both meet the main goal while at the same time being able to
accommodate the inevitable “oh yeah, we should be able to do, too – that won’t take
too long, will it?”.
One of our most frequent tasks as programmers is assigning names. It’s hard to go an hour without coming up with a name for a class, a method, or a variable. But naming things is hard for at least two reasons:
- The exact purpose of an item might be not be clear until you’ve written its body or used it in context. I often use a clearly inappropriate placeholder that will force me to replace it once I have a good name.
- Picking appropriate words is tough. It can be hard to spend time selecting the right word when you’re focused on writing logic, but often the work of naming will help clarify that logic’s organization.
Here are some suggestions for naming rules, born from recent experiences.
Rule: reflect the usage and context
A name is the first and most important way a reader will determine what something does, and whether it’s the appropriate something to use.
If a class has a very specific context in which it’s useful, reflect that context in the name or its containing package. On the other hand, think forward to future uses of a class, and don’t unnecessarily restrict it to Foos by calling it FooEngine when it might also be useful for Bars.
Rule: influence the named object’s scope
Names can act as a valuable indicator that the scope of a class or method has grown too big. If a good name doesn’t seem to comprise the full functionality any more, or conversely the functionality is suggesting a name that involves too many steps, then consider factoring out some of that functionality.
A class named SearchEngine that’s also used to retrieve user configured paths needs to be refactored into at least two classes. A method named ValidateUpdateNotify (or more problematically, Process) should actually be three separate methods.
Rule: name length is inversely proportional to usage frequency
The more frequently a name will be used, the shorter it can and should be. The length and obscurity of names impacts how other developers use the named objects. In the following comparison, split is idiomatic, familiar, easy to read, and easy to remember; componentsSeparatedByString is much less so:
'a b c'.split(' ')
# Objective C
[@"a b c" componentsSeparatedByString:@" "]
Apple’s very long method names such as tableView:accessoryButtonTappedForRowWithIndexPath: have a clear benefit of being self-documenting and are appropriate for less frequently used API classes. But for the more common classes and methods in a language, API, or project, they add an unnecessary burden to the developer.
Rule: unique names are searchable names
If you ever need to refactor a widely used method or search the git commit history for the introduction of a variable, you’ll be grateful if the name is unique. For example, name a class PurchaseOrder or JobOrder rather than Order, which will easily be confused with sorting or other meanings for the word.
Rule: alphanumeric names are Googleable names
Rule: rename when necessary
In many cases, it’s hard to get a name right the first time, particularly when requirements or architecture change. As a project evolves, make sure to keep the above rules in mind and rename your classes and methods when their roles change. Don’t let a name rot into inaccuracy.
The subject of naming has been a popular one over the years. Here are some worthwhile posts:
“I only modified one line of the file, why should I be responsible for fixing the coding style of the whole thing?” That was my first reaction when participating in a full-scale code review at one of the software companies I worked for. Then, if I do have to fix the coding style, my name is going to be on the blame list when somebody checks version control for who wrote that section of code. How far should we take fixing things during reviews? (more…)
When I started my own personal site, I faced a dilemma: I’m a software developer, why should I use a content management system (CMS) on my personal website when I’m supposed to be an expert at making websites? Every CMS I’ve used has angered me in one way or another. The end result was always me hacking together my personal site with PHP (the one thing the language was originally designed for) or playing around with other custom backend solutions for it.
A static website with a dynamic backend though seemed wasteful to me. Every time somebody visits the page, the web server must regenerate the content for the page. The engineer inside of my head was screaming “surely there’s a better way to do this!” (more…)