QUY ƯỚC CODE

V. Quy ước đặt tên

9. Biến

Sử dụng camelCase
Tên phải có ý nghĩa
Không viết tắt khó hiểu

Không sử dụng tên như: a, data1, temp, test nếu không có ý nghĩa rõ ràng.

10. Class và Interface

Sử dụng PascalCase
Tên phản ánh đúng chức năng

Ví dụ:

UserSyncService
AuthController
DataMappingRepository

Không đặt tên chung chung như: Service1, TestClass.

11. Tên file

Tên file trùng với class chính
Không đặt tên file không rõ nghĩa

Không sử dụng các tên như: utils2, newfile, test.

VI. Cấu trúc và tổ chức code

12. Phân tầng rõ ràng

Controller không chứa business logic phức tạp
Service không truy cập database trực tiếp nếu đã có repository layer
Không viết toàn bộ logic trong một file duy nhất

Phải tuân thủ đúng kiến trúc đã thống nhất của dự án.

13. Hàm và logic

Một function chỉ nên thực hiện một nhiệm vụ
Không viết function quá dài và khó theo dõi
Logic phức tạp phải được tách nhỏ

Nếu một function vượt quá mức hợp lý và khó đọc, reviewer có quyền yêu cầu refactor.

14. Logging

Log phải có mục đích rõ ràng
Không log dữ liệu nhạy cảm
Không để log debug dư thừa trước khi merge

15. Xử lý lỗi

Không catch lỗi mà bỏ qua
Không throw lỗi chung chung
Message lỗi phải rõ ràng, có ngữ cảnh

Không để các khối catch rỗng hoặc bỏ qua exception.

16. Format và kiểm tra tự động

Bắt buộc sử dụng ESLint / Prettier theo cấu hình dự án
Không merge nếu format sai
Không thay đổi format toàn bộ file nếu không liên quan đến task

VII. Trách nhiệm kỹ thuật

Code trước khi tạo PR phải:

Chạy được
Không lỗi compile
Không làm hỏng chức năng cũ

Người thực hiện task chịu trách nhiệm:

Test lại trước khi merge
Theo dõi lỗi phát sinh sau khi merge

Không đổ lỗi cho quá trình merge nếu chưa kiểm tra kỹ trước đó.

VIII. Xử lý vi phạm

17. Vi phạm mức độ 1 – Yêu cầu chỉnh sửa

Áp dụng khi:

Sai format
Sai naming
Commit message không đúng quy ước
PR thiếu mô tả

Hình thức xử lý:

Yêu cầu chỉnh sửa trước khi approve

18. Vi phạm mức độ 2 – Từ chối merge

Áp dụng khi:

Không tuân thủ workflow
Tự ý commit vào nhánh chính
Không xử lý conflict
Không test trước khi tạo PR

Hình thức xử lý:

Từ chối merge
Yêu cầu làm lại theo đúng quy trình

19. Vi phạm mức độ 3 – Đánh giá năng lực kỹ thuật

Áp dụng khi:

Lặp lại vi phạm nhiều lần
Không tuân thủ quy ước dù đã được nhắc
Gây ảnh hưởng nghiêm trọng đến hệ thống

Hình thức xử lý:

Trao đổi trực tiếp
Đánh giá lại mức độ phù hợp trong dự án

IX. Hiệu lực

Quy định này có hiệu lực kể từ ngày ban hành và áp dụng cho toàn bộ thành viên tham gia phát triển dự án.

Mọi thay đổi về workflow hoặc quy ước kỹ thuật phải được thống nhất trước khi áp dụng.