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.

๐Ÿ‘‰ 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:

  1. User Stories (US) ๐Ÿ›ฃ๏ธ: describe each functionality in a few words.
  2. Use case diagram ๐Ÿชด: create a Use case diagram from US
  3. Basic class diagram โœ๏ธ: identify the first classes and methods and add them to a Class diagram
  4. 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.).
  5. 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.

Static Code Analysis

Static Type Checker

  • Flow for JavaScript