Insights in programming

1. Learning should start from the basics, don't try the most advanced techniques at the beginning.

2. Every time I read a book, don't say that I have studied this chapter before, and I have mastered it well, so I can skip this chapter and read more important ones.

3. For homework, try not to immediately ask others for help if you can't.If you really can't solve the problem, you can complete your skills first, and then extract some special difficulties and ask experts for advice.Don't expect books and experts to solve every problem for you, because not every problem can be taught to you by someone else.

4. If you ask someone a question, you should explain it clearly.The error message should be provided as it is, not according to the information you understand.Because since you can't do it yourself, it means that you generally have problems with understanding.

5. Ask questions with codes.

6. Don't say "compilation passed, but runtime...", because compilation errors and runtime errors may not be related at all.Generally speaking, compilation is a syntax issue, while execution is a logic issue.

7. It's better to read a book a thousand times than to write a program once. You should try to write a program as much as possible.

8. It is better to do a thousand programs than to do one program.You should try to improve the program you are doing now, instead of constantly opening new programs, each of which is anticlimactic.

9. Remember that you are not writing programs by yourself, but with others.

10. Although advanced skills show advanced skills, they are often harmful to cooperation. You should try to write simple and easy-to-read code.

11. The programming should be self-commented as much as possible, that is, the code itself can be understood as soon as it is read, as if it is explaining its own logic.

12. If complex codes cannot be self-commented, appropriate comments should be given.

13. Comments should be modified accordingly when modifying the code, and old comments cannot be used to mislead others.

14. The code should be reusable as much as possible, the code with the same function should be completed by the same function, and the important functions should be given debugging information, so that problems can be found early during debugging.

15. You should try to write small functions, each function should not exceed 40 lines or less.This way you may be able to read the entire function without scrolling the screen.

16. For the switch statement, try not to have too many branches. If there are too many branches, you can consider using a jump table.

17. Minimize the use of some controversial statements, such as goto and ternary operators. Since there are disputes, it must have certain disadvantages.

18. For goto, many engineers are skilled enough to use them reasonably without causing problems.But your program is not necessarily for your peers to read and modify, and they can't guarantee reasonable reading and modification of these related codes.

19. There should be a certain format when writing the code, and the basic requirement is that it is helpful to understand the code.

20. If the data is shared by multiple modules, an encapsulated class should be provided to manage it, and an appropriate interface should be provided to each module.In this way, if the data content is significantly modified, as long as the interface remains unchanged, it is basically guaranteed that the program will not be modified very complicatedly.

21. Data concurrency control should be considered as much as possible.

22. The concurrency control of data should be encapsulated in the interface instead of being exposed to other modules, which can reduce program deadlock caused by concurrency.

23. The structure of the data itself should not be too complicated.You should try to split irrelevant data into two sets of data.

24. For a large amount of data, the database should be considered.

25. The database interface should use the standard ODBC or ADO interface, try not to deal with the interface provided by the actual database DBMS, because you may replace the DBMS in actual use.

26. Small data can be considered files, and the file path should be designed as a relative path.

27. In a function, try to open the file and close it immediately after use, so that other programs may use the file.

28. Don't try to read all the files into memory, you should process large files in batches.

29. The writing program should provide relevant test programs to provide testing means.

30. You should consider the usage of codes and functions, and do not use them beyond the scope of functions.