From eb07f85e02bc111f98e2f01119c1a3cb218d0315 Mon Sep 17 00:00:00 2001 From: srgooglo <38926803+srgooglo@users.noreply.github.com> Date: Fri, 4 Jul 2025 22:09:08 +0200 Subject: [PATCH] Update CODE_STYLE.md --- CODE_STYLE.md | 36 +++++++++++++++++------------------- 1 file changed, 17 insertions(+), 19 deletions(-) diff --git a/CODE_STYLE.md b/CODE_STYLE.md index 7128659e..93088cba 100755 --- a/CODE_STYLE.md +++ b/CODE_STYLE.md @@ -15,31 +15,29 @@ This document outlines the code style guidelines for the Comty project. The goal ## Language-specific Guidelines ### JavaScript + +#### Do's - Use ES6 syntax and features whenever possible. - - Use double quotes for strings, including for JSX. - - Use const and let instead of var. - - Always use strict equality (=== and !==) for comparisons. - -- Avoid using eval() and with(). - -- Use camelCase for variable and function names. - -- Use PascalCase for class and component names. - -- Use four spaces for indentation. - -- Use a CSS preprocessor like LESS to organize styles. (We recommend use LESS cause it's used in the project, we prefer to no include another dependency) - -- Use kebab-case for ID names. - +- Use a CSS preprocessor like LESS. (We recommend use LESS cause it's used in the project, we prefer to no include another dependency) +- Use the :hover, :focus, and :active pseudo-classes as needed. +- Use descriptive class and ID names that clearly indicate their purpose. - Use a consistent naming convention for classes and IDs, and avoid using inline styles. -- Use the :hover, :focus, and :active pseudo-classes as needed. +#### Dont's +- Don't include unnecesary logs over the console. +- Don't declare unnecesary variables. +- Avoid using eval() and with(). -- Use descriptive class and ID names that clearly indicate their purpose. +#### Format +- Use 2 tabs for indentation. +- Use kebab-case for ID names. +- Use camelCase for variable and function names. +- Use PascalCase for class and component names. + +Preferably use prettier to format all the code, the configuration file is included in the repository. ## Conclusion -By following these code style guidelines, we can create code that is easy to read, understand, and maintain. These guidelines are not exhaustive, and there may be cases where they don't apply or conflict with other guidelines. In such cases, use your best judgement and work with the team to come to a consensus. \ No newline at end of file +By following these code style guidelines, we can create code that is easy to read, understand, and maintain. These guidelines are not exhaustive, and there may be cases where they don't apply or conflict with other guidelines. In such cases, use your best judgement and work with the team to come to a consensus.