Developer Guidelines¶
This document is intended to be a long-term reference for defining and tracking changes and evolutions in FLoRaSat Ultimate Version. Details are welcome to make this document useful in the long term.
General Guidelines¶
- Do not break existing functionalities
- Think of how people will use the functionalities that have been implemented
- A little paragraph at the beginning of each file is welcomed (module description)
- Don't hesitate to point out missing functionalities, as time is not always on our side
- We are not professionals, but we can try to do our best to code well at least
- Add your name next to a bullet point if you are working on it. Tick the point when it's done
Coding Guidelines¶
- Avoid imbrication of conditions, prefer the use of events and self-messaging. Come on, it's an event-driven simulator
- The name of a file should reflect the folder architecture
- Avoid folders with a depth of more than 4. We can have folders inside the layers folders, but not more
- Separate INET and FLoRaSat imports in
.hfiles to organize the import section
Terminology¶
Nodes¶
| Common Name | Project Name |
|---|---|
| User device | Terminal |
| LEO Satellite | Satellite |
| Base/Ground station | Station |
| Network server | Server |
Submodules¶
| Abbreviation | Full Name |
|---|---|
| ISL | Inter-Satellite Link |
| DSL | Device to Satellite Link |
| GSL | Ground to Satellite Link |
Each link type (ISL/DSL/GSL) can contain the following functional layers:
- Physical
- Data_Link
- Network
- Application
- Energy
- Mobility
File Name Convention¶
To ensure clarity and consistency across the project, file names should follow a structured naming convention. The recommended pattern is:
Entity Abbreviations¶
| Abbreviation | Node Type |
|---|---|
Ter |
Terminal |
Sat |
Satellite |
Sta |
Station |
Srv |
Server |
Category¶
Refers to the functional aspect of the file (e.g., Mob for mobility, Mac for MAC layer, Phy for PHY layer, Rout for routing, etc.).
Description¶
Provides a brief and specific explanation of what the file implements.
Additional Suggestions¶
- Use CamelCase for readability
- Avoid unnecessary abbreviations unless they are well understood within the project
- The file name should be descriptive but concise
- Each filename must be unique within its functional category