-
Notifications
You must be signed in to change notification settings - Fork 0
Coding Standards
Axyl S edited this page Dec 6, 2024
·
4 revisions
Our team has agreed upon specific coding standards to maintain code consistency, readability, and maintainability throughout the project. This section outlines the standards we follow for code formatting.
-
Indentation:
- We use 4 spaces per tab for indentation throughout the project.
- No trailing whitespace should be left at the end of any line.
-
Braces and Block Structures:
- Place the opening brace
{on the same line as the control statement. - Example:
if (condition) { // Code block }
- Place the opening brace
-
Line Length:
- Try to keep lines to 80 characters to maintain code readability.
-
Function Definitions:
- Functions must follow the format:
function function_name(parameters){ // function body }
- Functions must follow the format:
-
Commenting and Documentation:
- Use
/** ... */for function documentation, explaining its purpose, parameters, and return values. - Inline comments are encouraged where the logic is non-obvious, using
//.
- Use
-
Naming Conventions:
-
Variables: Use snake_case for names, e.g.,
is_running. -
Functions: Use camelCase for functions, e.g.,
setScheduler(). - Constants: Use ALL_CAPS_WITH_UNDERSCORES.
-
Variables: Use snake_case for names, e.g.,
Our coding standards are aligned with the Linux Kernel Coding Style, with minor adjustments for team preferences, such as the use of 4-space tabs instead of 8 and same line function curly braces.
All errors in our project will be reported using the showToast function to ensure consistency and clarity. Each error message must follow the format:
console.log("No scheduler selected");