LCD Numbers Kata Object Calisthenics with PMD Check
Requirements (copied from Ruby Quiz)
Write a program that creates an LCD string representation of an integer value using a 4x7 grid of space each, using minus and pipe characters for each digit. Each digit is shown below:
-- -- -- -- -- -- -- -- | | | | || || | || || | | | | | || || | || || | -- -- -- -- -- -- -- | | || | | || | || | | | | || | | || | || | | -- -- -- -- -- -- --
The bar size should be adjustable. The default value is 2 - as shown above. Read more about it at RubyQuiz.
There are sample LCD outputs in the
- Only One Level Of Indentation Per Method.
- Don't Use The
- Wrap All Primitives And Strings.
- One Dot/Arrow (dereference) Per Line.
- Don't Abbreviate (long names).
- Keep All Entities Small. (50 lines of code per class)
- Not More Than Two Instance Variables.
- First Class Collections.
- No Getters/Setters/Properties.
Checking Code for Compliance
The Code Cop Custom PMD Rules contain PMD rules to check code for compliance with Object Calisthenics'.
This project is set up to check the code using the Maven PMD Plugin on each
To check the setup run
mvnw test on the sample code. It will show two violations:
[INFO] PMD Failure: SampleClass.java:2 Rule:TooManyFields Priority:3 Too many fields. [INFO] PMD Failure: SampleClass:9 Rule:NoElseKeyword Priority:3 No else keyword.
You can also check the rules on their own with
By using the Maven Shell the time to run the check can be reduced by 50%.
Limitations of Checking Code
Obviously code analysis cannot find everything.
For example the
PrimitiveObsession rule (Wrap All Primitives And Strings) allows primitive values in constructors and getters because they are needed to implement Value Objects.
On the other hand these getters are getters, so
NoGetterAndSetter will flag them.
Rule #4 (One Dot Per Line) is checked using PMD's own
LawOfDemeter, which checks for the Law Of Demeter. Now the LoD is not about counting dots per line, it is about used types.
So sometimes a single dot in a line will already violate the LoD.
Finally it is very difficult to check for abbreviations, so rule #5 is not enforced.
You can use
// NOPMD comments and
@SuppressWarnings("PMD") annotations to suppress false positives.
I recommend using exact suppressions, e.g.
@SuppressWarnings("PMD.TooManyFields") to skip issues because other issues at the same line will still be found. Use your good judgement. The goal of this exercise is to follow all nine rules, not to suppress them.
See my blog post about Object Calisthenics and how to enforce it for more details.
This work is licensed under a New BSD License, see
license.txt in repository.