The idea of code review is a very simple one: if you have someone else look over your code, they can probably help you make it better. Many software companies incorporate this into their development workflow, and it is not uncommon for code review to be mandatory before new code is accepted. While this works well in industry (not to say that it is without faults), it relies on the assumption that every developer writing code is also a code reviewer. If all code gets a second set of eyes and you assume that reviewing code is a much less time-consuming task than writing it in the first place, then the overhead of mandatory code review is fairly palatable.

When we look instead at teaching a moderately large programming class with a significant amount of programming work, it becomes essentially impossible for the teaching staff to look over student code with any amount of detail beyond superficial correctness, code style, and maybe some high-level concepts. While this is depressing, it is also inevitable when you look at the numbers (we’ll use some approximate numbers from a recent iteration of MIT’s 6.005: Elements of Software Construction):

100 students × 3 projects × 3000 lines per project / 3 students per group
= 300,000 lines of code

300,000 lines of code / 4 TAs / 15 weeks per semester
= 5,000 lines of code per TA per week

I’m not comfortable with the idea of looking at 1,000 lines of code per day as a TA. That’s not even including the smaller problem sets we had throughout semester.

How can we make sure that student code gets looked over and corrected?

One approach is to bring in more people by bringing the students into the review process. This has three advantages: reducing the load on the teaching staff, teaching the students how to review code, and exposing students to each other’s code and comments. It is easy to imagine a class where after an assignment is due, each student is then given the task of reviewing some amount of code written by classmates, after which the feedback would be collected and presented to the students for their own benefit, and also to the teaching staff to facilitate the grading process.

While existing review systems are built for small teams of experienced developers whose primary goal is to improve code quality, our problem is fundamentally different. A classroom code review tool needs to be built for a large group of students of varying levels together with a small group of (hopefully experienced) teaching staff. Furthermore, while code quality is important, the primary goal in a classroom is to teach the students how to be better software engineers. By designing a few key features into the system with the characteristics of our reviewer population in mind, we can accelerate and improve both the quality of the code review and the quality of the student learning that result:

• Code partitioning – Because it would be unfeasible to simply distribute an entire project to a student for review, student code needs to be partitioned into small “chunks”, perhaps on the order of 50 lines each, to distribute to peers.
• Discussion support – Users can reply and vote on existing comments, allowing students to directly communicate with each other in the context of code.
• Reputation system – Users are rewarded for high-quality comments, incentivizing  participation. This can be in the form of “karma” points, achievements or badges, or both.

The other approach is to bring in better tools to help streamline and automate the review process as much as possible. This is something that doesn’t quite exist yet in the wild. Our current state-of-the-art tools to ensuring code quality fall largely into two categories: completely automated systems like testing frameworks and static analysis, and completely user-driven tools like existing code review systems (Gerrit, Rietveld, Review Board).

Ideally, our tool would sit between these two extremes and aim to increase the efficiency and quality of the code review by automating tedious work and gathering relevant data. Our users are experience-rich and time-poor, so the it is the primary responsibility of the tool to decide how best to target their attention.

• Automatically generated feedback – Existing static analysis tools (Checkstyle, FindBugs) can often generate many of the same comments that human reviewers would otherwise leave. Why not add the output of those tools into the same interface that human reviewers use and allow users to upvote/downvote/reply to them.
• Clustering similar code – If a piece of code is unfamiliar to the reviewer, it could be extremely helpful to look at a piece of similar code somewhere else in the system that has already been reviewed and annotated.

In short, my thesis work is to improve both the code review process itself and software engineering education by adding students (and others) into the review process and giving them an intelligent, easy-to-use tool to make that process as easy and streamlined as possible.

One of the points I made during the first class was that programming is more about a conversation with other people rather than a conversation with a machine.

When one first starts learning to program, it really does feel like you are somehow talking to a computer. You type some words in a text file, save it, and when you run it, your silicon companion will either helpfully respond with the correct answer or squawk at you irritably and tell you to try again. For small programs that never grow beyond one-off scripts and toy projects, this is about the highest level of discourse that really ever gets reached.

As your projects grow in both the amount of work that needs to be done and in the time it takes to complete them, it becomes increasingly important to write your code not just as instructions to a computer, but as documentation to anyone else working on that code. You are just as much, if not more, telling the computer what to do as you are telling the next person to read the code what you mean to do. Sometimes, the next person to read the code might even be yourself in the future, well after you have forgotten the thought process behind the original code.

I’ve found that thinking of programming this way has inevitably led me to write clearer, better code and clearer, better comments. I imagine a colleague sitting next to me and then I pretend that I’m not allowed to communicate in any way other than the contents of the text file that I am editing. If the code is obvious, then my intentions are clear. When I do something that looks funny, or pause to think about a decision (perhaps some trade-off or compromise), I imagine the furrowed brow and confused expression on my friend’s face. These are then quickly remedied with an illuminating comment or bit of documentation.

Writing clear, understandable code isn’t a once-over kind of process after the fact, and it doesn’t have to be difficult either. I’ve found that by keeping my imaginary friend in the back of my head while I do my work, the output is inevitably better for myself and for others. Or maybe this is all just an excuse to justify having an imaginary friend.

A lot of computer users, when using text editors or any other application that use monospaced (having the same width for every character, useful for programming and related tasks) fonts to render text (source code, plain text, e-mails, markup, etc.), stick with the default font. On some platforms, notably Mac OS X and most modern Linux distributions, this default font is a fairly reasonable and attractive typeface like Monaco or Monospace. On Windows XP and Vista, however, the default monospaced is Courier New.

Courier New, 10pt

Recently, Microsoft released several new fonts with its new operating system, Vista. One of these fonts is a monospaced font specifically designed for programming, called Consolas. This font, and a few other nice fonts, is available by default in Vista and Office 2007, and can also be downloaded as part of the Office Compatibility Pack for free.

Consolas, 10pt

Isn’t that better?

The only caveat is that Consolas is designed with ClearType font smoothing in mind, and if you do not have ClearType enabled, then things will look very ugly.

My task is to design and develop a client-side Javascript framework that takes event data in some format (iCal, XML, etc.) and renders it out to a number of different, configurable, dynamic views. What kind of views will Timegrid support? For starters, it will support all of the views that Google Calendar is currently capable of: weekly, monthly, etc. Timegrid is more flexible than Google Calendar though. Imagine that you want to render a table of events happening in various locations, and you want each column to represent a different room, and each row to represent a starting time. Timegrid will be able to handle that as well.

Timegrid is designed to be easily configurable, incredibly flexible and customizable, clean, and beautiful. Good thing I have all summer to work on it.

Timegrid Project Page

• Prototype – A fairly large (~50kb) Javascript library that defines several classes to make your life easier. There are many functions provided that simply reduce the amount of typing you have to do, and even Ruby-style closures for lists, through the Enumeration class. Of course, it also provides some great classes for AJAX tasks as well. However, be warned, there is very little official documentation for Prototype.
• script.aculo.us – A Javascript library that layers itself on top of Prototype and adds a plethora of eye candy. Some of the effects it includes are: drag & drop support, fading, sliding panels, and highlighting.

Working with either library is extremely pleasant, especially when compared to the task of manually coding all of the functionality that they provide for free. Also, I’ve seen the end results on many websites and they look great. Highly recommended.