Meta

• Read this list! It might look like some generic “blah blah” that you don’t really need, but it will make it much easier for you to keep up with things.
• If it’s early in the semester, make yourself a reminder to go over these tips again in a few weeks Some of these tips will not make sense until you get to the heavier homework, and by then you’ll probably forget many things that could save you a lot of efforts, so it will be very helpful to re-read it later again.

Keeping Up

• Read the class notes! This might seem like an obvious thing, but one of the most common answers to the “what could I do better” in the course reviews goes along the lines of “I should have read the notes”.
• Make sure you look at the course home page frequently for important announcements. You can even leave a browser window open with this page, and it will get auto-updated when there’s new content.
• You can jump to various pages and sections quickly by entering their name in the top-right “page finder” box that is included in all pages, including this one (hit the slash key (/) to get there quickly).
• In particular, keep an eye on your performance. You’re given several pieces of information about your performance: stats charts and the information in the grades.txt file in the “Summary” row on the Handin server. You should plenty of grade indications to know when you’re not doing so well: catching this early and discussing it with us will make a “recovery” much easier.
• Piazza can have many posts, especially when a homework is due. Don’t leave reading these messages for later — you should at least have a quick look at what’s there so you won’t miss important information.
• Read the Email and Piazza Policies handout to use piazza more effectively and save time for everyone who reads the messages, making everyone’s life easier. (Including yours: good questions get quicker answers.)
• You can also consider a utility for tracking changes on a web page. For example, Firefox has an addon called “Update Scanner” that can alert you when there are changes to a web page, and Google Reader can generate a feed that will show you changes in any URL if you just enter that URL as a new subscription. There are also a number of free services that can mail you when a page has changed. (If you use such a utility, you can also make it track homework pages to keep up with updates to the texts.)
• Remember to be prepared for PLQs too: review the material if you need to, make sure that you’re logged-in to the PLQ app on your phone or laptop, and most importantly — read the topmost green log line when you use the app, this line shows you what answer you’ve submitted.
• If you’re not doing too well on the PLQs, please consider suggesting PLQ questions. It does require some work to review the material to the point where you can come up with a good question, but it pays off in two ways: (a) if your suggested question is used, you’ll know its answer (I frequently modify the answers, but since you’ve looked into it, it’ll still be pretty easy), (b) just trying to come up with good questions is a good preparation for how to solve them better — this is something that will generally help even if your question is not used.
• And finally, see if there are Tutors available, or consider becoming one (which is an excellent way to hugely improve your performance).

Homework Submission

• You’re encouraged to submit as frequently as you want, treat the handin server as a remote safe storage for your homework. You can also use the handin button to retrieve the last version of the code that you submitted.

• It would be good to remember how you worked in Fundies, and adjust your work based on that.

• Begin your work by getting some minimal code that can be submitted, so you can start using the handin server as such a storage. This usually means having a number of definitions in the code. Make sure that these bindings have comments next to them, making it clear that they’re a yet-unimplemented part of the homework.

  The server will warn you about a penalty for incomplete coverage as long as you don’t have enough tests — you should accept this penalty to have your code saved, and then continue working on getting the code to work and the tests to cover your code. Remember the scratch option if you want to save a checkpoint that cannot be submitted (because it cannot even be evaluated by the server).

• But note that the server warns you about incomplete coverage for a reason! When it does so, be aware of the high penalty that you will get automatically — so don’t just accept it blindly!

• If you just can’t get some part(s) of a homework done, do not give up on getting complete coverage since that will result in a heavy penalty on top of the missing part. If all fails, write a stub function and a test to get the stub marked as covered, with a comment saying that you did that to avoid the coverage penalty.

• The scratch “homework” accepts anything you submit (the server will not evaluate the code). You can use it to test that everything is working, and as a kind of a remote file storage for your code. Note that the handin button can be used to retrieve the file that you submitted last, making it possible to conveniently work on the remotely saved file.

Writing Good Code

• Make sure you read the Style Guide.

• Some style mistakes are particularly bad, and are considered bugs. For example, “flat” non-indentation, or worse, “out-dented” code.

• Be aware of runtime costs, and don’t spend cycles needlessly. For example, (= (length l) 0) is equivalent to (null? l), but the length will scan the whole list (so it is O(n) instead of O(1)). Also, (append l (list x)) to add an element to the end of the list will scan the whole list and copy it, which is much more expensive than the O(1) cost of (cons x l).

• Especially with the heavier homework later in the class, pay attention to tests: the right kind of tests could save you a ton of work. Specifically, when you have some bug, minimize the test that demonstrates the bug as much as possible, so you know know where to look for it.

  For example, this item was added after talking to a pair of students and realizing that they just spent several hours over a bug, because they were looking at the wrong place. A minimized failing test led them to a different piece of code, and it took less than two minutes to fix it.

