Computer Programming/Standards and Best Practices
What are "Best Practices"
editStandards in computer programming are methods of programming that have been declared acceptable and thereafter are recommended as the approach that should be used. Much like what GAAP is to Accounting, programming standards allow programmers to use a common ground when writing code. Closely tied with programming standards, best practices are simply recommended methods of writing code.
Goal of this section
editThe goal of this section is to give beginners a checklist that allows them to write decent code and to tell beginners that those things exist, so that they can do further reading on these things and figure out if they want to use it or not.
Language-specific best practices
editWikicode | Standards | Best Practices | Template |
---|---|---|---|
C | Page Here | No Page | No Page |
C++ | Page Here | Page Here | No Page |
C# | No Page | No Page | No Page |
Java | No Page | Page Here | No Page |
Perl | No Page | No Page | No Page |
Python | No Page | PEP 8 | No Page |
Makefile | No Page | No Page | No Page |
Apache Ant | No Page | Page Here | No Page |
JavaScript | No Page | Page Here | No Page |
Visual Basic | Page Here | No Page | No Page |
Language-independent best practices
edit- Use a version control system.[1][2][3]. Most common: git
- Create a License.txt file
- Use a proper build system like Meson, CMake, Makefile, Apache Ant, Gradle, Buildr...
- Use a code-formatter. Consider configuring your editor to run the formatter everytime you save the file.
- Use a documentation generator
- Enable compiler warnings.
- Fix all compiler warnings.
- If there are good linters available for your language, run them and fix all warnings.
- Have an appropriate amount of unit test.
- Use a 404 link checker to make sure you do not have any 404 links in your documentation.
- If you are working with memory-unsafe languages - Run your tests with ubsan.
- If a part of your code can be fuzzed, fuzz it.
It is important, that you don't just run the unit tests, fuzzers, linters, code-formatters and 404 link checkers once, instead you should run them everytime you change something. The purpose of of unit tests isn't to check whether it works, it is to make sure it keeps working when you change something. Maybe add those things to your pre-commit hooks. Most projects have their servers configured to run those tools everytime someone creates a pull requests.
Disputed Language-independent best practices
editThe following are practices that some developers think are best practices, while others think that they are bad practices.
Further reading
edit- ↑ Troy Hunt. "The 10 commandments of good source control management".
- ↑ Joel Spolsky. "The Joel Test: 12 Steps to Better Code".
- ↑ "Version Management".
This page or section is an undeveloped draft or outline. You can help to develop the work, or you can ask for assistance in the project room. |