Page:
Coding Conventions
Pages
API SMHI
API TimeEdit
Accessibility Testing
Api documentation
Bat/Ps
Branch Creation
C# Coding Convention
CSS Coding Convention
Coding Conventions
Creating new databases
Dapper
Documentation for service endpoints
Documentation of useTemperature and mock sensor
Energy endpoints
Environment
Evaluation react-grid-layout
Evaluation Localization
Evaluation Password hashing
Evaluation Testing framework
Evaluation of Logging Frameworks
Formatter
Frontend model
Generic Diagram for Sensor data flow
Home
How to- Creating Databases in Docker
Implementing different Styles
Implementing new Mockup sensors
Implementing new Views
Installation script documentation
Installation
Issues
JSON Coding Convention
Jest Testing
Layout endpoints
Linux
Localization
Login endpoints
Mac
Middleware model
Mock API Ceation Guidelines
Mockup models
Model Tools and Standards
Parking endpoints
React/JavaScript Coding Convention
React
Reviews
Room booking endpoints
SQL Coding Convention
Scheduled Database tasks
Scripting Coding Convention
Secrets and .env
Server Access
Server-Deployment
Service/API models
System models
System requirements
Temperature endpoints
Testing API with Bruno
Testing Architecture
Testing frontend for Mobile devices
Testing frontend with Playwright
Testing methodology
Västtrafik API
Webpage Design
Windows
pg_cron and scheduled database jobs
xUnit Testing
No results
9
Coding Conventions
Tim Svensson edited this page 2026-04-26 14:12:27 +00:00
Coding Conventions
Important Considerations
- The intent of code should be clear
- Keep solutions as simple as possible
- Reuse of code is desired
- Minimize use of External Libraries to limit dependencies
Language un-specific code conventions
- All code, comments and documentation is to be written in English
- We use tab to indent code, which is equal to two spaces.
- We use spacing between comparator signs to reduce cluttering.
- We use var instead of strongly typed datatypes.
- A space should always be followed by a comma or semicolon.
- A quick breakdown of what the code does is always written at the top followed by global variables.
- Brackets are opened on the same line as the conditioner, and is ended on a separate line.
- Variables should preferably be short and descriptive.
- Variables should not use abbreviations unless it is already established within the codebase (example, MQTT)
- Methods should have a purpose, or be used to avoid code duplication.
- Comments should have a purpose. Comments should only exist if the code is hard to understand even with proper naming and formatting, or if a function is abstract enough that the name isn't a giveaway for its purpose.
- Comments should also be used when external data is received (and what the data is).
- Bools should use true and false, not 0, 1, null or anything else to indicate its value.
- Checking bool values should be done with appropriate functions/comparisons.
- Arrays are typed as follows: things = [1, 2, 3, 3] (value, comma, space)
- Arrays are also named as plurals, as a collection of things.
- for-loops should use index names as: i, j, k, l, etc.. If the loop ever goes beyond l, please reconsider.
Language specific code conventions
1. Setup
2. Standards
- Coding Conventions
- Issues
- Branch creation
- Reviews
- Implementation Standards
- [WIP] Creating new databases
- Localization
3. Models and Diagrams
4. Testing
5. Documentation
- Documentation for service endpoints
- API documentation
- Webpage Design
- Secrets and .env
- Evaluations
- Installation and Rebuild script documentation
6. Guides and How-to's
7. Micro Service Mockup Api
- Guidelines Mircro Service Mockup
- Documentation of useTemperature/useTemperatureTimeSeries mockup sensor