📖
Docs
  • Hi there 👋
  • Python
    • Tutorial
      • Class
      • Context Managers
      • Iterators and Iterables and generators
      • Lambda Operator
      • Decorators
      • Lập trình đa luồng
      • Singleton
      • Logging
      • Best practices
    • Django
      • Lazy queryset
      • Sql injection
      • Transaction
    • Flask
    • Fastapi
  • Struct data and algorithms
    • Struct data
    • Algorithms
  • database
    • Nosql và RDBMS
    • Index sql
    • Inverted Index
    • Migrate database best
    • Datatype
  • Cache
    • Caching strategies
    • Cache replacement policies
  • Message queue
    • Message queue
  • Other
    • Clean code
    • Design pattern
    • Encode-decode
    • Security
    • Docker
    • Celery
  • deploy
    • Jenkins
Powered by GitBook
On this page
  • Thế nào là clean code
  • Quy tắc đặt tên
  • Cách viết hàm
  • Comment
  • Format Code
  • Class
  • Một số nguyên tắc
  1. Other

Clean code

Thế nào là clean code

  • Dễ đọc

  • Dễ thay đổi

  • Dễ bảo trì

Quy tắc đặt tên

1. Dùng những tên thể hiện được mục đích

// Bad 
int a // elapsed time in days
// Good
int elapsedTimeInDays

2. Tạo sự khác biệt rõ ràng

Hãy phân biệt tên theo cách cung cấp cho người đọc những khác biệt rõ ràng.

getCustomer();
getCustomerInfo();
getCustomerData();

3. Dùng những tên phát âm được

// Bad
class DtaRcrd102 {
    private Date genymdhms;
    private Date modymdhms;
    private final String pszqint = "102";
};
// Good
class Customer {
    private Date generationTimestamp;
    private Date modificationTimestamp;
    private final String recordId = "102";
};

4. Dùng những tên tìm kiếm được

5. Không cần phải thêm các thành phần tiền tố

6. Tên lớp nên sử dụng danh từ hoặc cụm danh từ không nên là một động từ

7. Tên các phương thức nên là động từ ( get, set, is)

8. Chọn một từ cho mỗi khái niệm

fetch, retrieve, get là các phương thức có cùng chức năng nên thống nhất 1 cách đặt

9. Magic number

// Bad practice
for (let i = 0; i < 60; i++) {
  // do something
}

// Good practice
const MINUTES_OF_THE_HOUR = 60;
for (let i = 0; i < MINUTES_OF_THE_HOUR; i++) {
  // do something
}

10. Viết hoa các giá trị không đổi

  const DAYS_IN_A_YEAR = 365;

Cách viết hàm

  • Nguyên tắc đầu tiên của hàm là chúng phải nhỏ. Nguyên tắc thứ hai là chúng phải nhỏ hơn nữa

  • Hàm thực một việc

  • Tránh dùng nhiều vòng lặp lồng nhau

“HÀM CHỈ NÊN THỰC HIỆN MỘT VIỆC. CHÚNG NÊN LÀM TỐT VIỆC ĐÓ, VÀ CHỈ LÀM DUY NHẤT VIỆC ĐÓ”
  • Nguyên tắc stepdown

Chúng tôi muốn code được đọc tuần tự từ trên xuống. Chúng tôi muốn mọi hàm được theo sau bởi các hàm có cấp độ trừu tượng lớn hơn để chúng tôi có thể đọc chương trình. Và khi chúng tôi xem xét một danh sách các khai báo hàm, mức độ trừu tượng của chúng phải được giảm dần
Nguyên tắc Đơn nhiệm: Mỗi lớp chỉ nên chịu trách nhiệm về một nhiệm vụ cụ thể nào đó mà thôi.
Nguyên tắc Đóng & mở: Chúng ta nên hạn chế việc chỉnh sửa bên trong một Class hoặc Module có sẵn, thay vào đó hãy xem xét mở rộng chúng.
  • Đối số của hàm

Hàm có một đối số đầu vào sẽ là tốt “đứng thứ 2” (tốt nhất vẫn là hàm không có đối số).

Comment

“Đừng biến đống code gớm ghiếc của bạn thành comment – hãy viết lại nó” 
BRIAN W. KERNIGHAN AND P. J. PLAUGHER

Một số comment là cần thiết hoặc có ích. Chúng ta sẽ xem xét một vài trường hợp mà tôi cho là xứng đáng để bạn bỏ công ra viết. Tuy nhiên, hãy nhớ rằng comment thật sự tốt là comment không cần phải viết ra.

  • COMMENT PHÁP LÝ

  • COMMENT CUNG CẤP THÔNG TIN

  • GIẢI THÍCH MỤC ĐÍCH

  • TODO COMMENTS

Format Code

Luôn format code

Class

  • Lớp nên nhỏ

Nguyên tắc đơn trách nhiệm (SRP) nêu rõ rằng một lớp hoặc mô-đun nên có một và chỉ một lý do để thay đổi. Nguyên tắc này cung cấp cho chúng ta cả định nghĩa về trách nhiệm và hướng dẫn về quy mô của lớp. Các lớp chỉ nên có một trách nhiệm — chỉ một lý do để thay đổi.

Một số nguyên tắc

  • Single Responsibility Principle (SRP)

  • Open Closed Principle (OCP)

  • Dependency Inversion Principle (DIP)

PreviousMessage queueNextDesign pattern

Last updated 2 years ago