Function Design
Michael Heron
Introduction
• The syntax of functions is something we have already
discussed in an earlier lecture.
• In this lecture we ...
Coding Tradeoffs
• In code, we are constantly making trade-offs for the programs
we write.
• We must choose between CPU, m...
Efficiency
• The first metric people apply to code is that of efficiency.
• How fast does it run.
• Modern processor speed...
Efficiency
• We’ll talk more about efficiency tomorrow.
• When we discuss algorithms.
• However, it is a measure of how fa...
Efficiency
• Efficiency is prized in many applications.
• Games
• Frame rates are important
• Simulations
• Responsiveness...
Maintainability
• Maintainability relates to how easily a piece of software can
be changed after it is written.
• Hugely i...
Maintainability
• However, developing a maintainable program needs a certain
structure to the code as well.
• Important to...
How To Write A Function
• A function should do one thing, and only that.
• Tempting to make functions very powerful.
• Tha...
How To Write A Function
• Repetition in your code is a good sign that adjustments are
needed.
• Create a loop
• Separate o...
How To Write A Function
• Functions should do one thing only.
• Consider your assessment.
• One function to print a number...
Program Logic
• Program logic is the flow of execution through the code.
• It can very easily become extremely difficult t...
Abstraction
• This is a process called abstraction.
• Ignore the little details, just focus on the big picture.
• Very imp...
Maintenance
• Most programming work is maintenance.
• Fixing broken code
• Adding in new features
• Adjusting new features...
Designing a Function
• Various ways exist to help design functions.
• Common way known as top down design.
• Concentrate o...
Document Driven Functions
• Good way to do this is write the documentation for functions
first.
• Functions should be comm...
Function Commenting
/*
*
* This function takes in two parameters and returns the power of
* the first to the second.
*
* p...
Adding Functionality
• How do we add new functionality to a program?
• New functions
• Alterations in the user interface
•...
Fixing
• There is an informal metric in software engineering.
• For every two bugs you fix, you probably introduced a thir...
Changes
• It is when we change functionality that we really benefit from
high maintainability.
• Many reasons why we may w...
How?
• Good functions hide their implementation details.
• We know what goes in and comes out
• That is not necessarily re...
Function Interface
• The interface to a function cannot be changed if we do not
wish to make more work for ourselves.
• Th...
Function Interface
• Provided we were sensible, this is not especially limiting.
• We can overload functions if necessary,...
Refactoring
• Refactoring is the process of taking code we wrote in the past,
and rewriting it the way we would have if we...
Summary
• Maintainability is important for good programs.
• Functions help us ensure that our code is well designed for th...
Upcoming SlideShare
Loading in...5
×

CPP11 - Function Design

118
-1

Published on

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

Published in: Software, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
118
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

CPP11 - Function Design

  1. 1. Function Design Michael Heron
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×