Login

Formatter và linter: dùng Prettier, ESLint để cả nhóm khỏi cãi nhau về style

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Tranh luận về dấu nháy đơn hay nháy kép, thụt lề hai hay bốn khoảng trắng, dấu chấm phẩy có nên có hay không... là chuyện làm mất thời gian của nhiều nhóm. Formatter và linter giải quyết triệt để việc này bằng cách giao cho máy móc. Bài này giải thích khác biệt, cách cài đặt và cách tích hợp vào quy trình.

Formatter và linter khác nhau thế nào?

  • Formatter (như Prettier, Black, gofmt) tự động sắp xếp lại cách trình bày code: thụt lề, xuống dòng, khoảng trắng, dấu nháy. Không thay đổi hành vi chương trình.
  • Linter (như ESLint, Pylint, Flake8, PHP_CodeSniffer, golangci-lint) phân tích code để phát hiện lỗi tiềm ẩn và code kém chất lượng: biến không dùng, so sánh sai, hàm quá phức tạp, thiếu xử lý trường hợp.

Hai công cụ bổ sung cho nhau: formatter lo hình thức, linter lo chất lượng. Nhiều dự án dùng cả hai.

Lợi ích cho nhóm

  1. Hết tranh luận về style: cả nhóm theo một chuẩn do công cụ quyết định.
  2. Diff gọn hơn: không còn thay đổi vô nghĩa về khoảng trắng làm nhiễu pull request.
  3. Review tập trung vào logic: người review không phải nhận xét về dấu chấm phẩy.
  4. Bắt lỗi sớm: linter phát hiện lỗi ngay khi gõ hoặc trước khi commit.
  5. Dễ cho người mới: viết theo công cụ nhắc, tự học được quy ước.

Cài đặt Prettier và ESLint trong dự án JavaScript

npm install --save-dev prettier eslint

Tạo file .prettierrc với vài tùy chọn đơn giản:

{"singleQuote": true,"semi": true,"printWidth": 100,"trailingComma": "es5"}

Thêm script vào package.json:

{"scripts": {"format": "prettier --write .","format:check": "prettier --check .","lint": "eslint ."}}

Cấu hình ESLint (tên file và định dạng thay đổi theo phiên bản, bạn có thể dùng lệnh khởi tạo npm init @eslint/config để tạo theo hướng dẫn). Với dự án dùng cả hai, cần đảm bảo các quy tắc ESLint về định dạng không xung đột với Prettier, thường qua cấu hình eslint-config-prettier.

Đừng quên tạo .prettierignore hoặc cấu hình ignore để bỏ qua thư mục sinh tự động như node_modules, dist.

Công cụ tương đương ở các ngôn ngữ khác

Ngôn ngữFormatterLinter
JavaScript / TypeScriptPrettierESLint
PythonBlack, Ruff formatRuff, Flake8, Pylint
PHPPHP-CS-Fixer, Laravel PintPHPStan, Psalm, PHP_CodeSniffer
Gogofmtgolangci-lint, go vet
Javagoogle-java-format, SpotlessCheckstyle, SpotBugs
RustrustfmtClippy

Tích hợp vào editor: format khi lưu

Cách tiện nhất là để editor tự định dạng mỗi khi bạn lưu file. Với VS Code, cài extension Prettier và ESLint rồi thêm vào settings:

{"editor.formatOnSave": true,"editor.defaultFormatter": "esbenp.prettier-vscode","editor.codeActionsOnSave": {"source.fixAll.eslint": "explicit"}}

Từ đó bạn gần như không bao giờ phải nghĩ đến định dạng nữa.

Chặn lỗi trước khi commit và trên CI

Không thể tin mọi người cấu hình editor giống nhau, vì vậy hãy kiểm tra ở hai tầng:

  1. Pre-commit hook: dùng Husky kết hợp lint-staged (hệ sinh thái JavaScript) hoặc framework pre-commit (Python và nhiều ngôn ngữ) để tự động định dạng và lint các file thay đổi trước mỗi commit.
  2. CI (tích hợp liên tục): chạy npm run format:check và npm run lint trong pipeline. Nếu lỗi thì pull request không được merge. Đây là lưới an toàn cuối cùng.
{"lint-staged": {"*.{js,ts,jsx,tsx}": ["prettier --write", "eslint --fix"],"*.{json,md,css}": ["prettier --write"]}}

Áp dụng vào dự án đã có sẵn code

Khi đưa formatter vào dự án cũ, lần chạy đầu sẽ thay đổi rất nhiều dòng. Một số lời khuyên:

  • Làm việc đó trong một pull request riêng, chỉ chứa thay đổi định dạng, không trộn với logic.
  • Thông báo trước cho cả nhóm để tránh xung đột với các nhánh đang làm dở.
  • Thêm commit định dạng vào danh sách bỏ qua của git blame bằng file .git-blame-ignore-revs, để lịch sử tác giả dòng code không bị che bởi commit này.

Nguyên tắc chọn quy tắc

  • Với formatter, ít tùy chọn càng tốt; chấp nhận mặc định và đừng tốn thời gian tinh chỉnh.
  • Với linter, bắt đầu từ bộ quy tắc khuyến nghị của cộng đồng, bật dần các quy tắc nghiêm ngặt hơn.
  • Phân biệt lỗi (error, chặn merge) và cảnh báo (warning, nên xem xét).
  • Khi cần tắt một quy tắc ở một dòng, ghi lý do bằng comment.
  • Xem lại cấu hình định kỳ: quy tắc nào gây phiền mà không mang lại giá trị thì bỏ.

Kết luận

Hãy để máy làm việc của máy: định dạng và bắt lỗi cơ bản tự động, con người tập trung vào thiết kế và logic. Chỉ cần một buổi chiều cấu hình, bạn và cả nhóm sẽ tiết kiệm được rất nhiều thời gian về sau.

Nếu bạn muốn học cách thiết lập môi trường làm việc chuyên nghiệp cho dự án, hãy xem qua các khóa học trên codebem.com.

author_photo
Nguyễn Đình Cường

0 comment