Programming Principles, Rules and Recommendations Cheatsheet
Programming Principles, Rules and Recommendations Cheatsheet
Hello,
Last book I finished is Agile Technical Practices Distilled by Pedro M. Santos, Marco Consolaro and Alessandro Di Gioia. The book is crammed with concepts from a very wide range of topics and a good bunch of them, specially in the beginning, relate to coding.
At some point, I felt overwhelmed by rules, recommendation, practices, premises and so on because of my very limited cache memory. It’s fine to work focused on one specific criteria in a Kata (or even at work), but I wanted to have something at hand to be able to recap on the ones that I found more important in an easy way. Hence, I made myself a cheatsheet that I could print and have next to me while coding.
In the cheatsheet you can find:
-
The 4 rules of simple Design (by Kent Beck) - These four simple rules sorted by precedence (ones on top more important, the one at the bottom less) are an excellent rule of thumb to guide your programming process.
-
SOLID Principles (by Uncle Bob ) - Five principles on which properties should your classes follow. Even though it is OO specific, they still can be mapped to functional programming.
-
Connascence (by Meilir Page-Jones ) - A classification of types of relationships between elements that can be used to evaluate design decisions in an OO codebase.
-
Transformation Priority Premise (by Uncle Bob repeating here) - A premise which provides guidance on how to introduce your changes during the coding phase of TDD.
-
Object Calisthenics (by Jeff Bay) - A set of rules intended to lead you to good OO code design.
I don’t pretend to explain every one of those topics here (they all deserve way more than a single post altogether, thanks to the Internet I can share proper links to very good explanations to each :p).
As usual with rules, principles and similars, I take all of those with a pinch of salt, so please don’t use the cheatsheet as “my code must be compliant with all those commandments at the same time all the time”, this would probably lead you to analysis paralysis and/or excellent code, but usually it’s nice to find a trade-off ;).
If you are a newcomer to some of those topics (or all of them), I would suggest you to get yourself introduced to them one at a time in the order I described, diggesting and consolidating before moving to the next one.
Have a nice day,
Xavi
Credits: Thanks David Asensio, Pau Trepat for reviewing and Jorge Garcés for the feedback.