Constraints

To improve our programming design and skills, we can chose some coding constraints. This chapter aims to be a collection of constraints, that allows reader to challenge exercise after exercise with coding skills. Code kata is a learning method. During code kata, the purpose is understand single asplects of object oriented or functional programming.

As said in effectiveness chapter, each kata should be a new challenge. To learn something every time you do practice with a kata, you have to self constraint your practices sessions. Here a collection of constraints.

Exaggerating some aspects, we can learn when some language feature can be a tool or a double edge weapon. And when a constraints is not a way to deeply understand object oriented programming, should be a way to learn how to apply new rules in day by day work.

The purpose in not just playing with some new challenge. Code katas, code dojos and code retreats, shows show as some rules. Each rules purpose is to improve our perceptions of object programming design.

Write code without mouse

Maybe this stuff is only for vim users.

No IFs

In the world exists different campaigns against usage of if statements. Completely removes ifs, while or switch are forbidden for this constraint. Remember that is an exaggeration. As exaggeration should be keeped as is: the purpose is just learn to find different solutions.
This rule aims to remove the netsing exaggeration form developers habits. Sometimes developers use switch instead of switch. But this is a smell to hide another smell.
In Object Oriented paradigm, polymorphism can help developer to reach this scope. But not all languages implements polymorphism. This challenge could be achieved with interfaces. Our code will talk with them instead of talk with objects. Is the good place to learn how to mock and stubs.

TDDaiymi

In my experience, fiew developers practice the dogmatic test first way to develop write code. As Kent back says explaining test first practice, second D means driven. A lot of developer spend time creating classes and other files because, they says, it needed. One constraint, on Code Kata, is to force the practice of test first: following three basic rules of test driven development. This constraint, allow you to learn the way of tdd and bring what you can learn in your dayly work. First times TDD is practiced it could be a bit extreme and difficult practice. This is also the purpose of Code Kata: training within this practice you could remove the unfamiliarity of this practice. Once the practice is learned, you will do same things at work. You will test your code at work.

No naked primitives

This constraints aims to be good in object oriented programming. In this paradigm, developers must represent concepts with class names. This activity is often reached with value objects. A primitive values is a number, a boolean or a string. Depending on what is your programming language. Also array, lists and hash-tables are considered primitives for this challenge. The purpose is to wrap objects with objects that hide primitives in object boundaries. The trap here is the primitive obsession obsession. Like a wrapper of a wrapper of a wrapper. And this constraint aims to learn how to write code against over engineerization. Maybe this is the right place where we can learn to write code where variable names, classes an function speaks. Code must speak.

No void

All functions must return something.

Immutability

All data structure must be immutable.

Combining constraints

This is an amazing and challenging constraint. Is the customization of all rule in mind of each developer. Each developer can combine some basic rules for creation of its own. Here a list of basic challenges:

  • only void methods
  • no void returns: all methods must return something
  • no else keyword
  • no if statement
  • no getter and setters
  • no conditional statement
  • no fluent interface
  • only immutables objects
  • only static methods
  • no conditionals
  • only static fields
  • no loops
  • no void methods
  • one line methods
  • only four line per method after refactoring
  • only one level of indentation
  • no primitives
  • no mouse
  • no debugging
  • only static fields
  • only static methods
  • strictly follow the rule of three
  • two refactoring after each test passing
  • zero constructor argument
  • no more than two parameter per method

The fact, here, is that there are some roles that is exaggerated. Some other very easy to achieve. Here we can do experiments. Combine other constraints or split them in little parts. Here we are free to violate all other constraints. The rule is there are no rules.

Refactoring toward constraints

If you like TDD practice, you always refactor your code. Refactoring is already part of your familiar habits. This kind of constraint is instead forced in refactoring activity. While tdd consider one refactoring step for each feature, in this constraint we must have three commit of refactoring and just one for feature adding.
This focuses developer in refactoring activity. The process here is gree, refactor, refactor, refactor. In TDD the process is red, green, refactor.

results matching ""

    No results matching ""