0. Đừng lo lắng về những gì không quan trọng (Hoặc: Biết rõ những gì không cần tiêu chuẩn hóa)

Estimated reading: 9 minutes 329 views

Tóm tắt

Chỉ nói những gì cần nói: Đừng áp đặt sở thích cá nhân hoặc những tập quán lỗi thời.

Thảo luận

Đừng áp đặt các vấn đề liên quan đến sở thích cá nhân nếu chúng không ảnh hưởng đến tính chính xác hoặc khả năng đọc mã, vào các mục tiêu chuẩn hoá. Bất kỳ Dev chuyên nghiệp nào cũng có thể dễ dàng đọc và viết mã có định dạng khác một chút so với thói quen cũ của họ.
Hãy sử dụng định dạng nhất quán trong từng file nguồn và từng dự án, vì việc chuyển đổi giữa nhiều phong cách lập trình trong cùng một đoạn mã sẽ gây khó chịu. Nhưng đừng cố gắng áp đặt định dạng nhất quán trên nhiều dự án hoặc trên toàn công ty.

Dưới đây là một số vấn đề không cần đặt ra quy tắc mà chỉ cần thống nhất phong cách (kiểu) lập trình, ít nhất là trong phạm vi file bạn đang làm việc:

Không chỉ định thụt lề bao nhiêu, nhưng hãy thụt lề để hiển thị cấu trúc: Sử dụng bất kỳ số lượng khoảng trắng nào bạn muốn thụt lề nhưng phải nhất quán trong ít nhất mỗi file.
Không chỉ định độ dài cụ thể của 1 dòng, nhưng hãy giữ độ dài dòng có thể đọc được: Sử dụng bất kỳ độ dài dòng nào bạn thích, nhưng đừng quá dài. Các nghiên cứu cho thấy độ rộng văn bản tối đa 10 từ là dễ theo dõi nhất cho mắt.
Không áp dụng quy tắc đặt tên quá nghiêm khắc, nhưng phải có quy ước đặt tên nhất quán. Cần tuân thủ 2 điều sau:
- Không sử dụng tên bắt đầu bằng dấu gạch dưới “_” hoặc dấu gạch dưới đôi “__”
- Luôn sử dụng tên toàn bộ viết hoa, ví dụ: TEN_TOANBO_VIETHOA cho định nghĩa Macro. Tránh dùng tên Macro là một từ hoặc đơn giản hoặc viết tắt, ví dụ T hoặc U. Viết #define T với bất kỳ điều gì đều sẽ gây rối cực kỳ.
Mặt khác hãy sử dụng tên có ý nghĩa phổ thông, đọc có thể hiểu được ý nghĩa, cách đặt tên tuân theo quy ước của file hoặc dự án hiện tại. Nếu bạn chưa có quy tắc đặt tên riêng có thể đặt tên như sau:
- Tên Class, Hàm và Enum: LikeThis
- Tên Biến: likeThis
- Tên Biến thành viên Private: likeThis_
- Macro: LIKE_THIS
Không quy định cách chú thích (Comment) (ngoại trừ trường hợp cần có một định dạng nhất định để dùng Tool trích xuất dữ liệu ra bên ngoài). Hãy viết những comment có ích: Nếu được hãy viết mã thay vì viết nhận xét (Xem mục 16). Không viết comment lặp lại mã, nghĩa là viết comment theo cách diễn giải khác của mã code, cách viết này dẫn đến sự không đồng bộ trong quản lý (Thứ nhất là mất thời gian quản lý, thứ hai là dưới áp lực của công việc, thời gian bạn sẽ có xu hướng chỉ sửa một trong hai phần trên). Vậy khi nào viết comment? Hãy viết những chú thích nhằm giải thích phương pháp sử dụng, cách tiếp cận vấn đề và những lý do căn bản của vấn đề.

Cuối cùng, đừng cố gắng áp đặt các quy tắc lỗi thời (xem Ví dụ 3 và 4) ngay cả khi chúng đã từng xuất hiện trong các tiêu chuẩn mã hóa cũ.

