important parts of your code.

    Line Comments ~

    Also, lines that are non-obvious should get a comment at the end of the
    line. These end-of-line comments should be separated from the code by 2
    spaces. Example: >c

        // If we have enough memory, mmap the data portion too.
        mmap_budget = max<int64>(0, mmap_budget - index_->length());
        if (mmap_budget >= data_size_ && !MmapData(mmap_chunk_bytes, mlock)) {
          return;  // Error already logged.
        }
<
    Note that there are both comments that describe what the code is doing,
    and comments that mention that an error has already been logged when the
    function returns.

    If you have several comments on subsequent lines, it can often be more
    readable to line them up: >c

        do_something();                      // Comment here so the comments line up.
        do_something_else_that_is_longer();  // Comment here so there are two spaces between
                                             // the code and the comment.
        { // One space before comment when opening a new scope is allowed,
          // thus the comment lines up with the following comments and code.
          do_something_else();  // Two spaces before line comments normally.
        }
<

    NULL, true/false, 1, 2, 3... ~

    When you pass in a null pointer, boolean, or literal integer values to
    functions, you should consider adding a comment about what they are, or
    make your code self-documenting by using constants. For example, compare:
    >c

        bool success = calculate_something(interesting_value,
                                           10,
                                           false,
                                           NULL);  // What are these arguments??
<

    versus: >c

        bool success = calculate_something(interesting_value,
                                           10,     // Default base value.
                                           false,  // Not the first time we're calling this.
                                           NULL);  // No callback.
<

    Or alternatively, constants or self-describing variables: >c

        const int kDefaultBaseValue = 10;
        const bool kFirstTimeCalling = false;
        Callback *null_callback = NULL;
        bool success = calculate_something(interesting_value,
                                           kDefaultBaseValue,
                                           kFirstTimeCalling,
                                           null_callback);
<

    Don'ts ~

    Note that you should never describe the code itself. Assume that the
    person reading the code knows C better than you do, even though he or she
    does not know what you are trying to do: >c

        // Now go through the b array and make sure that if i occurs,
        // the next element is i+1.
        ...        // Geez.  What a useless comment.


Punctuation, Spelling and Grammar ~

Pay attention to punctuation, spelling, and grammar; it is easier to read
well-written comments than badly written ones.

Comments should be as readable as narrative text, with proper capitalization
and punctuation. In many cases, complete sentences are more readable than
sentence fragments. Shorter comments, such as comments at the end of a line of
code, can sometimes be less formal, but you should be consistent with your
style.

Although it can be frustrating to have a code reviewer point out that you are
using a comma when you should be using a semicolon, it is very important that
source code maintain a high level of clarity and readability. Proper
punctuation, spelling, and grammar help with that goal.


TODO Comments ~

Use `TODO` comments for code that is temporary, a short-term solution, or
good-enough but not perfect.

`TODO`s should include the string `TODO` in all caps, followed by the name,
email address, or other identifier of the person who can best provide context
about the problem referenced by the `TODO`. The