Slide 1
Administrivia
• Nate's office hours are Wed, 2-4, in 329
Soda!
• TA Clint will be handing out a paper survey
in class sometime this week.
• Interviews starting next week, from ex-TA
Paul Hale
– These can be a great place to ask questions
• This week, the BIG PROJECT is
introduced
Slide 2
Midterm #2
Any questions?
Slide 3
The Big Project
• Three possible projects:
– Database
– Blocks World
– Yukon
• You can work in partnerships
• You will have three weeks to work on this
(it is due on the last lab)
• Worth 10% of you final grade
Slide 4
Project Check-offs
• There are 3 checkoffs
You need to do them on time in order to get
credit for the project
1. Tell your TA which project you will do and
who you will do it with
2. Show your TA that you have accomplished
something. S/he will comment.
3. Show that you have most of the work done:
your TA will run your code.
Slide 5
April 11
April 18
April 25
May 2
May 9
Midterm #2 (during lecture)
Extending sentences, words to lists (in lab)
Finish advanced list processing (recursion)
Start on the big project
CHECKOFF #1 – Thur/Fri
Big Project
CHECKOFF #2 – Thur/Fri
Finish up the Project
CHECKOFF #3 – Tue/Wed
Project Due on Thur/Fri
Review session instead of lecture?
Slide 6
Only two more lectures
(after this one)…
What would you like to do?
– Hear about the CS major, and other courses…
– Do exam-type problems…
– Review…
On May 9th, we could hold a final lecture, or a
review session, or nothing…
Slide 7
Lets see the projects in action
Slide 8
Programming Style
• Why does it matter
– Bad style gets worse in large programs
– Program maintenance: 6 months later, will
you know what your code does?
– Code “literacy”: sharing code
• Remember, programming style will be
considered in your project grade
Slide 9
What issues of style matter?
•
•
•
•
•
Don’t nest conditional statements
Keep procedures small !
Good names for procedures and parameters
Proper use of global variables
Adequate comments
– Above and within procedures
• Put tests cases in a comment block
• Indent to aid program comprehension
• Data abstraction
– E.g. Don't do (bf (car '((a b) (c d)))
Slide 10
Of course, other issues matter
• Reading specifications carefully
• Error checking inputs (especially in the
database project)
• Adequate testing
• Code reuse (again, with the database)
Slide 11
Working in partnerships
• Won't be faster, necessarily
– While you are less likely to get stuck, there
will be a lot of communication necessary
• The main strength will be with testing
– i.e., two sets of eyes…
• Remember, only one grade is given…
• Any other ideas?
Slide 12
Functional Programming
• In CS3, we have focused on programming
without side-effects.
– All that can matter with a procedure is what it
returns
– In other languages, you typically:
• Perform several actions in a sequence
• Set the value of a variable – and it stays that way
– All of this is possible in Scheme.
Slide 13
Printing, and sequencing
• With Blocks World and Yukon you will
need to display information.
– Simply Scheme chapter 20 is nice summary.
– And, all the projects have either file input
/output routines that you don't need to
"understand", as well as user input routines.
Slide 14
Data structures
• The format of data used in these projects
in a central feature
– A "data structure" (abstract data type) is a
specification of that format. Here, generally,
lists of lists (of lists).
– Accessors and constructor allow for
modularity: letting parts of a program work
independently from other parts.
Slide 15
Strings versus words
• One useful data structure is a string
– Strings are surrounded by double quotes
when printed.
– Strings are a native type in Scheme.
• In CS3, you used words (sometimes
sentences) to present names and other
output to the user.
– In the real world, strings are used.
Slide 16