The 5 CUPID properties for joyful coding

Programmers are always looking for better methods to create better source code. Many principles for software design and development such as SOLID, GRASP, DRY… have appeared.

In the 2000s, when Object-oriented programming was popular, we all learned about SOLID. A quick recap of SOLID principles:

• The Single-responsibility principle: Every class should have only one reason to change.
• The Open–Closed principle: Classes should be open for extension, but closed for modification.
• The Liskov substitution principle: Subclasses should be substitutable for their base classes.
• The Interface segregation principle: Many small, specific interfaces are better than one large interface.
• The Dependency inversion principle: Depend upon abstract classes instead of concrete classes.

By describing the rules in the design and development of software processes, SOLID helps source code become clearer and more understandable. Moreover, the next development phase can be more flexible and less complex.

But today, applying those principles in software development might be a bit rigid as programmers apply the rule just because it is... the rule. Therefore, in the early of 2022, CUPID, a new approach was introduced to the community. Instead of telling us what to do, Daniel Terhorst-North, the author of CUPID suggests 5 properties that a software should have.

1. Composable - "plays well with others": classes and functions should have a small surface area, work with each other easily, and have minimal dependencies.

Unix commands can be combined using the Pipe.

2. Unix philosophy - "does one thing well": components should only do one thing, and do that thing well.

In Unix OS, the ls command only lists information about files and folders, but ls itself does not know this information. Instead, this information is provided by the stat command, and the ls command just displays it in the form of a list.

3. Predictable - "does what you expect": software should behave as expected, with no surprises (if A is what a component looks like to do, A should be what the component actually does), be deterministic, and observable.

findIndex() method normalizes input before processing to make sure the result is always "expectable" (from Excalidraw)

4. Idiomatic - "feels natural": Shape the standard coding style that helps others have an easy approach to source code (if the language does not have a standard style, try to learn from the ecosystem, community, or preferred styles).

"python –m this" shows 19 "guiding principles"

5. Domain-based – "in language and structure": Using domain language in developing and structuring source code to make it clearer and more comprehensible (even non-tech people can understand the source code!)

Excalidraw defines elements and properties using sketching domain language

To make software have these properties, programmers can choose their own suitable methods. CUPID does not give out concrete actions for source code, it tells us which characteristics the final product should have. We may find it confusing when we compare CUPID to other principles as it seems to be unclear. However, it will help us be more receptive and take suitable actions.

As its first introduction in the early of 2022, CUPID is more up-to-date for different systems. Applying CUPID not only makes the source code friendly and accessible, but also gets upgrade and update easier and faster. The CUPID properties help programmers who access the source code later reduce stress, and maybe that person can also be you, who knows?!

Choose the method that suits you best. Because in the end, it's our goal as programmers to make great code.

Read more about CUPID.