We agree that our industry constantly changes the rules, new languages and platforms, evolving the languages' syntax.The developers and the consumers of their products-users aren't changing. I think you have seen a lot of books where the ideal code theme is parsed internally — from the web and software development point of view. But I think it's enough to explain what an ideal code is.
Custom software developers should understand why it is important to write the ideal code. Therefore, in order to give more complete and reasoned response, I suggest you to "dig a little deeper and remember that writing code is only part of the process that is called "software development". Let's look at product development from the side of all involved participants.
The main idea — an ideal code is the part of a perfect product. Or, an ideal code helps to produce a perfect product. What distinguishes the ideal product? The quality. Here, the quality means at first to understand the stability of a product, the number of the mistakes and their criticality, as well as the product efficiency (consumption of resources and speed).
The main tasks that the perfect product does in the course of working on the project:
1) Code Reading;
2) Modification of the code;
3) Start and debugging.
If he will fast perform all these tasks, if there will be few downsides, the faster he will be able to release the next version of a product, the more dynamic his career will develop.
Thus, to summarize all the indicators shown in this Chapter, to the project (and to the code as well) should be given the following requirements:
1) Easy to read and disassemble;
2) Easy to change (correct);
3) Start (and restart) quickly on different operating systems;
4) Can be reused and test;
5) Use the free platform and libraries;
6) The minimum number of mistakes (or absence of them);
7) The Minimum resource consumption;
8) The Stability change of the configuration/environment;
If we analyze this list of requirements, then we can conclude that our ideal code should be:
What is more important? Is it easier to achieve? What can be ignored?
Why did we start with readability? Developers spend most of the time (sometimes 90%) reading of the code. The development is a team work, mostly they are viewing someone else's code. Almost every developer has to say about your code that it's readable or not, just by looking at him. Readable code is code that will be equally easy to understand, no matter how much this code you will be looking at.
Complicated methods should be short and simple -could be long; avoid nested loops and forced exit from the loop where it's possible; avoid nested try/catch and anonymous classes; Try to write each expression on a separate line; avoid excessive number of methods that are called in the chain one by one; Use the Java Convention. In fact, readability is based on the amount of information that needs to be kept in the developer mind to understand any line of your code.
If the code is small it's easier to read it and the fewer mistakes you can do. But where is the line beyond where compactness goes to the unreadable and affects the flexibility? Compact code is code that cannot be reduced in volume without hurting other characteristics.
3 major violations of compactness of code:
1) Minor cases;
2) Duplication of code or a violation of OOP principles;
3) The Use of language constructs or API in a context that is not designed for this.
The self-explained code is a code with the comments for those who like clarity and code with constants, for those who do not like to waste time. You can make our own choice. But the clearer code is so the easier it is to work with him in the team.
If the main thing for developers — to do the project and forget about it so it doesn't worth to bother with the code. But if the matters is in the quality and confidence in the project, the principles of the ideal code is for you.