Constraint List

Pick 1 or 2 to add an extra challenge when doing a kata. The constraints have been gathered from across the web with a few of our own thrown in.

Constraints work because they take away a tool you reach for without thinking. Once else or a loop is off the table, you have to find another way to express the same behavior, and that search is where new design options show up. The goal is not to write production code this way; it’s to widen the set of moves you can make when you are back in production code.

The Constraints

1. Only four lines per method - After refactoring
2. Immutables only
3. Only one level of indentation per method
4. Do not use else
5. No passing of primitives between methods as parameters or return types
6. No Properties/Getters/Setters
7. No loops
8. No void returns - All methods must return something
9. No conditional statements
10. No chained method calls - 1 dot per statement
11. No objects
12. No mouse
13. No debugging
14. Only static methods
15. Only static fields
16. One level of abstraction per method
    1. Let the code be read as if it was a small story.
    2. Collapse methods and read only function names top down
17. Communicate clearly, meaningful naming taken from the Domain (Kata)
18. Only void returns - All methods must return nothing
19. Strictly follow the rule of three
    1. Allow duplication to emerge at least 3 times before removing it
20. 2 refactorings after each passing test
21. Do not use any classes with more than two instance variables
22. Zero constructor arguments
23. No more than 2 parameters per method

How to use the constraints

• Start with one. Two constraints that interact (for example no loops and no conditional statements) can turn a short kata into a long one. Add a second only once the first feels manageable.
• Pick a kata you’ve already solved. A familiar problem lets you notice how the constraint changes your solution rather than fighting the problem itself.
• Apply it during refactor, not only green. Several constraints, such as only four lines per method, are meant to be enforced after refactoring. Get to green first, then reshape the code until it complies.
• Debrief. After the session, write down one thing the constraint forced you to do differently and whether you’d use that move without the constraint.

What the constraints train

Focus	Constraints
Small, focused methods	1, 3, 16, 23
Replacing conditionals with design	4, 9
Encapsulation and object design	5, 6, 10, 21, 22
Functional style	2, 7, 8
Working without your usual tools	12, 13
Unfamiliar paradigms	11, 14, 15, 18
Naming and duplication	17, 19, 20

Suggested pairings

• No else or no conditional statements with Roman Numerals or FizzBuzz Whiz, where the rules invite long if chains.
• No primitives between methods with Bank Account or Shopping Cart, so money and quantities become types of their own.
• No loops with Prime Factors or String Calculator, which push you toward recursion or collection pipelines.
• One level of abstraction per method with Bowling Game or Tennis Refactoring, where the scoring rules read best as a short story.