SOLID is a nice sets of principles. And like principles, there are valid reasons to break them. To use or not to use is a decision best taken after you’ve become a master, when you know the tradeoffs and costs.

Learn the rules first, then learn when to break them.

▲

koakuma-chan 9 hours ago | parent | next [-]

This is idealistic. Do you actually sit down and evaluate whether the code is SOLID or maybe it's more like you're just vibe checking it, and it doesn't actually matter if you call that SOLID or DRY or whatever letters of the alphabet you prefer. Meanwhile your project is just a PostgreSQL proxy.

	▲	skydhash 9 hours ago \| parent [-]
		These are principles, not mathematical equations. It’s like drawing an human face. The general rule is that the eyes are spaced by another eye length viewed from the front. Or the intervals between the chin, the base of the nose, the eyebrows and the hairline are equal. It does not fit every face, and artists do break these rules. But a beginner breaks them for the wrong reasons. So there’s a lot of heuristics in code’s quality. But some time, it’s just plain bad.

▲

mattmanser 8 hours ago | parent | prev [-]

I actually sat down to really learn what SOLID meant a few years ago when I was getting a new contract and it came up in a few job descriptions. Must have some deep wisdom if everyone wants SOLID code, right?

At least two parts of the SOLID acronym are basically anachronisms, nonsense in modern coding (O + L). And I is basically handled for you with DI frameworks. D doesn't mean what most people think it does.

S is the only bit left and it's pretty much open to interpretation.

I don't really see them as anything meaningful, these days it's basically just make your classes have a single responsibility. It's on a level of KISS, but less general.