| ... | ... | @@ -5,6 +5,7 @@ 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.
|
|
|
|
|
|
|
|
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.
|
| ... | ... | @@ -17,7 +18,32 @@ Since many people are working on this project, it is crucial to set a few rules |
|
|
|
|
|
|
|
## Naming conventions
|
|
|
|
|
|
|
|
There are three main conventions involved in Common
|
|
|
|
> 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. Names with fewer than 3 letters are allowed to
|
|
|
|
|
|
|
|
### 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
|
| ... | ... | @@ -33,4 +59,9 @@ Note that |
|
|
|
|
|
|
|
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 |
