Coding Practices
When developing software, there are well-known guidelines, patterns, methodologies and tools that can help boost developers. ๐ฅ
One of the life-saving methodologies, when you have a bug, is the Rubber duck debugging method. While you explain the problem to a rubber duck, you might be enlightened and find the solution. ๐ฆ
Coding Helpers
Websites
A few notables:
- StackOverflow ๐น: most of the time, another developer had a similar question or problem as us and asked about it here.
Artificial Intelligences
A few notables:
- ChatGPT ๐: a chatbot that is somewhat like a smarter search engine though it often provides incorrect (or outdated) results
- tabnine: TabNine AI coding assistant
- Microsoft Copilot โ: Microsoft AI coding assistant
- FauxPilot โ๏ธ: an open-source AI assistant
- codeproject: ๐ป
- codegrepper: ๐ป
Coding Principles
Donโt repeat yourself (DRY) ๐ฐ
Write your code once. Don't copy and paste. Write functions. It reduces the number of locations to patch when a bug is found.
Also, avoid reusing hard-coded constants, such as "Hello, World"
, and store them in a constant, for the same reason.
โก๏ธ Apply Code Reuse as much as possible.
You ain't gonna need it (YAGNI) ๐ฎ
Don't write code for something unless you need it right now. Stop writing code that will supposedly be used 'later'.
Separation of concerns (SOC) ๐ช
Split each element so that they only handle one thing.
Curly's Law โ๏ธ
Each function variable or any element of your code should only do and mean one thing at a time.
Murphy's law โจ
"Anything that can go wrong will go wrong." For instance, always check that the preconditions of a function are correct, do not expect that they will always be as expected. Test your code.
Keep it simple, stupid (KISS) ๐
Simple code is easier to debug and maintain. Don't make things complicated, write simple code that works.
Code For The Maintainer ๐
Put yourself in the shoes of the maintainer when writing code to ensure that the code is genuinely maintainable.
Don't reinvent the wheel ๐
Before creating something from scratch, try to find if there is a maintained stable solution that could start from. It reduces the code to maintain and the time it takes to get a working program.
Do The Simplest Thing That Could Possibly Work โ
Write as little code as possible to get a working program. Think about the easiest solution to a problem and code it. You will then improve your code when you need it.
SOLID
SOLID is a popular acronym in object-oriented projects:
- Single ๐: Each class should have one responsibility
- Open/Closed ๐ฅจ: "Open for extension, closed for modification". Use inheritance etc. to modify the behavior of a class.
- Liskov substitution ๐ป: if B inherits from A, then we must ensure code working with A works with B.
- Interfaces segregation ๐ช: keep your interfaces relevant to the one that uses it (don't force them to implement unneeded stuff)
- Dependencies inversion โณ: ensure high-level classes do not depend on low-level ones using interfaces, abstract classes etc.
Code Formatting ๐งผ
It's common for developers to have different preferred formatting habits when writing code. A few examples with a simple "if" ๐ฑ:
if (condition) // no braces
if (condition) {} // dirty one-line
if ( condition ) {} // inner spacing
if ( condition == true ) {} // explicit
if ( true == condition ) {} // "fix" = instead of ==
if (condition) // common syntax - new line
{
}
if (condition) { // common syntax - same line
}
To avoid making the code hard to read and maintain, developers often define formatting rules. There are a lot of linters ๐ซง, at least one per programming language, that can detect and automatically clean up the code according to the formatting rules defined.
- ESLint or js-beautify for JavaScript
- pylint for Python
- markdownlint for Markdown
- ShellCheck for Shell Scripts
- ClangFormat for C/C++
- prettier for HTML, CSS, JavaScript, Markdown...
- ...
๐ Common elements: tabulation, spacing, variable names, lines width, position of symbols/elements in the code, symbols to use, etc.
Pair-programming
Pair-programming ๐ชท or Mob programming (when more than two) ๐ช is one of the most well-known coding practices.
Multiple persons are working together on the same computer. One writes code, while the others:
- Provide help ๐ป
- Give advice and suggestions ๐ซ
- Ask questions when your code is unclear ๐ค
- Think about potential problems in the code ๐ฅ
- ...
Make sure to take turns if you are often doing it.
There are many extensions to popular IDEs or text editors allowing us to do pair-programming on two computers remotely. It's useful as two persons can write the code instead of one.
"Two heads are better than one"
Programming Paradigms
Model-Driven Development ๐ช
The Model-Driven Development (MDD) means that the code must, at any time, be the mirror of the model that we designed.
The model is commonly designed using UML. It refers to all diagrams associated with the project (class diagrams, activity diagrams etc.).
The procedure to make a good model:
- User Stories (US) ๐ฃ๏ธ: describe each functionality in a few words.
- Use case diagram ๐ชด: create a Use case diagram from US
- Basic class diagram โ๏ธ: identify the first classes and methods and add them to a Class diagram
- Sequence Diagram ๐โโ๏ธ: for each use case, create a sequence diagram. You must use actors, classes, and methods from other diagrams. Complete your diagrams each time you something is missing (method, method arguments etc.).
- Implementation ๐ฆ: generate the code from the model and improve your model as you work on the implementation.
โก๏ธ It may be helpful to create a mock-up of the application first to better identify user stories.
Data-Driven Programming ๐๏ธ
Data-driven programming is a paradigm where the behavior of the program is driven by the data we provide.
For instance, in a game, we could define quests directly inside the code or we could create JSON/XML/... for each quest and load them inside the program (which is a Data-Driven approach).
It allows us to change the data or add new files without editing the code. It's both easier to use and to maintain. Editing data files may not require any programming knowledge, and they can be processed by other tools (ex: we could develop a graphical editor).
Documentation-Driven Development ๐
Literate programming is a coding practice in which we write documentation before and alongside the code to explain its purpose.
It's sometimes called "Documentation-Driven Development" to enforce the idea that we must write documentation before the code, and that it drives what we code.
๐ป To-do ๐ป
Stuff that I found, but never read/used yet.