We will break our code into modular-named pieces because it makes it easier to understand what we have, to manage and find what we're looking for. It makes it easier to maintain, to change and make it more flexible if we have different ideas and new plans. The ability to do this is the same thing that's going to save us from having to reinvent the wheel every day.
This will be what lets us tap into and build on top of all the things that other programmers have written, whether that was yesterday or 20 years ago. When we're writing code, we'll often write a section of code that's several lines, maybe even just 4 or 5 statements and we figure out that these lines kind of belong together.
Perhaps it's a few lines of code that plays a sound effect, or a few lines of code that checks the internet connection or shows the scoreboard in a game. So we decide to take this code and give it a name. We're going to make it a function to create this self-contained chunk of code, like having a mini program within our program. We'll then be able to use it, and more importantly re-use it, from other places in our code.
A quick side bomb. There are some other terms you'll hear for the same idea. Sometimes it's called a function and sometimes it's called a module, a sub-routine, a sub-program, a process or a method, but function is the most generic and the most widely understood term for this idea.
To create a function, we just need to begin with 3 things:
Fig 5.2.1: How to create a new function
In many languages we have a keyword like Function or funk, and then our name for this new function, what we want to call this new chunk of code. Naming a function is like naming a variable. It's up to us, but we want something meaningful. Just like naming a variable, it's very common to use the camel case style when naming a function.
Even though we're using camel case, a function name is going to feel very different from a variable name because when you name a variable, you're naming a piece of data, score, file name, or phone number, but with a function, you're naming a task. This is a block of code that does something, so it's very common to name a function with a verb-noun format, like…
Function validatePassword
Function playSoundEffect
Function showScoreboard
Function explodeSpaceship
Function createEmail
Function encryptFile
Function connectToDatabase
Function printMessage.
There is no rule for this naming style. We just hope we can read a function name. Even if we didn't write it, just from that name we can get a pretty good idea of what this function does. The code block of a function also says where it starts or ends.
As with other code blocks we've seen, sometimes it might use words and in other languages it uses the curly braces, but it's just a code block, the same as code blocks in conditionals or loops, to simply mark where this function begins and where it ends. See Fig 5.2.2.
Fig 5.2.2: Using braces and indentation to create a new code block for a function in some languages
Once again, the code inside is commonly indented, but we're missing a vital step because the code now placed inside this function will never be executed unless some other part of the program says go run that function.
When we talk about functions, we have two tasks:
Any programmer will know what you mean if you said you wanted to run a function, but the term we usually use is that we call a function. We write a function and then we can call it. Fig 5.2.3 shows how we might call it.
Fig 5.2.3: A pseudocode showing how to call a function
Now this is still a Pseudocode, not real syntax. Different languages do call functions in different ways, but it is very common to see a function called written as just the name of the function with a pair of parentheses after it (the last line of code in Fig 5.2.3:
printMessage()
I'll talk more about this in a moment. Only when this last line is executed that we then jump into the function itself, run through all the lines inside it (execute statements one through five). When we get to the end, we jump back out of the block to where we were (after the call to function) and move on. Fig 5.2.4.
Fig 5.2.4: A function has been called. All statements one to five are about to be executed sequentially
As a working programmer, sometimes you'll write a function and somebody else on your team will be the one who calls it. Sometimes someone else will write that function and you'll be the person who needs to know the name of it so you can call it.
Very often you'll find useful functions that were written years ago. You find them and think, great, somebody else already did this task so I don't have to. I can just call that function they wrote and that's a good thing.
Now we're back to this idea of code reuse. Don't repeat yourself. Don't reinvent the wheel unless you have an idea for a better wheel. But sometimes you need your functions to be more than just a few lines of code with a name on it. You need to be able to pass information into that function and get information out of it.