Writing C Programs

Here are some recommendations for optimizing how you write C code for CS 107.

Set up a .ssh/config file

You're going to be typing ssh YOUR_SUNET@myth.stanford.edu many times in your time at Stanford. You can shorten it to ssh myth by doing the following on your own computer WHILE NOT ALREADY ssh'ED INTO THE MYTH MACHINES.

  1. Create the directory ~/.ssh if it does not already exist.
  2. Within that directory, create a file called config.
  3. Inside that file, put the following text in 3 lines:
Host myth
Hostname myth.stanford.edu
User YOUR_SUNET

Now you can just type ssh myth in new terminals to connect to the Myth machines. I've configured this, so you'll see me doing this.

Use two terminals at once

Open two terminals and resize one to take up the left half of your screen, and the other to take up the right half. ssh into the Myth machines on both of them, and open the C file you're working on in one of them. Now you never have to quit your text editor - you can keep it open indefinitely, and run commands like make and sanitycheck in the other terminal.

Here's what it looks like in action:

Get used to the save-make-run cycle

Programming is a cycle of tweaking your program and testing it, over and over again, until it works the way you intend. To ensure you're testing the version of your program that includes your tweak, make sure you get into the rhythm of doing the following:

  1. Make a change to your C source code.
  2. Save the file (:w in vim, CTRL+X,CTRL+S in emacs).
  3. Pop over to your other terminal.
  4. Run make.
  5. Run your program on the current test case (e.g. ./triangle 0).
  6. Use the results to inform your next change to your C source code.

Run the sample solution program to understand how your program should behave

Sometimes it's unclear what your program should do in scenario X. Are you supposed to report an error? Segfault? Ignore it?

While running to Ed to ask is one option, it's always safe to run the sample solution to see what it does. If you match the behavior of the sample solution, you're golden. (If you ask Ed, we'll probably end up referring you to the handout or telling you to run the sample solution anyway.)

As an example, for assign0, you can run the sample solution for the triangle program like this:

samples/triangle_soln

The sample solution will have a filename similar to that. Use ls to view the contents of the samples directory to find the exact name.

Stop running sanitycheck all the ****ing time

sanitycheck is a great tool for just that - checking your sanity and seeing if you pass basic test cases. You should only be running it after you've completed a significant milestone in your work and want to check if your program continues to pass previous test cases.

Prefer to run your program manually so you can focus on a particular test case you're failing instead of getting a dump of everything (including results from programs you haven't even written yet) from sanitycheck.

Add to custom_tests anytime you think of a good test case

sanitycheck is bundled with only very basic test cases, and these will get more and more bare as the quarter progresses. You'll want to write your own test cases and add them to custom_tests (look inside the file and match the syntax already present!).

If you notice a bug on a particular input and fix it, add the input you failed on to custom_tests to ensure your program continues to pass it as you make further changes.

Assuming you're in your assignment root directory, you can run sanitycheck on your custom_tests by running

tools/sanitycheck custom_tests

Usually part of the points are awarded for writing test cases, so you only help yourself by doing this :)