Module 5 Lesson 3: Linting and Style Checks

Code reviews shouldn't be about "Missing semicolons" or "Tabs vs Spaces." A computer should handle that. Linting is the practice of scanning code for style errors and "Potential" bugs (like an unused variable).

1. Why Lint in the Pipeline?

1. Uniformity: The codebase remains clean regardless of which developer wrote it.
2. Education: Linters teach junior developers best practices automatically.
3. No Arguing: If the "Linter" says the line is too long, the developer fixes it. No humans are blamed.

---

2. Implementing a Linter (JavaScript/ESLint)

lint-code:
  stage: test
  image: node:18
  script:
    - npm install
    - npx eslint . # This job fails if there are errors!

---

3. Style vs. Logic

• Prettier: Handles "How it looks" (Brackets, spaces, quotes).
• ESLint/Pylint/Rubocop: Handles "How it works" (Unused imports, shadow variables, dangerous functions).

Best Practice: Run both!

---

4. Visualizing Linter Results

GitLab can show "Code Quality" reports in your Merge Request, highlighting which specific line of code broke the style rules.

include:
  - template: Code-Quality.gitlab-ci.yml

code_quality:
  artifacts:
    exposed_as: 'Code Quality Report'
    paths: [gl-code-quality-report.json]

---

Exercise: The Clean Code Audit

1. Add eslint to your local project.
2. Create a GitLab CI job that runs the lint check.
3. Intentional Mess: Add 10 empty lines between two functions and push.
4. Does the pipeline catch the mess?
5. Why should the "Lint" stage usually happen BEFORE the "Test" stage? (Hint: Speed).
6. Research: What is the "AirBnb Style Guide," and why is it popular in the industry?

---

Summary

Automated linting is the secret to a professional-grade repository. By delegating style enforcement to your GitLab pipeline, you free up your team to focus on the things that matter: building great features and solving complex problems.

Next Lesson: Locking the gates: Security Scanning (SAST and DAST).