1. 6
  1.  

  2. 1

    I’m the author of the Honorable Mention submission. I had hoped to win the contest, but I must acknowledge that the winning submission had more bad code than mine. Congratulations, group __1EC7__ (ikbenlike and Zeroji).

    The summary of my entry didn’t mention some of its bad properties, probably due to the goal of keeping the article short. Here are two more bad parts that I am especially proud of:

    • The “intuitive” format that the program changes the input to is not only unnecessary, it also adds ambiguity. Instead of using the letters L,R for turns and the letters N,S,E,W for cardinal directions, the program uses the letters U,D,R,L (up, down, right, left) for directions. So the casewhen expressions in right and left handle the values L,D,R,U, and the casewhen expression in handle_turns_chars and the final direction calculation code also handle the values L,D,R,U, but the D and U cases are just commented out as “not needed”.

      This ambiguous notation actually stemmed from an initial misreading of the problem. I skimmed over the problem description so fast that I didn’t see what characters to use for the cardinal directions, so I used U,D,R,L from the start because they really were more “intuitive” to me. Then I kept using those letters even after seeing the ambiguity they added.

    • The four command-line arguments are read from ARGV in an overly abstract, functional way that is not natural in Ruby:

      # arguments
      processors = [
        method(:eval),
        method(:eval),
        method(:map_dir_to_intuitive_dir),
        lambda { |arg| arg }, # leave it alone
      ]
      init_x, init_y, init_dir, cmd_str = ARGV.zip(processors).map do |arg, processor|
        processed = processor.call(arg)
      end
      
    1. 2

      Yeah, those were some nice touches that didn’t make it into the summary :)

      I’ll tell you that when I met with the other two judges it was a really hard decision between yours and the winning entry. Yours has more the “feel” we’re going for – but once it was clear that the other wasn’t just stacking languages for obfuscation, but had this “legacy codebase evolved through stacks over time” feel, it was decided to focus the teardown there.

      That much to say: thanks so much for your participation, we really enjoyed it!