• Pay attention to your work strategy, especially note the differences from your Fundies days.

Working with DrRacket (or other editors)

• You should be using the “Racket” language throughout most of the course, with a language specification line that looks like:

  #lang pl ...

  In the language selection dialog (shurtcut: Ctrl+L / Cmd+L), click the “Show Details” and choose the “Syntactic test suite coverage” option to see which parts of your code are not covered by tests yet (they will be painted red), or when you have complete coverage (when the colors stay the same after running).

• To conveniently navigate Racket code, you can use Alt with the arrow keys to move over an expression — complete identifier, number, string, or a parenthesized expression. (On a mac, use Esc followed by the arrow key.)

• Racket programmers never count parenthesis. There’s two sides for this: reading code, and writing code (including any editing, i.e., debugging).

  For reading code: if you keep your code properly indented, you will find that the structure of the code should be obvious by its indentation.

• For writing code, if you never perform edits that can break the parens, then you’ll never need to “count how many parens I should close now” (or brackets, double-quotes, etc).

  It’s nice to have an editor that highlights matching parens, or even better an editor that inserts a closing character when you type the opening one. But it’s possible to work in an editor that doesn’t do that, even notepad!

  The trick is to write your code in such a way that the parentheses are always balanced, mimicking what the better editors do — never insert an open paren, bracket, brace, or double-quote without inserting the closing token too. DrRacket makes this easy to do: just use Alt while you’re typing one of these open tokens, and DrRacket will insert the matching closing one too. (On macOS, hit Esc before the open token.) If you do this while some text is selected, it will get surrounded by the delimiters.

  The fancier option is available too: go to Preferences ⏵ Editing ⏵ General Editing, and turn on “Enable automatic parentheses…”. (You can get to the preferences via the menus, or using the Ctrl+; / Cmd+; keyboard shortcut.)

• Related to the above: if you’re doing some structural change, do so without breaking the parenthesizing. For example, say that you want to remove an unnecessary let around a piece of code — don’t just delete the (let () line and then the dangling ) (since there’s probably a bunch of them, and now you need to guess which one). Instead:

  • select the whole body expression
    • place the cursor before the expression, then use Alt+Shift+Right to select the whole expression (again, use Esc on a mac),
    • —or— double click one of the parens to select the whole thing,
  • cut it (Ctrl+X / Cmd+X),
  • select the whole let expression (same as above),
  • paste the copied body over it (Ctrl+V / Cmd+V),
  • and reindent it (selecting the pasted code again and hit Tab). The important thing here is that throughout this process there is no point where the parenthesis can become imbalanced.

• DrRacket can make the open-square-bracket key ([) into a magic key that guesses which paren shape should actually be used. You can enable that in Preferences ⏵ Editing ⏵ Racket ⏵ “Automatically adjust opening square brackets”. (To force square brackets, use Alt/Esc.)

• On the REPL (the interactions), you can use Ctrl+Up to get the last entered expression.

• DrRacket has a lot more key bindings, you can see a list of them from the Edit menu.

• In addition to line comments (;), and block comments (#|...|#), Racket has expression comments: #;. When the reader sees a #; in the input, it will read the following expression, and discard it. This is especially convenient while debugging, since it gives you a convenient way to completely ignore an expression.

• Instead of discovering too late that you have lines that are too long, you can make DrRacket show you a “width guide”. Turn in on in Preferences ⏵ Editing ⏵ General Editing ⏵ Maximum character width guide. It is also generally useful while working since it’s yet another indication that your code is getting too complicated and should be split into smaller functions.

• You don’t have to use DrRacket as your editor if you don’t want to. You can use any editor for your editing, and only switch to DrRacket to run the code. DrRacket will prompt you to revert the file if it was modified.

More Help

• Remember that your homework is being graded with comments. Don’t just blindly accept your grade: go over your graded homework and see what you did wrong so you can avoid these mistakes in the future. (Plus, you might catch a grading mistake…)
• The graders also serve as TA’s: you can schedule a meeting with them and get some help with the material. This is especially useful if you’re worried about lagging behind.
• Look at the tutors page for additional help.
• Repeating the above: keep an eye on your performance, and seek help as soon as possible if you realize that you’re starting to “slide down”.

Navigating these Pages

• ? — open this help text.
• To quickly find pages and jump between them, use the “Page Finder” at the top of all pages.
  / — open up the finder.
• \ — open the table-of-contents without reaching for your mouse.
• Use the B icon next to the page finder to switch themes, if you prefer a light theme or unsaturated colors.
• `, ~ — when viewing a toplevel page, go to the next/prev section.
• You can leave the main page open: it will self-update when there are changes (new homework announcements, office hours opening/closing etc).