# 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** 1. 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ũ 3. 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 5. 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.