Code Tips

Question

Sometimes I really wonder if my code is "durable." I do my best to make it "last" and avoid dependence on things when writing or solving problems. Things like “software tricks” and assumptions that may change in the future if I rewrote or add code. Sometimes it’s easy, in other cases it’s difficult, but all of this is part of the programmer and does the job better, faster and easier.

Having said that, can you recommend some tips from your personal experience for writing the best durable code in HLL? What should i avoid that covers?

Thanks!

Answer 1

Avoid everything you've read and thought about recently

Well, this is an interesting feature of the language, design pattern, etc., I think it can help me reduce my code complexity.

For some reason, it always causes me to bite later. It’s better to have this in side projects and then use it in production code as soon as it turns out to be a good idea, and just looks like one.

Answer 2

Bit rot ...

The problems that I most often encounter when compiling an old project,

• Missing dependencies. It is recommended that you specify any libraries you depend on, including the URL from which you received it. Your inclusion path may not be the same as it was 5 years ago!
• Compiler changes. Usually this is not very worrying and can often be fixed by C # define in C / C ++
• Resizing data - this was unpleasant when switching from 16-bit to 32-bit. Try not to make assumptions about the size of the variables.
• Mysterious assembly process. For some projects, there may be hidden build steps to create resources, libraries, etc. Make sure they are well documented.
• Too smart code - I saw code suggesting that the computer has less than X megabytes of memory, and therefore uses the upper bits of pointers to store data. Do not do that!
• Error checking. When something breaks, a good error check will help you understand why it is much faster.

Answer 3

Sometimes the key to creating code is not trying to build some kind of masterpiece of eternal longevity ahead, but just getting up and doing something that is really useful. It may even be permissible to make certain assumptions ahead if they are all clearly documented, perhaps through comments, statements or unit tests. This reminds me: write a lot of unit tests, so that as the code evolves over time, you’ll constantly check assumptions about how it should behave.

Do not assume that everything you write will remain unchanged for centuries. Count continuous refactoring and focus on making it as easy as possible.

Answer 4

I found the following helpful tips:

• Use meaningful variable / member / class / function names, even if your fingers have been hit by input.

• Comment on each class and function, procedure (if it is not a template, for example, set / get methods) exactly, briefly. If this is not possible or easy, then your / sub function is probably too complex.

• Keep functions / procedures small - 5-10 lines. This helps them easily verify, test, debug, document and use.

• When you look at your code (usually during bug fixing or further development), and something strikes you, document the problem or fix it. Often you will find a mistake later, and it will be related, or you will use the code in a way that violates some of these assumptions, and the documentation will help you.

• Keep a working log of the changes you make during the day. When saving to the repository, you can cut and paste part of the log from the last save to the current location, so your changes to the code repository are well documented. Save the magazines separately (repository, email, blog).

• Compose the code in independent, reusable components. There is a thin line between the add-in, KISS and the generalization, so you need to weigh the pro and the console. The advantage of creating reusable components is that you tend to build the component better to make a few assumptions, have clean interfaces, have several dependencies - all this is done by the best code. In addition, reusable components are used in more places, so the code is better tested.

• Throw exceptions or use statements wherever your code may fail, depending on how it is called, that is, the parameters passed, or depending on any external factors to the function / procedure. "Never happens" exists only in theory - exceptions make narrowing errors much easier.

• Keep a list of running todo / list of errors for things that need to be done or improvements as part of your log. Most likely, this list will never be completed, because as soon as you can finish the items in the list, new ones will be added. At some point, the list will consist of low priority or pending items, and you will move on to production or to a new version. How many years was written by the MS-word and now it is completed?

Answer 5

For me, this is very similar to sending emails or correspondence.

After the code is “done”, I will read it and look through all the scripts in my mind.

After that, the tests will pass.

The best developers I've seen can read the code and get all the basic stuff. And then you get even more problems knocked out with unit testing.

Also comments. I think in assembly programming they talk about "write once, never read." If you do not comment on the assembly code, it cannot be supported. HLLs require helpful comments.

Answer 6

In my opinion, there is nothing wrong with letting the program evolve. Previously, I always wanted to anticipate all the possible changes, but I found out that most of the time this is not possible. However, abstractions survive longer than implementation details. So my advice is to split your application as much as possible into many components (classes and functions) with interfaces that are abstract (hiding implementation details) as much as possible. Thus, when something needs to change, which will inevitably happen, the changes are likely to be isolated in a small part of the source code.

Answer 7

I am trying to remember the following:

• The code is likely to live much longer than anyone would expect, or much shorter than anyone would expect (I left the project once and they completely rewrote my application in another language, however the new developer was happy. I left a lot of comments!)
• If you ever return to your code, you will find that it is terrible. It's always like this. Comment before you forget how it works.
• Understand that someone else will look at your code, decide that this is crap, because you did not follow OOP well enough and reorganized everything on you. Then, later, the person who reorganized the thing will come and ask for help because it does not work, and you will find that the person who rewrote for the sake of SOLID principles completely removed from the application all the functions that were the whole reason why you violated RESPONSIBLE principles in the first place (sorry, this is rant ...).

In any case, I would add a lot of comments . Comments will fix all of the above problems and make the code longer. I would recommend the fallacy on the verbose side.

Answer 8

Take a look at SOLID principles. For example Getting SOLID start .