[12thwonder]

I like this.

It is very hard to find out if the definition already exists or not in the codebase. This can lead to multiple definitions of the same thing or the truth.

anyone has a good way to deal with this?

[Jabihjo]

Unfortunately the issue of lacking a single point of truth is exacerbated the more people who work on a project. I believe the issue in spreading around logic comes from not knowing the original intention, and asking the original authors is, IMO, the best way to fix something or add new features. Obviously knowing the original authors is not always possible, so I try to follow existing patterns.

[layer8]

If the codebase isn’t a total mess, one should be able to guess which components or code paths have to deal with a given truth by virtue of their purpose/function. Then one can investigate the code paths in question to find out where exactly the existing code is dealing with the respective thing.

It should be an automatic thought when implementing some logic to think about which other parts of the system need to be consistent with that logic, and then try to couple them in a way that will prevent them from inadvertently diverging and becoming inconsistent in the future.

In terms of software design, a more general way to think about this is that stuff that (necessarily) changes together (is strongly coupled) should be placed together (have high cohesion).

[criddell]

Some IDEs will warn you about similar blocks of code.

[waynesonfire]

It's interesting to note that this principal doesn't just need to apply at a low level, e.g. code. It continues to add value when designing application architecture. Or, can be used to help refine features.