[2024Q4] feat: update clean code (#1735)

* feat: update  clean code

* fix: external link

* fix: internal links

* chore: run prettier

* feat: update task description

* fix: a typo

stage1/modules/clean-code/README.md

@@ -1,6 +1,10 @@
 # [Stage#1](../../) Project 'Clean Code S1E1'
 
-## In this module, students should:
+## Module Overview 📚
+
+This module provides a comprehensive introduction to the fundamental principles of clean code, including DRY, KISS, and YAGNI. It emphasizes the importance of writing maintainable, readable, and efficient code, covering essential practices like code formatting, effective comments, and proper commit styling. Through this module, students will gain hands-on experience with style guides, laying the foundation for producing high-quality, professional-level code.
+
+## Learning Objectives 🎯
 
 - Learn the general principles:
   - DRY
@@ -14,11 +18,11 @@
   - Tools, linters
 - Start learning the practices of writing clean, readable code
 
-## Approximate time to complete the module
+## Approximate time to complete the module 🕒
 
 10 hours
 
-## Theory part
+## Theory 📖
 
 You need to read the materials:
 
@@ -27,14 +31,15 @@ You need to read the materials:
 - [Common rules for HTML & CSS. Part 1](materials/html-and-css.md)
 - [Common rules for HTML & CSS. Part 2](materials/html-and-css-extended.md)
 
-## Practice part
+## Practice part 💻
 
 1. Complete the task ['Clean Code S1E1'](clean-code-s1e1.md)
-2. Pass the "Test for generic principles" in the RS APP.
+2. Pass the "[St1] Clean-code" test in the RS APP > Auto Test.
 
-## Additional materials
+## Additional Resources 📘
 
 - "Clean code", Robert Martin
+- [clean-code-javascript](https://github.com/ryanmcdermott/clean-code-javascript)
 - [Wikipedia: Coding Conventions](https://en.wikipedia.org/wiki/Coding_conventions)
 - [Git commit editing](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)
   - [How to use Vim or how to change Git editor](https://www.tempertemper.net/blog/changing-editor-for-git-on-the-command-line)

stage1/modules/clean-code/clean-code-s1e1.md

@@ -2,52 +2,55 @@
 
 # Task "Clean Code S1E1"
 
-![image](clean-code.png)
+<div align="center">
+  <img src="clean-code.png" width="50%">
+</div>
 
 Here is a small single-page [TODO-list application](https://github.com/rolling-scopes-school/clean-code-s1e1).
-Your task is to edit and change code – refactor code files, while the functionality of the application should remain the same. Changes should be made according the following guidelines: [html-and-css](materials/html-and-css.md) and [html-and-css-extended](materials/html-and-css-extended.md).
+Your task is to edit and change code – refactor code files, while the functionality of the application must remain the same. Changes must be made according the following guidelines: [html-and-css](materials/html-and-css.md) and [html-and-css-extended](materials/html-and-css-extended.md).
 
 No automatic code formatting tools are expected to be used at this task.
 
 ## Implementation Requirements
 
-**Warning!** Student can give a 0, if at least one of the following requirements is not met:
+**Warning!** A reviewer can give 0 points if at least one of the following requirements is not met:
 
-- Use a personal **public** repository on GitHub to complete the task.
-  Make a fork of an existing project or just create a new one and copy the task project files.
-- One commit should contain changes according to one point of the guides and should also have all the made changes in the commit message. Intersection of 2 or more rules in a single commit is acceptable if compliance of one rule automatically leads to compliance of others (all rules should be listed in commit message in this case).
-- Each commit should be made according to the [commit requirements](https://docs.rs.school/#/git-convention?id=%d0%a2%d1%80%d0%b5%d0%b1%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%ba-%d0%b8%d0%bc%d0%b5%d0%bd%d0%b0%d0%bc-%d0%ba%d0%be%d0%bc%d0%bc%d0%b8%d1%82%d0%be%d0%b2).
+1. Use a personal **public** repository on GitHub to complete the task. Make a fork of the existing project or create a new one named `clean-code-s1e1` and copy the task project files (in this case the commit message for adding the files must start with `"init:"`).
+2. One commit must contain changes related to a single point of the guidelines, the commit message must reflect all the changes made in the commit. Intersection of two or more rules in a single commit is acceptable only if compliance of one rule automatically leads to compliance of another one and it is impossible to separate them (all the rules must be listed in a commit message in this case).
+3. Prettier or other automatic code formatting tools must not be used.
+4. Each commit must be made according to the [commit requirements](https://docs.rs.school/#/git-convention?id=%d0%a2%d1%80%d0%b5%d0%b1%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%ba-%d0%b8%d0%bc%d0%b5%d0%bd%d0%b0%d0%bc-%d0%ba%d0%be%d0%bc%d0%bc%d0%b8%d1%82%d0%be%d0%b2) and comply consistently with one of the [commit message style](#commit-message-style) options.
+5. Create a new branch from `main` and name it `clean-code-s1e1`. All your changes must be made inside this new branch.
+6. [The original application functionality](#application-functionality) must remain the same after all your changes or be fixed if necessary.
+7. Once the task is completed, create a Pull Request from the branch `clean-code-s1e1` into `main` of your personal **public** repository.
 
-- Create a new branch from the `main(master)` and name it as `clean-code-s1e1`. All your changes should be made inside this new branch.
-- [The original application functionality](#application-functionality) must remain the same after all your changes.
-- Once the task is completed, create a Pull Request from the branch `clean-code-s1e1` into `main(master)` of your personal **public** repository.
+   **Warning!**: if you have forked the project, the default branch to create a PR will be `main` of the task description repository. You MUST change the repository and open a PR into the `main` branch of **YOUR** repository.
 
-  **Warning!**: if you have forked the project, you will be advised to create a PR into the task description repository. You MUST change the repository and create the PR into `main(master) branch of` **YOUR** repository.
-
-- Pull Request must be created according to [the following rules](https://docs.rs.school/#/pull-request-review-process?id=%d0%a2%d1%80%d0%b5%d0%b1%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%ba-pull-request-pr).
-- ❗ You should submit your **Pull Request** link once the task is completed.
+8. A Pull Request must be described according to [the following rules](https://docs.rs.school/#/pull-request-review-process?id=%d0%a2%d1%80%d0%b5%d0%b1%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f-%d0%ba-pull-request-pr).
+9. `main` branch must not be modified.
+10. The PR must be open.
+11. ❗ Submit your **Pull Request** link once the task is completed.
 
 ### Application Functionality:
 
 - Adding a new item to the "TODO" tasks list.
 - Editing an item in the "TODO" tasks list.
 - Deleting an item from the "TODO" tasks list.
 - Marking an item as "COMPLETED" and moving it to the corresponding list via the checkbox.
-
 - Deleting an item from the "COMPLETED" list.
 - Editing an item in the "COMPLETED" list.
 - Marking an item as incomplete via the checkbox and moving it into the "TODO" tasks list.
-
 - The appearance of the application has not been changed.
+- Alternate text is present for all necessary images.
 - The delete button animation works.
 
 ### Recommendations:
 
-- Carefully rename the attributes, don't miss a single one, including the JS files.
+- Carefully rename the attributes, don't miss a single one, including the `.js` files.
 - You can deploy the application using `gh-pages` so it will be easier for the students to check your work.
-- Learn and apply all code refactoring tools that your IDE has.
 
-You have two commit styles - choose the one you like more. **Both of them are correct!**
+### Commit message style:
+
+You have two commit message styles - choose the one you like more. **Both of them are correct!**
 
 _Commit style №1:_
 
@@ -63,26 +66,34 @@ fix: add Html5 DOCTYPE tag according to rule 2.2 in html-and-css.md
 refactor: update CSS according to BEM to rule 2.1 in html-and-css-extended.md
 ```
 
+Commit messages must be written in English.
+
 ## Evaluation criteria
 
-**Check loyally, this task requires a lot of work. All arguable moments should be resolved in the higher score way. Stay human!**
+**Be lenient, this task requires a lot of work. All disputable issues must be resolved in the higher score way. Stay human!**
 
 **Maximum amount of points for the task +45**
 
-- +2 points for each of 15 list items [beginner guideline](materials/html-and-css.md), which is fully completed\*.
-- +5 points for each of 3 list items [advanced guideline](materials/html-and-css-extended.md), which if fully completed\*.
-- If there are changes in margins and padding because of HTML tags' replacement, that insignificantly change the UI, that's not a mistake, no penalties should be applied.
+- +2 points for each of 15 list items [beginner guideline](materials/html-and-css.md)\*.
+- +5 points for each of 3 list items [advanced guideline](materials/html-and-css-extended.md)\*.
+
+  (\*each rule must be applied throughout the entire project, not just for a piece of code).
 
-(\* the rule must be applied for the whole document, not just for a piece of code).
+- Changes in margins or padding because of HTML tags replacement that insignificantly change the UI must not be considered a mistake, no penalties must be applied. There is also no need to verify the layout of the application with PerfectPixel.
+
+- Please note that the fantasy font used in the application is commonly supported on Windows and Mac. If it doesn't display correctly on Linux, feel free to choose any other suitable font. A different similar font must not be considered a mistake, no penalties must be applied.
 
 ## Cross-check
 
-- The repository should be opened locally or on GitHub to review the task.
-- Form for the Cross-Check: https://rolling-scopes-school.github.io/checklist/ ("Clean code S1E1")
-- Cross-Check instruction: https://docs.rs.school/#/cross-check-flow.
+- To review the task you can open the repository locally or on GitHub.
+- The cross-check form is built-in on [RS App](https://app.rs.school/) ("Cross-Check: Review"), or you can use a cross-check [checklist](https://rolling-scopes-school.github.io/checklist/) ("Clean code S1E1").
+- [Cross-check flow](https://docs.rs.school/#/cross-check-flow).
+
+## Q&A
 
 [A document for questions](https://docs.google.com/spreadsheets/d/1lgzmc72mKCmYvHimvqBNENgKJuXMON8q1f1s4GEnEVI/edit?usp=sharing)
 
 ## Hints
 
-- To create the commits students are offered to use [Commitizen](https://github.com/commitizen/cz-cli). Its usage is not required.
+- To create the commits you can use [Commitizen](https://github.com/commitizen/cz-cli). Its usage is not required.
+- You can use [Husky](https://typicode.github.io/husky/) to verify your commit messages. Its usage is not required.

stage1/modules/clean-code/materials/commits.md

@@ -4,11 +4,11 @@
 
 ## Commits content requirements
 
-Each commit should have
+Each commit should contain one of the following:
 
-- either completed functionality / documentation
-- either completed fix of a defect in code
-- either completed code refactoring
+- completed functionality/documentation
+- completed fix of a defect in code
+- completed code refactoring
 
 Long story short, all changes in a commit should be described by one sentence with a single predicate.
 
@@ -17,15 +17,15 @@ Long story short, all changes in a commit should be described by one sentence wi
 - When a mentor is reviewing your Pull Request, it will be easier for them to look through the list of commits and check the logic in each commit separately than review the code of the whole application.
 - If the logic of one commit is wrong, you will be able to `revert` it without interfering with other functionality.
 
-## Commits name requirements
+## Commit message requirements
 
-- Commits' name must follow [the guideline](https://www.conventionalcommits.org/en/v1.0.0/)
+- Commit message must follow [the guideline](https://www.conventionalcommits.org/en/v1.0.0/)
 - Present tense must be used (e.g. `"add feature"`, not `"added feature"`)
 - Imperative mood must be used (e.g. `"move cursor to ..."`, not `"moves cursor to ..."`)
 
-### Examples of commits' names
+### Examples of commit messages
 
-- `init`: - is used for the beginning of a project or a task.
+- `init`: is used for the beginning of a project or a task.
 
   **Examples:**
 
@@ -34,7 +34,7 @@ Long story short, all changes in a commit should be described by one sentence wi
   init: start mentor-dashboard task
   ```
 
-- `feat`: – is used for adding a new feature (added zoom, added footer, updated product card etc.)
+- `feat`: is used when adding a new feature (added zoom, added footer, updated product card etc.)
 
   **Examples:**
 
@@ -50,7 +50,7 @@ Long story short, all changes in a commit should be described by one sentence wi
   feat: add real social icons
   ```
 
-- `fix`: – is used for fixing some bugs.
+- `fix`: is used for fixing some bugs.
 
   **Examples:**
 
@@ -61,7 +61,7 @@ Long story short, all changes in a commit should be described by one sentence wi
   fix: adjust social links for mobile
   ```
 
-- `refactor`: – code refactoring: application functionality wasn't changed, files were moved/created/deleted, code formatting changed, algorithms improved, but functional part is the same.
+- `refactor`: is used for code refactoring: the files were moved/created/deleted, code formatting changed, algorithms improved, but the functionality remains the same.
 
   **Examples:**
 
@@ -72,7 +72,7 @@ Long story short, all changes in a commit should be described by one sentence wi
   refactor: apply prettier
   ```
 
-- `docs`: – is used for docs/README updates.
+- `docs`: is used for docs/README updates.
 
   **Examples:**
 
@@ -83,23 +83,23 @@ Long story short, all changes in a commit should be described by one sentence wi
 
 ## PR Requirements
 
-**Pull Request** is a place to discuss code. It should not look like a student or mentor monologue. Be cultural, respect each other's time and work.
+**Pull Request** is a place to discuss code. It should not look like a student or mentor monologue. Be polite, respect each other's time and work.
 
 ### The Pull Request description should contain the following information:
 
 - A link to the task.
 - Screenshot of the result of the task (page of the created application or website). Add the screenshot to the Pull Request as an image.
 - A link to the deployed version of your application or website. You can use the following ways for the deployment:
   - `gh-pages` if there is a private repository of the school;
-  - if there is no private repository of the school or if it is impossible to place the application on gh-pages of the school's private repository - netlify.com or other similar hosting.
-  - for demos hosted on [netlify.com](netlify.com), the site name is given as: `github account name - task name`.
+  - if there is no private repository of the school or if it is impossible to deploy the application on gh-pages of the school's private repository - [Netlify](https://www.netlify.com/) or another similar hosting.
+  - for demos hosted on Netlify, the site name must be given as: `github account name - task name`.
 - Due Date / Deadline Date.
 - Your self-assessment with a preliminary grade.
-- It is recommended to add a link to a YouTube video of a self-check of the project you created (only for tasks that are cross-checked).
+- It is recommended to add a link to a self-check video of the project you created.
 
 #### PR Example:
 
-```markdown
+```md
 1. Task: [https://github.com/rolling-scopes-school/tasks/blob/master/tasks/fancy-weather.md]()
 2. Screenshot: ![](https://docs.rs.school/images/fancy-weather.png)
 3. Deploy: [https://chakapega-fancy-weather.netlify.com/]()
@@ -122,5 +122,5 @@ Long story short, all changes in a commit should be described by one sentence wi
 
 ### PR should not contain:
 
-- Commented code.
-- Some extra files, autogenerated code, node_modules folder etc. Use `.gitignore` for such cases. [More](https://git-scm.com/docs/gitignore)
+- Commented out code.
+- Any extra files, autogenerated code, node_modules folder etc. Use `.gitignore` for such cases. [More](https://git-scm.com/docs/gitignore)