How to engineer good function names

Continuing on our journey for clean and self-documenting code, we are now turning the focus to function names. We just talked about variable names so it follows that there is some guidance to follow on method or function names. There is a difference between a method and a variable as far as the formal definition goes, but here, let's just assume we are talking about the same thing.

Function Names

Just like with variables, we can generally choose our function names. There are a couple of special circumstances in each language, but outside of the standard entry point, constructor and destructor methods, and anything in a library we've imported, we pretty much get to choose. Let’s take a look!

// Golang
package main
import “fmt”

func main() {
    yFunc()
    xFunc(“Bob”)
}

// yFunc prints out “Hello World!”
func yFunc() {
    fmt.Sprintf(“Hello World!”)
}

// xFunc takes in a name and prints out “Hello name!”
func xFunc(name string) {
    fmt.Sprintf(“Hello %s!”, name)
}

Easy right? Well why would we name the methods yFunc and xFunc? Because they have that Func word, that’s how we know they are functions. That’s an incredibly bad reason to pick a name like this. Your functions need to tell you about the function. Fine, let's do it like this then.

// Golang
package main
import “fmt”

func main() {
    myCustomFunction1()
    myCustomFunction2(“Bob”)
}

// myCustomFunction1 prints out “Hello World!”
func myCustomFunction1() {
    fmt.Sprintf(“Hello World!”)
}

// myCustomFunction2 takes in a name and prints out “Hello name!”
func myCustomFunction2(name string) {
    fmt.Sprintf(“Hello %s!”, name)
}

These tell you something about the function alright; that they are your two custom functions, nothing more. Just like with the variable names we talked about before, what do these functions do? It’s clear to see in this short example exactly what they do. This just outputs “Hello World!” followed by “Hello Bob” to the standard output window. Well this isn't any better than xFunc and yFunc from before. On top of that, we now have two functions that only differ by which number they end with.

Naming functions like this is not efficient at all. Name your functions in a manner that makes it easy to recall what it’s doing. Typically, you want the name of the function to be a descriptive term. Something like SetName or GetName tells you exactly what the function does and what it does it to. Let’s try this again:

// Golang
package main
import (
    "bufio"
    “fmt”
    "os"
)

func main() {
    personName := readString()
    writeString(personName)
}

// readString returns user input
func readString() string {
    reader := bufio.NewReader(os.Stdin)
    fmt.Print("Enter text: ")
    text, _ := reader.ReadString('\n')
    return text
}

// writeString receives string and prints it
func writeString(content string) {
    fmt.Sprintf(“%s”, content)
}

Now this contrived example is simple to understand. Disregarding what the actual code is doing, and the fact that I'm ignoring an error (the underscore), the two function names here are pretty explicit in what they aim to accomplish. Both readString and writeString are pretty clear in what they are doing. Of course we could go as far as calling it readStringFromStdInput and writeStringToStdOutput. We'll actually revisit this later when we look at the SOLID principles, specifically the dependency inversion principle.

At some point, extra long function names become a hassle. TakeTwoNumbersAndAddThem is pretty lengthy, overly descriptive and really just too much when a simple Add would suffice. Maybe we can add another rule here. Function names should be descriptive and concise. There will be times where it makes sense to have a longer method name, but I typically look for ways to shorten it.

I think you get the point here. The same ideas that we talked about in the variable names post apply here. Just remember to follow project, employer or language guidelines and above all else, be consistent with the project you’re working in. It really sucks to see a project where half of it is following one convention and the other half is written differently. Developers tend to be strong willed and want to do things their own way, but trust me, there is room for that in other aspects of development.