I'm really curious on different viewpoints for what you consider "Clean Code". Not clever code, but code that you can decently maintain, extend and understand.<p>(I'm not referring to the concepts that Robert C.Martin/Uncle Bob is preaching - although a significant category of people will consider that to be clean code - but rather in general - couldn't find a better naming)
- there's unit tests<p>- there's integration tests<p>- you can run the code locally and it works<p>- you can send data you control to the system<p>- you can check what the system responds with<p>- you can do all of the above in debug mode and breakpoints actually work<p>- the external dependencies are optional or you can control them too on dev environment without too much hassle<p>If I have all of that - maintenance will be easy, SOLID or no SOLID, functional or OOP or whatever.
My only requirements for "clean code" are the following:<p>- readable (use self-describing functions, names, etc; consistent spacing...)<p>- as little repetition as possible<p>- as efficient (or "clever") as can be, while not sacrificing the first two bullets<p>-- caveat to the last bullet: using "extra-clever" techniques is acceptable <i>IFF</i>, you <i>very</i> clearly document (in comments, code commits, etc) not only <i>what</i> the code is doing, but <i>why</i> you're doing it that way
In a functional sense, clean code is something you can return to in 6+ months and quickly understand the flow. Ideally, it's code that <i>somebody else</i> can look at and quickly understand the flow. Lack of cruft, clear naming conventions, yeah, but the logic has to be obvious, too.