WITH’s Coding Guidelines

Introduction

As you are part of WITH, you are not an individual developer but rather you take your place in a team that works together in numerous ways. Because no one is perfect, no project is ever finished and no requirement is set in stone, we ought to work in a way that acknowledges the reality of our mission. The present document explores the techniques to get as close as possible to this goal.

Warning

This document will hurt your feelings. But the main rule is: no exceptions. If you think that 2 spaces is inherently better than using 4 spaces, you can do it whichever way you want on your personal projects but here you must think of what happens when you’re sick and that someone must jump into your project at the last minute without any prepartion. Your job is complicated as it is, let’s focus your brain power on writing code and not on personal style.

Note

That said, this document is hosted in Git. If you feel like the rules should change don’t hesitate to talk about it and to submit a pull request!

Mandatory content

This content contains the explicit rules of what needs to be done within the WITH team and must be read and known by all.

• Code Formatting
  • Languages
  • .editorconfig
  • Case styles
  • Dealing with poorly formatted files
• Documentation
  • What needs to be documented
  • When to write documentation?
• Version Control
  • Workflow
  • Commits
  • What can be commited or not
  • GitLab structure
• Build Lifecycle
  • Important stages
  • 12 factors
• Monthly Maintenance
  • Bugs
  • Updates
  • Performance
  • Documentation
• Functional thinking
  • Functions
  • Functional vs Imperative
  • A simple demo
  • General approach
• Dependencies Management
  • External dependencies
  • Internal dependencies
  • Forbidden patterns
• Approved stacks
  • Approved tools
  • Recommended stacks
  • Approbation procedure
  • Deprecated libs
• Testing
  • Base concepts
  • Methods of testing
• Optimization
  • Core Web Vitals
  • Front-end best practices
  • Back-end best practices
• BigQuery Exports
• On The Proper Use Of Eval

Bonus material

This track of pages contains articles that are interesting for your reading and probably worthy of your consideration, but not required as part of the onboarding process.

• Common Pitfalls
  • Not using the lib’s GET query encoding
  • Filtering empty values
  • String concatenation
• NASA’s power of 10
  • 1. Avoid complex flow constructs, such as goto and recursion.
  • 2. All loops must have fixed bounds. This prevents runaway code.
  • 3. Avoid heap memory allocation.
  • 4. Restrict functions to a single printed page.
  • 5. Use a minimum of two runtime assertions per function.
  • 6. Restrict the scope of data to the smallest possible.
  • 7. Check the return value of all non-void functions, or cast to void to indicate the return value is useless.
  • 8. Use the preprocessor sparingly.
  • 9. Limit pointer use to a single dereference, and do not use function pointers.
  • 10. Compile with all possible warnings active; all warnings should then be addressed before release of the software.
  • Key takeaways
• Bugs
  • The obvious
  • The blind
  • The meta
  • Conclusion
• The Async Debounce pattern
  • Expected flow
  • Code example
  • Conclusion
• Exceptions handling
  • How it works
  • Reasons for exceptions
  • Dealing with exceptions
  • Emitting exceptions