Clean code a handbook of agile software craftsmanship
tải về 0.5 Mb. Chế độ xem pdf
|
12-KTXH-VUONG QUOC DUY(105-113)
- Điều hướng trang này:
- Tạo nên những sự khác biệt có nghĩa
| Tránh sai lệch thông tin
Các lập trình viên phải tránh để lại những dấu hiệu làm code trở nên khó hiểu. Chúng ta nên tránh dùng những từ mang nghĩa khác với nghĩa cố định của nó. Ví dụ, các tên biến như hp, aix và sco là những tên biến vô cùng tồi tệ, chúng là tên của các nền tảng Unix hoặc các biến thể. Ngay cả khi bạn đang code về cạnh huyền (hypotenuse) và hp trông giống như một tên viết tắt tốt, rất có thể đó là một cái tên tồi. Không nên quy kết rằng một nhóm các tài khoản là một accountList nếu nó không thật sự là một danh sách (List). Từ danh sách có nghĩa là một thứ gì đó cụ thể cho các lập trình viên. Nếu các tài khoản không thực sự tạo thành danh sách, nó có thể dẫn đến một kết quả sai lầm. Vậy nên, accountGroup hoặc bunchOfAccounts, hoặc đơn giản chỉ là accounts sẽ tốt hơn. Cẩn thận với những cái tên gần giống nhau. Mất bao lâu để bạn phân biệt được sự khác nhau giữa XYZControllerForEfficientHandlingOfStrings và XYZControllerForEfficientStorageOfStrings trong cùng một module, hay đâu đó xa hơn một chút? Những cái tên gần giống nhau như thế này thật sự, thật sự rất khủng khiếp cho lập trình viên. Một kiểu khủng bố tinh thần khác về những cái tên không rõ ràng là ký tự L viết thường và O viết hoa. Vấn đề? Tất nhiên là nhìn chúng gần như hoàn toàn giống hằng số không và một, kiểu như: int a = l; if ( O == l ) a = O1; else l = 01; Bạn nghĩ chúng tôi xạo? Chúng tôi đã từng khảo sát, và kiểu code như vậy thực sự rất nhiều. Trong một số trường hợp, tác giả của code đề xuất sử dụng phông chữ khác nhau để tách biệt chúng. Một giải pháp khác có thể được sử dụng là truyền đạt bằng lời nói hoặc để lại tài liệu cho các lập trình viên sau này có thể hiểu nó. Vấn đề được giải quyết mà không cần phải đổi tên để tạo ra một sản phẩm khác. Tạo nên những sự khác biệt có nghĩa Các lập trình viên tạo ra vấn đề cho chính họ khi viết code chỉ để đáp ứng cho trình biên dịch hoặc thông dịch. Ví dụ, vì bạn không thể sử dụng cùng một tên để chỉ hai thứ khác nhau trong cùng một khối lệnh hoặc cùng một phạm vi, bạn có thể bị “dụ dỗ” thay đổi tên một cách tùy tiện. Đôi khi điều đó làm bạn cố tình viết sai chính tả, và người nào đó quyết định sửa lỗi chính tả đó, khiến trình biên dịch không có khả năng hiểu nó (cụ thể – tạo ra một biến tên klass chỉ vì tên class đã được dùng cho thứ gì đó). Mặc dù trình biên dịch có thể làm việc với những tên này, nhưng điều đó không có nghĩa là bạn được phép dùng nó. Nếu tên khác nhau, thì chúng cũng có ý nghĩa khác nhau. 18 Những tên dạng chuỗi số (a1, a2,… aN) đi ngược lại nguyên tắc đặt tên có mục đích. Mặc dù những tên như vậy không phải là không đúng, nhưng chúng không có thông tin. Chúng không cung cấp manh mối nào về ý định của tác giả. Ví dụ: public static void copyChars( char a1[], char a2[]) { for ( int i = 0 ; i < a1.length; i++) { a2[i] = a1[i]; } } Hàm này dễ đọc hơn nhiều khi nguyên nhân và mục đích của nó được đặt tên cho các đối số. Những từ gây nhiễu tạo nên sự khác biệt, nhưng là sự khác biệt vô dụng. Hãy tưởng tượng rằng bạn có một lớp Product, nếu bạn có một ProductInfo hoặc ProductData khác, thì bạn đã thành công trong việc tạo ra các tên khác nhau nhưng về mặt ngữ nghĩa thì chúng là một. Info và Data là các từ gây nhiễu, giống như a, an và the. Lưu ý rằng không có gì sai khi sử dụng các tiền tố như a và the để tạo ra những khác biệt hữu ích. Ví dụ, bạn có thể sử dụng a cho tất cả các biến cục bộ và tất cả các đối số của hàm. a và the sẽ trở thành vô dụng khi bạn quyết định tạo một biến theZork vì trước đó bạn đã có một biến mang tên Zork. Những từ gây nhiễu là không cần thiết. Từ variable sẽ không bao giờ xuất hiện trong tên biến, từ table cũng không nên dùng trong tên bảng. NameString sao lại tốt hơn Name? Name có bao giờ là một số đâu mà lại? Nếu Name là một số, nó đã phá vỡ nguyên tắc Tránh sai lệch thông tin. Hãy tưởng tượng bạn đang tìm kiếm một lớp có tên Customer, và một lớp khác có tên CustomerObject. Chúng khác nhau kiểu gì? Cái nào chứa lịch sử thanh toán của khách hàng? Còn cái nào chứa thông tin của khách? Có một ứng dụng minh họa cho các lỗi trên, chúng tôi đã thay đổi một chút về tên để bảo vệ tác giả. Đây là những thứ chúng tôi thấy trong mã nguồn: getActiveAccount(); getActiveAccounts(); getActiveAccountInfo(); Tôi thắc mắc không biết các lập trình viên trong dự án này phải getActiveAccount như thế nào! Trong trường hợp không có quy ước cụ thể, biến moneyAmount không thể phân biệt được với money; customerInfo không thể phân biệt được với customer; accountData không thể phân biệt được với account và theMessage với message được xem là một. 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. |