1
\$\begingroup\$

I wrote a Langton's Ant cellular automaton simulator in Ruby using object oriented principles. This code works. It requires the drawille library.

I would like to get feedback on what I could do better here, from optimizing the display to cleaning up code. I'm also wondering what I could improve in code quality and style.

#!/usr/bin/env ruby

require 'drawille'

# Langton's Ant
# Draws in terminal

class Direction
    @dir = 0

    def initialize(direction)
        @dir = {up: 0, right: 1, down: 2, left: 3}[direction] || 0;
    end

    def transform_vector
        case @dir
        when 0
            return {x: 0, y: 1}
        when 1
            return {x: 1, y: 0}
        when 2
            return {x: 0, y: -1}
        when 3
            return {x: -1, y: 0}
        end
    end

    def turn_cw
        @dir = (@dir + 1) % 4
    end

    def turn_ccw
        @dir = (@dir + 3) % 4
    end
end

module State
    OFF = 0
    ON = 1
end

class Tile
    @state = State::OFF
    def initialize(state)
        @state = state
    end
    def state
        return @state
    end
    def flip
        if @state == State::OFF
            return @state = State::ON
        else
            return @state = State::OFF
        end
    end
    def bool
        return (@state == State::ON ? true : false)
    end
end

class Screen
    @screen = [];
    @canvas = Drawille::Canvas.new
    @x = 0
    @y = 0

    def initialize(x, y)
        @screen = Array.new(y) { Array.new(x) { Tile.new State::OFF } }
        @canvas = Drawille::Canvas.new
        @x = x
        @y = y
    end

    def inspect
        string = "";
        @screen.each do |i|
            i.each do |j|
                string << (j.bool ? '██' : '  ')
            end
            string << ?\n
        end
        return string
    end

    def screen
        return @screen
    end

    def flip(x, y)
        return @screen[y][x].flip
    end

    def print
        @screen.each_with_index do |row, y|
            row.each_with_index do |cell, x|
                if cell.state == State::ON
                    @canvas.set(x, y)
                else
                    @canvas.unset(x, y)
                end
            end
        end
        puts @canvas.frame
    end

    def x
        @x
    end

    def y
        @y
    end
end

class Ant
    @x = 0
    @y = 0
    @direction = :up
    @screen = nil

    def initialize(x, y, direction, screen)
        @x, @y, @direction, @screen = x, y, direction, screen
    end

    def current_cell
        @screen.screen[@y][@x]
    end

    def step
        if current_cell.state == State::ON
            @direction.turn_cw
        else
            @direction.turn_ccw
        end
        @screen.flip(@x, @y)
        @x = (@x + @direction.transform_vector[:x]) % @screen.x
        @y = (@y + @direction.transform_vector[:y]) % @screen.y
    end
end

def main
    screen = Screen.new(160, 96);
    ant = Ant.new(79, 47, Direction.new(:down), screen);

    loop do
        screen.print
        ant.step
    end
end

main
\$\endgroup\$
  • 1
    \$\begingroup\$ The Tile class and its collaborators go to a lot of effort to make 0 and 1 act like booleans. Why not just use false and true? \$\endgroup\$ – Rein Henrichs Dec 13 '17 at 5:14
  • \$\begingroup\$ @ReinHenrichs Langton's Ant has variants that are more interesting - they require a tile having multiple types, so I wrote the class for extensibility purposes. \$\endgroup\$ – Dmitry Kudriavtsev Dec 13 '17 at 6:23
1
\$\begingroup\$

The code looks pretty clean. On first sight I notice some odd Ruby code.

Non-idiomatic Ruby

class Tile
    @state = State::OFF
    def initialize(state)
        @state = state
    end
    def state
        return @state
    end
    def flip
        if @state == State::OFF
            return @state = State::ON
        else
            return @state = State::OFF
        end
    end
    def bool
        return (@state == State::ON ? true : false)
    end
end

In the code above you first set @state and then inside initialize you set @state again. These two are not the same variable. Do not define instance variables outside class methods, unless you want to do some meta-programming with them.

You define method state for accessing the @state variable. As this is such a common pattern, Ruby provides a helper for generating such simpler getter methods:

class Tile
    attr_accessor :state

But all the places where state method is used, could actually use the bool method instead. This should make one realize that this whole Tile class could be completely eliminated and replaced with a plain boolean value instead.

Other smells

  • Screen class has @screen instance variable. It's not referring to itself, so a better name would be in order.
  • It's also exposing it directly to the outside world through screen method. Better to have a method like get(x,y) that would encapsulate the access to the coordinates array.
  • Screen has an inspect method that's unused. For debugging?
  • Screen has x and y fields, I think these are better called width and height.
  • Screen has a print method. I would instead recommend having a to_s method instead, so the Screen would not have a knowledge about printing itself, only of how to convert itself into string. One can then simply call puts screen to print it to console (the to_s method will be call automatically when casting to string).
  • Inside Ant.initialize all the variables are initialize on the same line, which I find confusing.
\$\endgroup\$
  • \$\begingroup\$ I have the Tile class for future extension (in case I want to implement some Langton's Ant variants). The bool method is one that I forgot to remove. I used Screen#inspect for output before I switched to drawille. Thanks for the tips on attr_accessor, field names, instance variables, to_s, etc. I find the one line initialization cleaner and easier to read, but if it's confusing for most people I'll change it. \$\endgroup\$ – Dmitry Kudriavtsev Dec 9 '17 at 1:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.