Jump to content

Computer Programming/Standards and Best Practices

From Wikibooks, open books for an open world

What are "Best Practices"

[edit | edit source]

Standards 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

[edit | edit source]

The 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

[edit | edit source]
Wikicode 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 | edit source]
  • 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

[edit | edit source]

The following are practices that some developers think are best practices, while others think that they are bad practices.

Further reading

[edit | edit source]