In my previous article, I covered four principles of good code, and I’m going to share four more. (From Lebyte)
01 –
Good code, no sense of violation
Products are like tools that help users achieve certain goals. They are neither decorations nor works of art. They should therefore be designed to be both neutral and constrained, leaving room for self-expression.
Code is abstract, but some code is too abstract.
Using unusual data structures, overly complex libraries, reinventing the wheel, etc., while actually usable, maintainable code is ignored.
Code that is elegant for the sake of elegance, at the expense of correctness, is counterproductive.
This code should be refactored or removed.
02 –
Good code. Time travel
Good design is created to avoid obsolescence, so it never looks outdated. Unlike fashion designs, it can last for years, even in today’s “fast food fashion.”
Software development faces more problems with AD hoc databases, frameworks, and schemas than any other field.
We should choose battle-tested solutions and be conservative in our technology choices.
Good code, can travel through time.
Some of the underlying principles from years ago are still relevant today because they think long term and don’t rely on temporary solutions to cater to the present.
03 –
Good code is environmentally friendly
Good design makes an important contribution to protecting the environment. It saves resources and minimizes physical and visual pollution throughout the life cycle of the product.
The maintenance of the program consumes a lot of server. Sometimes in order to improve the performance of your code, it affects not only the user, but also the environment.
Good code can make effective use of data structures and algorithms to improve their reuse.
Beginning programmers may often copy and paste the same functionality from code base to code base, which is inefficient.
They should be kept in libraries and open source where appropriate.
04 –
Good code is concise
Less, but better. Because it focuses on fundamentals and the product is not burdened by unnecessary factors. Good product design, return to pure, return to simplicity.
This is also my first rule in Lebyte. How can you do the same thing with less code? Here are some suggestions:
Focus on the problem of the moment, don’t think “too big”, and make sure the simplicity of the solution is exhausted
In the long run, clean code is easier to maintain, easier to understand for new developers to take over, and cheaper to test… All in all, there are many benefits.
Overall, code is both literary and a rational endeavor, so it’s often useful to think and discuss code using some of the basic principles of product design.
PS: self-study video Ali P8 strongly recommended 8 Java project combat large collection B station: BV1J64y1R7UN