COSC326

Effective Programming

Semester two, 2017

Teaching Team


Outline

This paper aims to improve and develop your programming skills by setting a series of exercises, called études, which require an analytical and creative approach to problem solving. Most, but not all, of them will involve programming tasks. Some will not use computers at all, while others will use computers only for ancillary tasks. Each solution will be assessed against the requirements and you will be expected to go back and rework each étude until it is completed satisfactorily. You will be required to fully test and debug your programs as well as learn to identify inefficiencies.

The main objectives of this course are to develop and foster general skills relating to computer related techniques, understanding a problem, problem solving strategies and working with people. Most of the études will require working in pairs or in groups, although some exercises are individual work. There are no lectures, but weekly town hall meetings will be used to discuss or propose solutions, give hints, and reflect on the things you've learned.

There are 13 études, and to pass COSC326 you must complete all of them. The individual point values for each one are really just a rough indication of their (expected) lengths.

The course structure and objectives are set out in more detail in the manifesto.

Timetable - Semester two, 2017

Semester two runs from Monday the 10th of July to Friday the 13th of October. The first lab session is on Monday the 10th. It is important to be there; that lab session will introduce you to how the course works.

This course has two kinds of sessions: Lab sessions and Town Halls. During Lab sessions you work on problems as individuals, pairs, or groups. A lecturer and/or tutor will be available. Town Hall meetings are not supposed to be lectures. They are opportunities for you to discuss the problems as a class and in several of them you will present your work as groups.

Lab 1Monday 4 p.m.–6 p.m.Lab F (Owheo G38)
Lab 2Wednesday 4 p.m.–6 p.m.Lab F (Owheo G38)
Town HallThursday 10–11 a.m.Seminar room (Owheo G34)

These times and locations are currently provisional.

You should attend both lab sessions every week. If there isn't enough room in Lab F, you may use Lab E (Owheo G37).

Assessment

Submission details

Please submit your assignments and send all COSC326 related materials to mark326@cs.otago.ac.nz, and not to other personal or organisational email addresses. We shall mark assignments as quickly as we can. You will be able to request your mark record. This includes all submissions of work, questions etc.

It is always appropriate to ask for help. Asking for help is the smart option, not an indication of problematic weakness.

When you submit an answer to étude N, include the number N in the subject line.

When submitting programs you must submit source code (e.g., .java, .py, or similar files). You should also submit test cases, build scripts, reports, and so on, as appropriate. All submitted materials must be in the body of the message or attachments; links to SourceForge, GitHub, Google Docs et cetera will not be accepted.

Do not send .ZIP files. We won't get them. The University's e-mail system does not deliver them, because it thinks "zip = Windows; Windows = viruses". Use
tar cfz whatever.tgz source-file… to create .tgz files, but only if you need to submit more than one file.

So that your markers can compile and run your programs,

  • You may not use any library that does not come as standard with your programming language. We have carefully crafted all the études so that you don't need any such libraries. In the past we allowed third-party libraries with a requirement that you provide a copy that we could use without administrator privileges. This proved unworkable. Ironically, the students who tried this invariably ended up with worse programs than the students who stuck with the standard libraries.
  • Do not use GNU extensions in C, C++, or Fortran.
  • Each source file must include a comment saying which version of the language and library it assumes.
  • If building your program is more complicated than calling the compiler or interpreter for your chosen language, with default arguments, you must provide a README or Makefile explaining the build process.
  • Building and running your program may not involve the use of Ant, Maven, Gradle, or any build tool other than Make.
  • You must include the name of each contributor in every source file and report.

As a courtesy to your markers,

  • Every line must be terminated by Line Feed. That includes the last line.
  • Every line must be terminated by Line Feed only. That means no Carriage Return characters.
  • Do not use the Tab character.
  • Keep all lines shorter than 80 columns. (You can use ll.c to find the longest line in a file.)
  • Indent your programs neatly and consistently. Consider using indent or astyle.

You can use check326.c to check all but indentation. The astyle program can indent C, C++, Objective-C, C#, and Java.

When submitting reports, please submit plain text files (under the same courtesy rules as source code), HTML (preferred), LaTeX, or PDF files. Under no circumstances should you submit .doc, .docx, .odt or other word processor file types. Google Docs counts as word processing so is also forbidden.

