Cross-post from Trent's Dev Blog.
Always prefer good structure over familiarity.
It worries me when some team members prefer shorter code & familiarity over maintainability & extensibility. To me, these aspects sound quite arbitrary. I think these aspects are more of a QoL(Quality of Life) improvements for the first developer working on the code, than actual better code. Good qualities to have, but not quite necessary. As modern software industry develops, codebases are getting larger and larger, and more people are being involved in a project. Thus, it is more important to write good structured code that team members can easily understand, compared to certain QoL improvements for the first writer.
Also, some people argue that it is faster to program writing badly structured code. I argue that there is no trade-off between program time & code quality - in fact, I think quite the opposite, that it is faster to program even a mildly interesting program using good code structure. Program with good structure may have more LOC compared to a hack job, but LOC doesn't necessarily equate time spent programming. Following a properly-learned good program structure helps a developer arrange program requirements into strict categories, thus helping them to make decisions faster and execute in confident manner. They can program freely, confident that their program will be easily readable & maintainable, and function correctly.
In summary, following a good code structure is to be preferred against shorter code or familiarity. Also, it's a myth that it takes more time to program using a good code structure. We should strive to break out of the mold we are used to, and always improve, to write good structured code that can ease life for others.
Top comments (1)
Good food for thought, but this article really needs a couple of examples.