diff --git a/README.md b/README.md new file mode 100644 index 0000000..8679d99 --- /dev/null +++ b/README.md @@ -0,0 +1,122 @@ +## Requirements + +Make 4.4.1 +GCC 14.2 +RAYLIB 5.5 + + +This document outlines the coding style and conventions to be followed. + +## 1. **File Structure** + +- Header files should be wrapped with include guards to avoid multiple inclusions: + + ```c + #ifndef PHYSICS_H + #define PHYSICS_H + ... + #endif // PHYSICS_H + ``` + +## 2. **Naming Conventions** + +- **Functions:** Function names should use `CamelCase` starting with a upercase letter. + +`UpdatePhysicsDirection`, `UpdatePhysicsVelocity` + +- **Structs:** Struct names should use `CamelCase` starting with an uppercase letter. + +`Physics` + +- **Variables:** Use `CamelCase` starting with a lowerase letter for local and parameter variables. + +`vector`, `newSpeed` + +## 3. **Function Design** + +- Functions should be named descriptively, indicating the purpose or action performed. + +`UpdatePhysicsDirection`, `UpdatePhysicsVelocity` + +- Functions should take pointers when modifying variables outside their scope. + +`void UpdatePhysicsDirection(Vector2 *direction, Vector2 vector)` + +- Ensure function parameters have clear names to indicate their role. + +`UpdatePhysicsVelocity(Vector2 *velocity, Vector2 *direction, float *speed)` + +- Functions should be concise and focused on a single task. Avoid functions with multiple responsibilities. + +## 4. **Struct Design** + + - Prefer composition, where structs are composed of other structs or primitive data types. This allows for more flexible and modular designs. + + ```c + typedef struct { + Vector2 position; + Vector2 direction; + Vector2 velocity; + float speed; + } Physics; + ``` + + Here, instead of trying to create a hierarchy of structs, we compose a Physics struct with relevant fields like `position`, `direction`, and `velocity`. + +## 5. **Indentation & Formatting** + +- **Indentation:** Use 1 tab for indentation. Never use spaces. + +- **Spacing:** Place a single space after keywords like `if`, `for`, and `while`, and around operators (`=`, `+`, `-`, etc.) for readability. + - Example: `*velocity = Vector2Scale(*direction, *speed * GetFrameTime());` + +- **Braces:** Use braces `{}` even for single-line blocks for consistency and future-proofing. + + ```c + if (condition) { + do_something(); + } + ``` + +## 6. **Pointer Usage** + +- Use pointers when passing large structures or when modifying variables outside the scope of the function. + +`Vector2 *position`, `float *speed` + +- Avoid unnecessary dereferencing and use `*` clearly to indicate pointer dereferencing. + +`*position = Vector2Add(*position, *velocity);` + +## 7. **Consistency in Function Calls** + +- When calling functions, parameters should be passed clearly, and care should be taken to avoid modifying data unintentionally unless needed. + + ```c + UpdatePhysicsDirection(&physics->direction, direction); + UpdatePhysicsVelocity(&physics->velocity, &physics->direction, &physics->speed); + UpdatePhysicsPosition(&physics->position, &physics->velocity); + ``` + +## 8. **Comments and Documentation** + +- Strive for clarity through descriptive naming and simple logic. +- Add comments to explain non-obvious logic, design decisions, or complex algorithms. +- Do not state the obvious; let the code speak for itself where possible. + +## 9. **End of File** + +- Always ensure that header files end with the appropriate closing include guard and a new line after the last line of code: + + ```c + #endif // PHYSICS_H + + ``` + +## 10. **General Rules** + +- **Modular Design**: Break code into small, focused functions and modules with clear interfaces. +- **Refactoring**: Regularly refactor code to maintain simplicity and performance +- **Don't Repeat Yourself**: Reuse code by creating helper functions to avoid duplication +- **Avoid magic numbers:** Use constants or defines instead of hardcoded values. +- **Code readability:** Prioritize code readability and maintainability over shortness or cleverness.