CIS 552: Advanced Programming

Fall 2017

  • Home
  • Schedule
  • Homework
  • Resources
  • Style guide
  • Syllabus

Project Rubric

Correctness

  • Does it work? And is the project "complete"? (Pick one from below)

    • This isn't a project.
    • Project has obvious deficiencies. Clear that more time should have been spent completing the assignment.
    • Subtle bugs, but mostly works
    • Project achieves its (perhaps refined) goal and works as intended.
  • How "difficult" was the project? (Pick one from below)

    • An "easy" project that requires fairly trivial data structures, and team members ignored suggestions during project feedback/checkpoint about how to extend. Any difficulty with project was mostly in connecting various libraries together in Haskell.

    • A "medium" project that involved some of the easier course concepts, such as lists and trees.

    • An "extensive" project that include a significant amount of well-thought out code and design. Clear that students stretched themselves in some way and produced something more in-depth than, say, a CS2 data structure.

Design

Not all projects will demonstrate the same opportunities for design. The following are qualities that projects can use to demonstrate their knowledge of CIS 552 design principles. Simple projects may lose points here because there may not have enough opportunity to encounter meaningful design decisions.

  • Decomposes the project into modules. Gives thought to constructing a reusable interface for at least one module (i.e. explicit export list, own type class, or clear indication that this should be a library.) We are especially interested in the compositionality of the library operations---witnessed perhaps by Monoid or Applicative/Monad instances.

  • Defines appropriate data structures and uses them appropriately. In particular, the project employs newtypes and/or datatypes instead of builtin types when appropriate. The data structures used lead to good running time (i.e. the code doesn't use !! for lists, or include redundant traversals). Furthermore, the type structure should captures invariants.

  • Uses a nontrivial purely functional algorithm. In particular, the code does not put pure code in the IO Monad. The project may extend or adapt a homework problem or (better) develop or implement a new algorithm.

  • Uses abstractions covered in class (e.g. Monoid, Functor, Applicative, any Monad other than IO). This may be merely a use of some of the libraries we developed in class (e.g. State or Parser) or it may be as sophisticated as the use of monad transformers.

  • Demonstrates abstraction via higher-order functions or type classes. This also includes well-designed helper functions that identify common patterns. We would like to see uses of higher-order library functions, such as map or fold. Even better is a design that uses new higher-order functions to structure their program.

Testing

Testing should be appropriate for the project and should be a convincing demonstration of the project correctness (without relying on the demo). We particularly want to see code that was written or refactored to make it easier to test.

  • Regression tests
  • Unit tests
  • Quickcheck properties

Other

Other considerations may affect the final score of the project. These include:

  • Does the project follows style guidelines ?
  • Did the project require learning advanced features (profiling, type system features, etc.) ?
  • Did all team members work together on the project?

Point breakdown

  • Proposal: 10
  • Checkpoint1: 10
  • Checkpoint2: 10
  • Presentation: 5
  • Demo: 65
Design adapted from Minimalistic Design | Powered by Pandoc and Hakyll