• The syntax of functions is something we have already
discussed in an earlier lecture.
• In this lecture we are going to talk about the steps that we go
through to write them.
• Like anything in programming, we can do this well or we can do
• Our goal is to end up with a program that is a maintainable
• Something we can easily make changes to later.
• In code, we are constantly making trade-offs for the programs
• We must choose between CPU, memory and the hard-drive
• We must choose between maintainability, efficiency, and size.
• The point where we decide on which of these will vary from
application to application.
• No answer works for all programs.
• The first metric people apply to code is that of efficiency.
• How fast does it run.
• Modern processor speeds have made this less important.
• Computers are just so fast these days that many efficiency
problems are simply gone.
• However, still important for some applications.
• Highly processor intensive applications.
• We’ll talk more about efficiency tomorrow.
• When we discuss algorithms.
• However, it is a measure of how fast your code is.
• Many ways to have efficiency problems.
• Mostly due to code being executed when it doesn’t need to.
• Or using a complex way to perform a task rather than a simple
• Efficiency is prized in many applications.
• Frame rates are important
• Responsiveness is important
• Artificial intelligence
• Speed of processing determines outputs
• Very efficient code is often difficult to read.
• Maintainability relates to how easily a piece of software can
be changed after it is written.
• Hugely important for most programs.
• Maintainable programs are highly prized
• By the people who have to maintain them!
• Some simple ways exist to ensure maintainability.
• Self documenting code
• However, developing a maintainable program needs a certain
structure to the code as well.
• Important to separate things out into as small a chunk as
• Functions are important for this.
• Various things act against maintainability:
• Monolithic code
• Global scope
• Good program design encourages maintainability.
How To Write A Function
• A function should do one thing, and only that.
• Tempting to make functions very powerful.
• That also makes them, usually, very specific.
• Functions should be small.
• The smaller the function, the better the function (usually)
• Functions should make use of other functions.
• This keeps them small.
How To Write A Function
• Repetition in your code is a good sign that adjustments are
• Create a loop
• Separate out into a function
• Whenever you are doing the same thing more than one time,
consider adopting a function.
• Consider what information will go in
• This gives you the parameters
• Consider what information must come out
• This gives you the return type.
How To Write A Function
• Functions should do one thing only.
• Consider your assessment.
• One function to print a number of stars
• One function to print stars in a loop
• One function to print the loops in a loop
• The more precisely defined the function, the easier it is to
• Don’t need to understand complex logic.
• Program logic is the flow of execution through the code.
• It can very easily become extremely difficult to understand.
• Functions help manage that by separating out functionality
into logical blocks.
• Can concentrate on the high level interaction and not the low
• This is a process called abstraction.
• Ignore the little details, just focus on the big picture.
• Very important in programming.
• Big part of pattern recognition.
• Functions aid in abstraction.
• We don’t need to know when they’re called how they work.
• Just need to know what they do.
• Most programming work is maintenance.
• Fixing broken code
• Adding in new features
• Adjusting new features.
• Around 80% of all programming time is spent on this task.
• Hugely important to design maintainable programs.
Designing a Function
• Various ways exist to help design functions.
• Common way known as top down design.
• Concentrate on the main steps of the program.
• Leave out the details.
• Like a higher level pseudocode.
• This is known as procedural abstraction.
• We pretend each function is a black box.
• Doesn’t matter how it works, just what it does.
Document Driven Functions
• Good way to do this is write the documentation for functions
• Functions should be commented for high level understanding.
• What do they do
• What are their parameters
• What do they mean
• What is the return type
* This function takes in two parameters and returns the power of
* the first to the second.
* param num The number we wish to raise
* param power The power to which we raise it
* returns The number which is num^power.
Don’t need to know how it does it.
We just need to know what information it needs, and what information it gives us.
• How do we add new functionality to a program?
• New functions
• Alterations in the user interface
• Relatively straight-forward for completely new features.
• My program calculates the power, now have it calculate the root
• More complicated for other situations.
• It no longer deals with pure integers, now handles floating point
• There is an informal metric in software engineering.
• For every two bugs you fix, you probably introduced a third in the
• Fixing software is an ongoing process.
• Only really find out when people are using software where the really
obscure bugs are.
• Big part of maintenance focused on ensuring bug-free software.
• Never ending goal!
• It is when we change functionality that we really benefit from
• Many reasons why we may want to do this:
• Laws change
• Procedures change
• Data structures change
• A good program is one that permits us to keep it up to date
• Good functions hide their implementation details.
• We know what goes in and comes out
• That is not necessarily related to how they are handled internally.
• We call the exposed details of a function its interface.
• Return type
• Everything else is its implementation.
• The interface to a function cannot be changed if we do not
wish to make more work for ourselves.
• There are some rules that help us deal with this, which we will
talk about in a later week.
• When working with multiple developers, we must be
respectful of our fellow coders.
• Our function interface represents an informal contract with our
• Provided we were sensible, this is not especially limiting.
• We can overload functions if necessary, for example.
• What happens inside the function is entirely our business.
• We can make changes largely on a whim, provided the external
behaviour remains unchanged.
• This is actually a very common process.
• Refactoring is the process of taking code we wrote in the past,
and rewriting it the way we would have if we had the time.
• As developers, we never write code as well as we can all of the
• External constraints limit us.
• It’s a good idea to refactor code.
• It solves problems before they occur.
• Must be done carefully though.
• Maintainability is important for good programs.
• Functions help us ensure that our code is well designed for this
• Many ways in which functions should be written.
• Important to separate out the interface from the implementation.
• Procedural abstraction as a process aids in function design.
• Write what they do, not how they do it.