Ví dụ

Ví dụ 1: Vị trí dấu ngoặc nhọn

Không có sự khác biệt giữa các cách sau:

				
					void using_k_and_r_style() {
   //...
}
void putting_each_brace_on_its_own_line()
{
   //...
}
void or_putting_each_brace_onjts_own_line_indented()
   {
      //...
   }

Bất kỳ một Dev chuyên nghiệp nào đều có thể đọc các dạng code trên mà không gặp khó khăn gì cả. Nhưng hãy theo một phong cách nhất quán. Không đặt các dấu ngoặc nhọn một cách bừa bãi hoặc gây khó hiểu các phạm vi lồng nhau. Hãy theo phong cách có sẵn của file mà bạn đang làm việc. Trong loạt bài này, chúng tôi cũng cố gắng đặt vị trí các dấu ngoặc nhọn sao cho dễ đọc nhất có thể.

Ví dụ 2: Dấu cách và Tab

Có một số Team cấm sử dụng Tab trong nhóm của mình, ví dụ BoostLRG. Tuỳ vào trình soạn thảo (Editor) mà Tab sẽ khác nhau, cho nên khi sử dụng sai sẽ gây ra căn lề nhô ra, thụt vào hoặc có thể không thụt lề. Cũng có một số Team vẫn cho sử dụng Tab dựa trên việc hiểu rõ những nhược điểm tiềm tàng mà Tab có thể gây ra và sử dụng một số biện pháp đối phó. Trong trường hợp cho sử dụng Tab, để đảm bảo tính nhất quán của mã code, phải đảm bảo rằng các toàn bộ thành viên khi lập trình vẫn phải duy trì được tính rõ ràng và dễ đọc của mã (Mục 6). Trong trường hợp không được sử dụng Tab, thì hãy để Editor có tính năng chuyển đổi từ dấu cách thành Tab khi đọc mã code, và khi ghi ra file thì có tính năng chuyển đổi từ Tab về dấu cách.

Ví dụ 3: Ký hiệu Hungary

Trong một số ngôn ngữ lập trình không an toàn trong kiểu dữ liệu ví dụ như ngôn ngữ C, chúng ta hay sử dụng phương pháp nhúng ký hiệu Hungary vào tên biến số (Ví dụ: b / boolean, l / long, n / integer…). Phương pháp này vẫn có thể áp dụng cho các ngôn ngữ lập trình hướng đối tượng nhưng sẽ không có điểm lợi gì cả, nếu có thì chỉ có điểm bất lợi mà thôi; và nó cũng không sử dụng được cho các chương trình chung, phổ biến. Vì vậy, chúng tôi không đề xuất sử dụng phương pháp nhúng ký hiệu Hungary trong ngôn ngữ C++, một số bộ tiêu chuẩn lập trình cũng cấm sử dụng phương pháp này.

Ví dụ 4: Một đầu vào – Một đầu ra (SESE: Single Entry – Single Exit)

Có một số bộ tiêu chuẩn quy định mỗi hàm số có chính xác một lối thoát, nghĩa là chỉ có một câu lệnh return. Yêu cầu như vậy đã lỗi thời trong các ngôn ngữ hỗ trợ ngoại lệ và hàm hủy, trong đó các hàm thường có nhiều lối thoát. Thay vào đó hãy theo Mục 5 của chúng tôi, sẽ làm cho hiểu vấn đề một cách tự nhiên, lỗi khó phát sinh và viết các hàm đơn giản ngắn gọn.

Tham khảo

[BoostLRG] • [Brooks95] §12 • [Constantine95] §29 • [Keffer95] p. 1 • [Kernighan99] §1.1, §1.3, §1.6-7 • [Lakos96] §1.4.1, §2.7 • [McConnell93] §9, §19 • [Stroustrup94] §4.2-3 • [StroustrupOO] §4.9.3, §6.4, §7.8, §C.l • [SutterOO] §6, §20 • [SuttHyslOl]

Link