Guy’s eight-person team does a bunch of computer vision (CV) stuff. Guy is the “framework Guy”: he doesn’t handle the CV stuff so much as provide an application framework to make the CV folks lives easy. It’s a solid division of labor, with one notable exception: Richard.

Richard is a Computer Vision Researcher, head of the CV team. Guy is a mere “code monkey”, in Richard’s terms. Thus, everything Richard does is correct, and everything Guy does is “cute” and “a nice attempt”. That’s why, for example, Richard needed to take a method called readFile() and turn it into readFileHandle(), “for clarity”.

The code is a mix of C++ and Python, and much of the Python was written before Guy’s time. While the style in use doesn’t fit PEP–8 standards (the official Python style), Guy has opted to follow the in use standards, for consistency. This means some odd things, like putting a space before the colons:

    def readFile() :
      # do stuff

Which Richard felt the need to comment on in his code:

    def readFileHandle() : # I like the spaced out :'s, these are cute =]

There’s no “tone of voice” in code, but the use of “=]” instead of a more conventional smile emoticon is a clear sign that Richard is truly a monster. The other key sign is that Richard has taken an… unusual approach to object-oriented programming. When tasked with writing up an object, he takes this approach:

class WidgetSource:
    Enumeration of various sources available for getting the data needed to construct a Widget object.

    LOCAL_CACHE    = 0
    DB             = 1


    def toString(widget_source):
            return {
                WidgetSource.LOCAL_CACHE:     "LOCAL_CACHE",
                WidgetSource.DB:              "DB",
                #WidgetSource.PROCESSED_DATA:   "PROCESSED_DATA", # @DEPRECATED - Currently not to be used
                WidgetSource.REMOTE_STORAGE:  "REMOTE_STORAGE"
        except KeyError:
            return "UNKNOWN_SOURCE"

def deserialize_widget(id, curr_src) :
     # SNIP
     widget = {
         WidgetSource.LOCAL_CACHE: _deserialize_from_cache,
         WidgetSource.DB: _deserialize_from_db,
         WidgetSource.REMOTE_STORAGE: _deserialize_from_remote
         #WidgetSource.PROCESSED_DATA: widgetFactory.fromProcessedData,

For those not up on Python, there are a few notable elements here. First, by convention, anything in ALL_CAPS is a constant. A dictionary/map literal takes the form {aKey: aValue, anotherKey: anotherValue}.

So, the first thing to note is that both the deserialize_widget and toString methods create a dictionary. The keys are drawn from constants… which have the values 0, 1, 2, and 3. So… it’s an array, represented as a map, but without the ability to iterate across it in order.

But the dictionary isn’t what gets returned. It’s being used as a lookup table. This is actually quite common, as Python doesn’t have a switch construct, but it does leave one scratching one’s head wondering why.

The real thing that makes one wonder “why” is this, though: Why is newly written code already marked as @DEPRECATED? This code was not yet released, and nothing outside of Richard’s newly written feature depended on it. I suspect Richard recently learned what deprecated means, and just wanted to use it in a sentence.

It’s okay, though. I like the @deprecated, those are cute =]

[Advertisement] Release! is a light card game about software and the people who make it. Play with 2-5 people, or up to 10 with two copies - only $9.95 shipped!