3 ms·
Na this is just semantics. There is clearly ugly code and clean code.. And generally speaking, ugly code is structured in a non obvious manner that can range f
by edwnj 5y ago
Na this is just semantics.
There is clearly ugly code and clean code.. And generally speaking, ugly code is structured in a non obvious manner that can range from the specific implementation to naming..
Its a spectrum and after a certain point what is ugly/clean is very subjective but this is where semantics kicks in. Other than the occasional heated arguments, most teams can agree on what is ugly vs what is acceptable/subjective.
- skohan 5y agoDisagree. I feel like I have seen this play out a number of times in my career: - New engineer joins a team with a mature codebase - New engineer complains about code quality, convinces management on a total rewrite to improve code quality - New codebase starts out simple and elegant - Eventually the codebase gets just as bulky and convoluted as the old one, because the ugliness was just a reflection of the complexity of the problem space A lot of times "ugly" is just a stand-in for "not written by me"
- edwnj 5y agoI think your mistaking technical debt for code quality. I've seen the same thing play out and more often than not, its a helix like cycle of projects starting simple and as time goes on trade offs are made and you get a lot technical debt then you rewrite and the cycle begins again. I partly agree with you about "ugly=not written by me", I just think that only happens at the edges aka semantics.. Nowadays its pretty easy for teams to come to a consensus on whats clean/ugly vs acceptable/subjective.
- skohan 5y agoI partially agree that there is a cyclical aspect to code rewrites and cruft accumulation. I still think a lot of time the perception that code is poorly written gets applied to complexity which is not yet understood rather than objectively poorly written code.