This is an introductory lecture on C++, suitable for first year computing students or those doing a conversion masters degree at postgraduate level.

1. Function Design
Michael Heron

2. Introduction
• 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
this badly.
• Our goal is to end up with a program that is a maintainable
whole.
• Something we can easily make changes to later.

3. Coding Tradeoffs
• In code, we are constantly making trade-offs for the programs
we write.
• 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.

4. Efficiency
• 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.

5. Efficiency
• 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
way.

6. Efficiency
• Efficiency is prized in many applications.
• Games
• Frame rates are important
• Simulations
• Responsiveness is important
• Artificial intelligence
• Speed of processing determines outputs
• Very efficient code is often difficult to read.

7. Maintainability
• 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.
• Comments
• Self documenting code

8. Maintainability
• 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
possible.
• Functions are important for this.
• Various things act against maintainability:
• Monolithic code
• Global scope
• Good program design encourages maintainability.

9. 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.

10. How To Write A Function
• Repetition in your code is a good sign that adjustments are
needed.
• 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.

11. 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
maintain.
• Don’t need to understand complex logic.

12. Program 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
level.

13. Abstraction
• 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.

14. Maintenance
• 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.
• Eeek
• Hugely important to design maintainable programs.

15. 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.

16. Document Driven Functions
• Good way to do this is write the documentation for functions
first.
• 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

17. Function Commenting
/*
*
* 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.

18. Adding Functionality
• 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
numbers.

19. Fixing
• There is an informal metric in software engineering.
• For every two bugs you fix, you probably introduced a third in the
process.
• 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!

20. Changes
• It is when we change functionality that we really benefit from
high maintainability.
• 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
with requirements.

21. How?
• 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
• Name
• Parameters
• Everything else is its implementation.

22. Function Interface
• 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
colleagues.

23. Function Interface
• 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.

24. Refactoring
• 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
time.
• External constraints limit us.
• It’s a good idea to refactor code.
• It solves problems before they occur.
• Must be done carefully though.

25. Summary
• Maintainability is important for good programs.
• Functions help us ensure that our code is well designed for this
purpose.
• 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.