I'll take clean domain level clear and concise coding even if it under-delivers on the abstractions occasionally. Code will always be read and maintained more often than it is aggressively extended.
I vote to keep it in!
I'll take clean domain level clear and concise coding even if it under-delivers on the abstractions occasionally. Code will always be read and maintained more often than it is aggressively extended.
I vote to keep it in!
I think we tend to agree given that you prefer 'concise coding' which I'll take to mean DRY and 'straightforward' rather than 'clever'.
But by 'picked over', I literally meant 'changed to meet changing requirements' rather than 'read for comprehension'. In that sense, the fact that one guy on the team considers the code he writes to be 'clean' is rather meaningless when many hands might work in that pathway. Composable approaches tend to be more resilient to regressions, well, in my experience anyway, YMMV.
I guess my problem with 'clean code' is that it's too open to interpretation. What do you specifically do that makes your code better than the other guys?
Nothing specific, I'm just saying I value my code well-structured and readable, as well as DRY and straightforward. The proof is in the pudding (my open-source software), of course.