You should think of your reports as being documents sent to a client answering questions that the client has raised — if they are too informal, too technical, or poorly presented they may be bounced for revision and resubmission.

If you have made significant use of any external resources in preparing your code or report, those resources must be identified, and acknowledged. Formal citation is not necessary, but enough information to let us find the resource is required.

If a submission is accepted you will get a reply that includes the phrase “complete and correct” or “passed” or a very close variant. When you receive such a message you can assume the submission has been accepted. Conversely, if no such phrase appears, then your submission has not been accepted and a resubmission is required. You can expect to be told about at least one defect that needs fixing in such a case. If you are at all in doubt, then check with mark326 before assuming either that you've finished, or that you haven't.


Etudes for the first half are listed here, the rest will be added.

Etude Type Points Name Notes
1 P 2 Ants on a plane An awk script to check input file format here
2 G 1 Syllable slam Deadline 19 July for Town Hall 2
3 I 2 Poker hands
4 G 3 Desert crossing Groups will be assigned, checking program here
5 I 1 A patchwork quilt
6 G 2 For Sale Town Hall 4 (Aug 3) updated source code
7 P 2 Joined up writing
8 P 2 Arithmetic
9 G 3 Sir Tet's carpets To be discussed in Town Hall 10 (Sep 21)
10 I 1 Red and green
11 G 2 A value proposition Java code and test data are here
12 I 1 Missing scores
13 G 1 Super size it Presentation in Town Hall 13 (Oct 12)
14 I 1 Evaluation

The études are revised from time to time, not to change what the requirements are but to clarify them or correct errors.

  • If an étude is labelled “I”, that means is must be worked on by an individual (all of you working on your own). Don't forget to put your name in your submission as well as the accompanying e-message. You can talk to other students about problems, but each of you must write your own program / report / whatever. You need not do the work in the lab, but if you come to the lab there will be someone you can ask for help.
  • If an étude is labelled “P”, that means is must be worked on by two students (a pair). One member of the pair should submit the program or report or whatever. Both members' names should be listed near the top of the submission where the marker cannot miss it. You may pair up with the same person if you both want to. You do not need to pair up with the same person every time. If you cannot find anyone to pair with, ask for help.
  • If an étude is labelled “G”, that means is must be worked on by a group of students. That's more than two of you. Three is good, four is good, more than four really won't work well. One member of the group should submit the program / report / whatever. Each member's name should be listed near the top of the submission where the marker cannot miss it. You may group with the same people every time if you and they want to, but need not. If you cannot find any group to join, ask for help. Everybody is expected to contribute in group work. Perhaps more importantly, everybody must be allowed to contribute.
  • The points are just a rough indication of expected workload. Recall that you must pass all 13 ├ętudes to pass the course.

 


Town hall meetings give you the opportunity to discuss discoveries and difficulties with the class. Details will be added here as the semester progresses.

Week Town hall discussion
1Welcome and planning
2Etude 2 results session
3Problem solving session example etude
4Preparation for Etude 6
5Job interview test problems
6Problem solving session example etude
7Jobs discussion with guest panel
.Mid semester break
8Mind control systems
9Etude 6 results session
10Discussion session of Etude 9
11How to make your program efficient (guest speaker: Emeritus Professor Geoff Wyvill)
12Presentation of Etude 13
13Evaluation session (Completion of Etude 14)

 


Resources

Richard O'Keefe has contributed a number of useful write-ups: (lightly edited)

  • arrays.htm explains the difference between arrays and mutable arrays and why it matters that Java and C# fail to support read-only arrays.
  • assert.htm shows you briefly how to write assertions in several programming languages. At one of the Town Hall meetings we discussed why to use them. As the Perl community put it, “die() early and die() often”.
  • bitwise.htm is a brief introduction to bitwise operations.
  • garbage.htm is a brief introduction to the problem of memory leaks in Java and Python.
  • absrel.htm is a brief introduction to the concepts of absolute and relative error, with an example program. This is for the Numbers étude.
  • tabling.htm presents an example of memoisation based on a Rosetta Code task.

Page maintained by Anthony.                     Last updated:  21st Sep 2017   12:15