Hammer's Code Critique Rules

gistfile1.txt

1. We evaluate the code from the beginner's perspective. We can assume
mediocre Ruby and mediocre Rails knowledge but we try to look at the
code as if it is the first time we have seen it. This allows us to try
to bring fresh perspectives to the code (and, hopefully, improve the
code for people that are reading it for the first time).

2. As in a retrospective, we assume that everyone involved was doing
the best that they can with the knowledge that they had at the time.
This is not a session to assign blame or to even feel guilty. We are
all trying to improve. That being said, it is expected that the
critiques are as civil as possible.

3. Testability is key. If something is not testable, it is one of the
largest indicators of poor design.

4. Idiomatic code is better code. We strive to be idiomatic with our
code, if we can. This is related to the beginner's perspective but
we do not want to use clever tricks or surprising results in our code.
Leave that for the Wat screencasts :)

5. Be ready to explain other principles and why they are good. For
example, if you bring up SRP [Single Responsibility Principle] you
should be able to explain why the class violates it and what SRP
actually means.