|
1 |
| -# Plain Robot Template |
2 |
| - |
3 |
| -This template is an extension of the WPILib CommandRobot template.<br> |
4 |
| -The extra features of this template are: |
5 |
| -* SpikesLib2, CTRE Phoenix and REVLib vendordeps are added by default. |
6 |
| -* Removal of the example commands and classes WPILib creates by default. |
7 |
| -* A robot map with CAN, DIO, PWM and AIN interfaces. |
8 |
| -* Most importantly, this template includes a Meguvalded OI™ <sub>(patent pending)</sub>. |
| 1 | +# Crescendo 2024 |
| 2 | + |
| 3 | +This is the official code of team Spikes#2212 for the 2024 FRC season. |
| 4 | + |
| 5 | +## Code Conventions |
| 6 | + |
| 7 | +#### General |
| 8 | + |
| 9 | +1. This project is developed according to our java code style convention, |
| 10 | + described [here](https://docs.google.com/document/d/1rGkyMf1XVvJ3K8mu5f1Gea2YFeEx2MpBVQo05D9ZVtY/edit?usp=sharing). |
| 11 | +2. Each branch is named in `lower-case`, according to the convention `author-feature`. |
| 12 | +3. Commit messages are written in `lower case`. |
| 13 | + |
| 14 | +#### Development |
| 15 | + |
| 16 | +#### Code Conventions |
| 17 | + |
| 18 | +All code in this project should be written according to the following conventions, code would not be merged in case it |
| 19 | +doesn't. |
| 20 | + |
| 21 | +1. All classes should be written in the following order |
| 22 | + 1. Constants Values |
| 23 | + 2. Class Members |
| 24 | + 3. Singleton Initialization |
| 25 | + 4. Constructor |
| 26 | + 5. Methods |
| 27 | +2. All `Namespace` instances should be named in `lower case`. |
| 28 | + |
| 29 | +#### Component Naming Conventions |
| 30 | + |
| 31 | +1. All CANBus components should be named in `lowerCamelCase` according to the following convention - |
| 32 | + `sideController \ index` |
| 33 | +2. All ports in RobotMap should be named in `ALL_CAPS` according to the following convention `SUBSYSTEM_COMPONENT_INDEX` |
| 34 | + |
| 35 | +##### Feature Branches |
| 36 | + |
| 37 | +This code is developed using the feature branches workflow. |
| 38 | + |
| 39 | +Each feature is developed inside its own branch, which is merged into dev after CR and testing. |
| 40 | + |
| 41 | +##### Testing |
| 42 | + |
| 43 | +Each feature branch should be forked by a `feature-testing` branch, in which all necessary testing code is |
| 44 | +added. <br> |
| 45 | +all the code fixes should be committed into this branch. |
| 46 | + |
| 47 | +After the code passes testing all the commits from the `-testing` are merged with the feature branch. |
| 48 | + |
| 49 | +##### DEV Branch |
| 50 | + |
| 51 | +All feature branches that passed testing successfully are later merged into the `dev` branch, which is in turn merged |
| 52 | +into `master` after passing complete testing and integration. |
0 commit comments