Tên xuất hiện ở khắp nơi trong phần mềm. Chúng ta đặt tên cho biến, hàm, danh sách tham số, lớp, gói. Sau đó chúng ta đặt tên tệp và tên thư mục chứa chúng, tên tệp jar và tệp war, tệp ear… Sau đây là một số quy tắc đơn giản để tạo ra một cái tên tốt.
Sử dụng những tên gợi tả mục đích
Mục lục
Thật đơn giản để nói về những cái tên được gợi tả. Việc lựa chọn tên tốt mất nhiều thời gian nhưng lại tiết kiệm được rất nhiều khi dùng. Vì vậy cần chú ý tới những cái tên bạn đặt và thay đổi chúng khi bạn tìm thấy tên tốt hơn. Khi bạn làm được điều đó, tất cả những ai khi đọc đoạn mã của bạn sẽ thấy dễ hiểu hơn.
Tên của biến, hàm, lớp nên giải đáp cho tất cả những câu hỏi lớn. Nó sẽ cho bạn biết lý do tại sao nó tồn tại, những gì nó làm và cách nó được sử dụng. Nếu một cái tên cần được yêu cầu giải thích, thì tên này không có ý nghĩa gợi tả.
int d; // thời gian trôi qua trong ngày
Tên biến d cho thấy không có nghĩa gì. Nó không diễn tả cảm giác thời gian trôi qua, cũng không phải nói về ngày. Chúng ta nên chọn một tên mô tả được điều đang diễn ra như:
|
1 2 3 4 5 6 7 |
int elapsedTimeInDays; int daysSinceCreation; int daysSinceModification; int fileAgeInDays; |
Sự chọn lựa những tên gợi tả làm cho ta dễ dàng hiểu và thay đổi khi lập trình hơn.
Tránh sai lạc
Lập trình viên phải tránh để lại manh mối sai mà che khuất nghĩa đoạn mã lệnh. Chúng ta nên tránh những từ có nghĩa khác với ý định thực của mình. Ví dụ, hp, aix, sco là những tên biến kém bởi chúng là những cái tên mô tả trong hệ điều hành Unix hay các phiên bản của nó. Thậm chí nếu bạn đang lập trình về hypotenuse và hp nhìn giống như từ viết tắt, đây không phải là thông tin tốt.
Không nên gọi một nhóm các tài khoản (account) là accountList trừ khi nó lưu trữ danh sách (list) thật sự. Từ danh sách (list) có nghĩa là một cái gì đó cụ thể cho các lập trình viên. Nếu các tài khoản này không được lưu trữ ở dạng danh sách, thì có thể danh đến những kết luận sai lệch. Vì vậy cái tên accoutGroup hoặc bunchOfAccounts chỉ ra danh sách chủ tài khoản vẫn tốt hơn.
Tạo nên sự khác biệt rõ ràng
Lập trình viên sẽ tự tạo ra vấn đề khi họ viết mã chỉ để thỏa mãn trình biên dịch hoặc trình thông dịch. Ví dụ, bởi vì bạn không thể sử dụng cùng một tên để chỉ hai việc khác nhau trong cùng một phạm vi, bạn có thể bị cám dỗ để thay đổi tên một tên theo cách ngẫu nhiên. Đôi khi, điều này được thực hiện do lỗi chính tả, dẫn đến tình huống ngạc nhiên sửa lỗi chính tả dẫn đến đoạn mã không có khả năng biên dịch được (Ví dụ khi đặt tên lớp là kclass bởi tên class đã được sử dụng cho việc khác).
Đặt tên cho một dãy số là (a1, a2, … aN) là ngược lại với việc đặt tên có chủ đích. Những tên này không làm hiểu sai, nhưng chúng cũng không có thông tin. Chúng không cung cấp manh mối về ý tưởng của tác giả.
Những từ nhiễu là một trường hợp khác của tên mà không có sự khác biệt đáng kể. Hãy tưởng tượng rằng bạn có lớp Product. Nếu bạn có một lớp khác được gọi ProductInfo hay ProductData. Bạn đặt những tên khác nhau mà không tạo ra bất kỳ sự khác biệt nào. Info và Data là hai từ nhiễu.
Các từ nhiễu là thừa. Một biến không bao giờ nên có tên variable. Từ table không nên xuất hiện trong tên bảng. Tên NameString tốt hơn Name ở chỗ nào? Name đã bao giờ là số thực chưa? Nếu như vậy nó phát vỡ quy tắc trước về sự sai lệnh thông tin. Hãy tưởng tượng việc tìm ra tên lớp là Customer và một cái tên khác đặt là CustomerObject. Bạn thấy sự khác biệt giữa hai cái tên này là gì? Tên nào sẽ mô tả tốt nhất cho lịch sử thanh toán của một khách hàng?
Giao diện và cài đặt
Thỉnh thoảng có một vài trường hợp đặc biệt khi mã hóa. Ví dụ, nếu bạn đang xây dựng một Abstract Factory để tạo ra đối tượng Shapes (hình). Factory này sẽ được tạo dưới dạng là interface và sẽ được thực thi bởi một lớp cụ thể. Vậy bạn nên đặt tên thế nào cho Factory đó? IShapeFactory hay ShapeFactory? Tôi thích interface ShapeFactory hơn. Khi xác định I phía trước interface, có nhiều phân tán và thông tin không tốt. Vì tôi không muốn khách hàng của tôi biết rằng tôi đang bàn giao cho họ một interface. Tôi chỉ muốn họ biết rằng đó là một ShapeFactory. Do vậy để mã hóa hay thực thi interface tôi chọn sự thực thi (implementation). Gọi đó là ShapeFactoryImp, hoặc thậm chí CShapeFactory hơn là mã hóa interface.
Tên lớp
Lớp và đối tượng nên có danh từ hoặc cụm danh từ như Customer, WikiPage, Account, và AddressParser. Tránh dùng những từ như Manager, Processor, Data, Infor trong tên của một lớp. Tên một lớp không nên là một động từ
Tên phương thức
Phương thức nên có động từ hoặc cụm động từ như postPayment, deletePage, hoặc save. Các phương thức truy xuất, thay đổi nên được đặt tên cho giá trị của chúng và tiền tốt get, get và is theo chuẩn của javabean.
string name = employee.getName();
customer.setName(“mike”);
if (paycheck.isPosted())…
Khi phương thức khởi tạo được nạp chồng, dùng phương thức tính với tên mô tả đối số truyền vào. Ví dụ:
Complex fulcrumPoint = Complex.FromRealNumber(23.0);
thường tốt hơn:
Complex fulcrumPoint = new Complex(23.0);
Hãy xem xét việc ép buộc dùng chúng bằng cách chuyển phương thức khởi tạo tương ứng thành private.
Chọn Một Từ cho mỗi Khái Niệm
Hãy chọn một từ cho mỗi khái niệm trừu tượng và gắn nó vào. Ví dụ, các phương phức tương đương của các lớp khác nhau có những tên fetch, retrieve và get. Làm sao bạn có thể nhớ được tên của phương thức trong mỗi lớp? Thật buồn, bạn vẫn thường phải nhớ công ty, nhóm hoặc cá nhân nào đã viết thư viện hoặc lớp đó để biết tên nào được sử dụng, nếu không bạn phải mất thời gian đáng kể để tìm kiếm.
Những IDE hiện đại như Eclipse và IntelliJ cung cấp những gì có thể dùng được trong hoàn cảnh đó, ví dụ như danh sách phương thức có thể gọi trên một đối tượng nào đó. Nhưng chú ý rằng, danh sách này không thường xuyên cho chúng ta những chú thích mà bạn đã viết xung quanh tên phương thức, danh sách tham số. Bạn thực là may mắn nếu IDE cho bạn biết tên của của tham số của phương thực. Tên phương thức phải độc lập và thống nhất để bạn có thể chọn đúng phương thức mà không cần phải tìm kiếm gì thêm.
Tương tự, việc có controller, manager và driver trong cùng một mã nguồn sẽ gây bối rối.
Thêm bối cảnh có ý nghĩa
Có rất ít tên mà tự thân có ý nghĩa, hầu hết là không. Bạn cần đặt tên vào bối cảnh, bằng việc đặt chúng vào lớp, hàm, gói có tên rõ nghĩa để giúp người đọc hiểu. Khi bạn không làm được những điều này thì có thể dùng tiền tố như giải pháp cuối cùng.
Hãy tưởng tượng bạn có các biến với tên như sau: firstName, lastName, street, houseNumber, city, state và zipcode. Đặt chúng cạnh nhau thì rất rõ là sẽ tạo thành một địa chỉ. Nhưng biến state có nghĩa gì nếu bạn thấy nó một mình trong một phương thức? Liệu bạn có hiểu ngay đó là một phần của một địa chỉ?
Bạn có thể thêm bối cảnh bằng cách sử dụng tiền tốt: addrFirstName, addrLastName, adddrState,… Ít nhất người đọc sẽ hiểu rằng những biến này là phần của một cấu trúc lớn hơn. Dĩ nhiên, giải pháp tốt hơn là tạo một lớp có tên là Address. Lúc đó thì thậm chí trình biên dịch cũng biết là những biến này thuộc một câu trúc lớn hơn.
Hãy làm theo những quy tắc này và xem liệu bạn có cải tiến được mã nguồn của mình dễ đọc hơn. Nếu bạn bảo trì mã nguồn của người khác, hãy dùng công cụ tái câu trúc để giúp giải quyết những vấn đề này. Nó sẽ trả hết vốn trong thời gian ngắn và tiếp tục cho lãi về lâu dài.
