Discussion 1B: F 4:00-6:00pm in BH 5264 CS 32 – Spring 2008 – UCLA
Office Hours: M 12:30-1:30pm, W 11:30-12:30pm in BH 4428 chuong [at] cs [dot] ucla [dot] edu

News | Projects & HW | Discussions | Related Materials

Visual C++ Debugger Demo

How to write a report

  • No essay style
  • Organized (headers, bullet points, etc.)
  • Clear / Short / to the point

How to do well in this class

1. Follow our trivial advices (and yet, some people will find these are too trivial that they decide to ignore them). Please don’t learn the lesson the hard way. Your fellow students did, and they proved their point with their grades barely made it to a D-

  • always start early. If you finish your 1st and 2nd projects within 1 hour, that definitely does NOT mean that the 3rd project will be of the same level. Do NOT wait till the last day (or even the day before the due date) to start working on a project. The difficulty of later projects will be 10x of earlier ones.
  • develop incrementally, this means to write your code step by step
    • write a few lines of code, or a function
    • compile your code, fix any compile errors if needed
    • test those lines of code or that function, fix any runtime errors if needed
    • repeat

2. READ the spec, READ the spec again, and READ the spec one more time

  • 1st time you read it: skim through it, get a general idea of what the project is about (after reading, you should know the main things you’re expected to do)
  • 2nd time you read it: get into the details (after reading, you should be able to go straight into coding)
  • 3rd time you read it: double check the details (you should be working on the code right now, and looking at the spec for something you might have missed or overlooked)

3. Always start something

  • whether to create an empty Project in Visual C++
  • or to set up empty files with the correct names you’re supposed to name them
  • or to have a skeleton framework of your project set up
  • or to copy/paste the given code in the spec to your files
  • or to write the pseudocode which later will become the comments of your code
  • or to start working on the report
  • or to think about the test cases