How to write code that will not lose relevance in 10 years. and is it truly necessary?

Technical base

In general, if the code functions normally, it does not need to be altered, even if it has been 10 or 100 years. However, there is another issue that cannot be changed: the product's moral obsolescence, as well as the versions of the programming languages in which it is created. The code built ten years ago may still be functional and scalable, but it is becoming increasingly difficult for it to adapt to current difficulties, therefore certain parts are added or updated. The exception may be a core structure that hasn't changed much over time, such as HTML.

Even today, an HTML framework designed in the late 1990s will operate and scale effectively. However, there is another issue here: the frame was designed for block design and layout, which was popular towards the end of the 1990s. Yes, there were already fundamental notions about online page design at the time, but incorporating contemporary page design into the HTML framework developed at the time was not always straightforward. It's sometimes easier to tweak it or create an entirely new foundation.

How to write code that will not lose relevance in 10 years

No way. It will still have to be changed and scaled during this period, so when applying for a job, the candidate code is evaluated in terms of ease of interaction with it, opportunities for scaling, updating versions. Since it will be inexpensive to maintain, such a code is able to remain relevant for a long time, perhaps even 10-15 years.

Next, consider the points that directly affect the ability to maintain the relevance of the code over a long period of time.

Code readability

The first and most important point is the ease of reading your code. It will be read much more often than written or corrected. Naturally, the writing style should not be difficult to read for a person familiar with the syntax and basics of the programming language used in the work. Also, do not forget that, most likely, you will not work alone, but in the company of developers, so it is important to make sure that they do not have any difficulties in reading. So there will be less chance that they accidentally “break” something, and colleagues with superiors will treat you better.

Clear and readable code is easier to diagnose, find errors, test, edit. An unreadable structure is more difficult to maintain, even if everything is implemented correctly from a technical point of view. So, to make the code easy to read, follow these recommendations:

• Use spaces and tabs correctly. In some programming languages, for example, in Python, this affects the quality of script processing. But even if spaces and tabs are not required in the language you use, they must be observed to structure pieces of code so that it is easier for other people to read them. This especially helps with a cursory view, when everything is “broken down”, and does not merge into one heap of symbols.

• Don't overuse abbreviations. Some commands can be written using abbreviations. Here you need to be careful, since a very large number of abbreviations complicates perception, and sometimes can lead to errors. True, in some programming languages, for example, JavaScript, it is customary to use libraries with abbreviations (for the same JS, this is JQuery). In this case, it is better to use only abbreviations instead. In other cases, use abbreviations wisely so that they don't make it difficult for an outsider to read the code.
• Separate code blocks from each other. Usually an empty string is used for this. In some cases, a hierarchical separation system is used, for example, separating code blocks within a parent block with one line, separating parent blocks with two blank lines.
• Write clear comments. It is desirable to comment on each block and main functions. In the comments, you need to briefly indicate what they are responsible for. True, there is no need to go to extremes and comment on everything and / or give too detailed a comment - a couple of words will be enough.
• Give proper variable names. From the name of the variable, it should be approximately clear what it is responsible for.

Paperwork

Each programming language has its own documentation according to the versions. A similar rule applies to libraries, development tools, frameworks, and so on. Of course, this does not mean that you need to write detailed documentation for any of your projects. It will be enough to indicate which technologies, programming languages, third-party libraries were used in the process of creating the application. True, do not forget to indicate the version that was used at the time of writing. Another developer, having this data, will easily find documentation on the tools used and will be able to quickly make the necessary changes.

The development team with which you made the first version of the project may have its own rules for coding. Usually they concern the name of variables, the use of abbreviations, indentation, general style. In this case, in order to be able to further support the finished code, on behalf of the team it is required to compile documentation with a detailed list of rules. Such documentation, for example, is available from the developers of Yandex.

Some IDEs have the ability to set style settings for different standards, including custom ones. Predefined styles can be uploaded to a separate file, which can be used by other developers to apply them automatically.

General rules for coding

Their use affects not only readability, but also the ease of scaling or making other changes in the future. This allows you to keep the code up to date for a long time.

Avoid ambiguous names

Don't give names to variables that might cause confusion. For example, an object enumerates a list, but the object itself belongs to a different class. In this case, it is better not to use “list” or other similar words in the name of the object, as they can cause confusion. It would be wiser to use this word in the name of just the list, and not the object in which it is located.

You should also beware of subtle differences in the names of objects and other important constructs. It is bad to use repeated elements in long names. The name of each construction must be unique and at the same time understandable, preferably without the possibility of discrepancies.

The name is conveniently searched by automatic search

To do this, it must be longer than 3 characters. The fact is that the search will no longer recognize shorter names as a separate word and will show any match, including inside other words. This will greatly complicate the search for the desired element in a large amount of code. Naturally, it is categorically impossible to give a name from one letter and / or number. Such items are even more difficult to find through automatic search.

Choose the correct part of speech

For classes and objects, it is recommended to use nouns or a combination of several nouns. Example: Sidebar, CSSParser, AccountPage. Methods and functions are best written as verbs or their derivative forms: replace, delete_folder.

Rules for working with functions

Functions and methods are responsible for the performance of the code. They should be easy to read, edit and maintain. In order for them to meet this requirement, the developer community has several rules for decorating functions in code. They are relevant regardless of the programming language used.

Function compactness

It shouldn't take up much space. Even a complex function can be simplified. They will be easier to read and understand the purpose, as well as the logic of work. Back in the 80s, an unspoken standard for the size of functions was adopted among developers - it had to fit on one screen. The computer screen of that time contained approximately 20-30 lines. Of course, this does not mean that you need to fit into these values, but it is desirable to make sure that the function is no more than 50 lines.

Minimizing blocks with conditions

This applies primarily to if, else, while. Their size should be minimized so that it is convenient to keep the information from these blocks in mind. If possible, try to write conditions on one line. Most programming languages ​​allow this. One line entry should be discarded when it becomes too long. In this case, it would be reasonable to break the line into several by meaning.

One function - one operation

It is better to describe the performance of any operation into several interrelated functions, rather than trying to shove them into one. Such code will be much easier to maintain in the future. So to maintain performance, you need to make changes to one specific function with minimal risk of globally disrupting the entire code.

Argument restriction

A large number of arguments to the function complicates the work with it, therefore, further support too. The need for functions with more than two arguments must be supported by very strong arguments. Adding new arguments makes the testing procedure more difficult, plus it increases the risk of problems when making changes to the code.

Conclusion

In most cases, there is no need to write code that will be relevant in 10-15 years. Moreover, it is often harmful. Code that needs to stay up-to-date over a long period of time needs to be easily scalable and changeable so that it can be quickly adjusted to changing realities. To do this, it is important to follow the accepted standards of writing, to correctly divide tasks between functions.