|
|
---
|
|
---
|
|
|
title: Home
|
|
title: Home
|
|
|
---
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**common** is an ever-evolving project which aims to gather all relevant data for all departments to use. The associated common repository shall be included as a submodule in all projects which require its data.
|
|
**common** is an ever-evolving project which aims to gather all relevant data for all departments to use. The associated common repository shall be included as a submodule in all projects which require its data.
|
|
|
|
|
|
|
|
The main pillar of common is **consistency**: Each step in which data is manipulated is a potential point of failure. For this reason, we try to avoid parsing between different data structures. When implementing something new, it is highly encouraged to follow specific patterns (e.g. store all vectors as colums) to avoid headaches.
|
|
The main pillar of common is **consistency**: Each step in which data is manipulated is a potential point of failure. For this reason, we try to avoid parsing between different data structures. When implementing something new, it is highly encouraged to follow specific patterns (e.g. store all vectors as colums) to avoid headaches.
|
| ... | @@ -16,53 +10,3 @@ Each decision shall be documented, specifying the reasons that led to said desig |
... | @@ -16,53 +10,3 @@ Each decision shall be documented, specifying the reasons that led to said desig |
|
|
Most importantly, **nothing is written in stone**, so if you'd like to contribute with your own discoveries and suggestions, you're more than welcome!
|
|
Most importantly, **nothing is written in stone**, so if you'd like to contribute with your own discoveries and suggestions, you're more than welcome!
|
|
|
|
|
|
|
|
Since many people are working on this project, it is crucial to set a few rules to ensure consistency |
|
Since many people are working on this project, it is crucial to set a few rules to ensure consistency |
|
|
|
|
|
|
|
## Naming conventions
|
|
|
|
|
|
|
|
|
|
> There are only two hard things in Computer Science: cache invalidation and naming things. ~Phil Karlton
|
|
|
|
|
|
|
|
|
|
Naming things is apparently a natural and easy thing, until you realize that everyone must be able to understand what you are talking about.
|
|
|
|
|
|
|
|
|
|
For this reason, there are a few tips to improve the naming of variables in the Common repository
|
|
|
|
|
|
|
|
|
|
#### Shortening variables
|
|
|
|
|
|
|
|
|
|
Unless a variable is repeated hundreds of times, avoid shortening names
|
|
|
|
|
```matlab
|
|
|
|
|
mFusMot = 12.5; % What does that mean???
|
|
|
|
|
motorFuselageMass = 12.5; % Oh ok.
|
|
|
|
|
```
|
|
|
|
|
Having a longer variable name is not a problem, since autocompletion features allow to write extremely fast.
|
|
|
|
|
|
|
|
|
|
#### Case conventions
|
|
|
|
|
|
|
|
|
|
It might seem draconian to impose rules on the case of names, but think about this situation: your colleague tells you to look for the variable 'center length'. You could find that variable written as `centerlength`, `center_length`, `CENTER_LENGTH`, `centerLength`, `CenterLength`, ... does it look a bit confusing?
|
|
|
|
|
|
|
|
|
|
This degree of freedom can be taimed to take advantage on a semantic level. The names of the repository are therefore decided based on a **priority list**:
|
|
|
|
|
1. Matrices and acronyms are usually a few letters in CAPS, e.g: `P` as a matrix, `ABK`, `MEA` as acronyms
|
|
|
|
|
2. All other names follow the **standard naming convention**
|
|
|
|
|
|
|
|
|
|
### Standard naming convention
|
|
|
|
|
|
|
|
|
|
There are three main standard conventions involved in Common
|
|
|
|
|
- `camelCase` for variables and functions
|
|
|
|
|
- `PascalCase` for classes
|
|
|
|
|
- `kebab-case` for branch names
|
|
|
|
|
|
|
|
|
|
**Example:** If you want to create an istance of the Rocket class you would write
|
|
|
|
|
```matlab
|
|
|
|
|
myMission = Mission(true);
|
|
|
|
|
myRocket = Rocket(myMission);
|
|
|
|
|
```
|
|
|
|
|
Note that
|
|
|
|
|
- `myMission` and `myRocket` are variables (istances of classes) and should be named with **camelCase**
|
|
|
|
|
- `Rocket` and `Mission` are classes and are named using **PascalCase**
|
|
|
|
|
|
|
|
|
|
After happily making changes, you can push these same changes on `my-branch`, which is in **kebab-case**
|
|
|
|
|
|
|
|
|
|
> [!NOTE]
|
|
|
|
|
> If a variable name is long 3 characters of less, it is possible to relax the camelCase naming requirements
|
|
|
|
|
|
|
|
|
|
**Example**: The center of mass 'x cg' can be written as `xcg` instead of `xCg`
|
|
|
|
|
|
|
|
|
|
## Useful links |
|
|
|
\ No newline at end of file |
|
|