Không nên dùng tiếng lóng
Nếu những cái tên là quá đặc trưng, thường chúng sẽ được ghi nhớ với người chia sẻ cảm nhận vui vẻ và chỉ những người này mới nhớ những câu chuyện đó. Liệu chúng ta có biết hàm được đặt tên HolyHandGrenade hỗ trợ làm gì không? Chắc chắn hàm này là một tên đặc trưng nhưng có lẽ trong trường hợp này nên đặt tên DeleteItems có thể sẽ tốt hơn.
Sự lựa chọn tường minh vẫn hơn là các giá trị giải trí. Việc đặt tên quá đặc trưng trong đoạn mã thường xuất hiện trong các trường hợp thân mật hoặc tiếng lóng. Ví dụ, đừng sử dụng tên whack() để giải nghĩa là ). Không nên dùng tên địa phương khi nói chuyện như eatMyShort() để giải nghĩa abort(). Hãy nói những gì bạn thấy có nghĩa. Sự có nghĩa ở đây chính là những điều bạn nói.
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.
Đâu là sự khác biện căn bản giữa DeviceManager và Protocol-Controller? Tại sao cả hai không mang tên controller hoặc manager? Cả hai có thực sự là Driver? Tên làm bạn nghĩ rằng đó hai đối tượng của hai loại rất khác nhau cũng như hai lớp khác nhau.
Một thuật ngữ nhất quán đem lại lợi ích rất lớn cho những ai sử dụng mã nguồn của bạn.
Không chơi chữ
Hãy tránh việc dùng một từ cho hai mục đích. Sử dụng một thuật ngữ cho hai ý tưởng khác nhau cơ bản là một trò chơi chữ.
Nếu bạn tuân thủ quy tắc “một từ một khái niệm”, thì bạn làm cho nhiều lớp có, ví dụ, một phương thức add. Không quan trọng giá trị trả về hoặc tham số đầu vào nhiều như thế nào, nhưng những phương thức add có ý nghĩa tương đương.
Tuy nhiên bạn nên cân nhắc việc dùng từ add vì lý do “nhất quán” khi bạn thực sự không thêm vào theo cùng nghĩa. Giả sử rằng chúng ta có phương thức add ở nhiều lớp, là tạo một giá trị mới bằng cách thêm vào hoặc nối hai giá trị có sắn. Bây giờ chúng ta viết một lớp mới mà có phương thức để cho một tham số vào một tập. Chúng ta có nên gọi nó là add? Có vẻ sẽ là nhất quán bởi chúng ta đã có nhiều phương thức tên là add, nhưng trong trường hợp này thì ý nghĩa là khác, bởi thế chúng ta nên dùng tên là insert hoặc append thì tốt hơn. Nếu gọi tên phương thức mới này là add thì đó là một trò chơi chữ.
Mục đích của chúng tôi, như những tác giả, là làm cho mã nguồn nguồn dễ hiểu nhất có thể. Chúng tôi muốn mã nguồn của mình có thể lướt nhanh, chứ không phải một nghiên cứ nặng nề. Chúng tôi muốn dùng mẫu bìa giấy phổ biến nơi tác giả có trách nhiệm tự làm rõ chứ không phải mẫu hàn lâm nơi công việc của trường học là đào sâu ý nghĩa.
Dùng tên của miền giải pháp
Nên nhớ rằng những người đọc mã của bạn là lập trình viên. Nên hãy dùng những thuật ngữ của khoa học máy tính, tên trong giải thuật, tên mẫu thiết kế, tên toán học, v.v. Sẽ là không hay lắm nếu mọi tên đều là của miền nghiệp vụ bởi chúng ta không muốn những đồng nghiệp của mình phải chạy và ép hỏi khách hàng ý nghĩa của mỗi tên khi họ biết khái niệm đó bằng tên khác.
Tên accountVisitor có ý nghĩa rất rõ ràng với lập trình viên đã biết mẫu thiết kế VISITOR. Có lập trình viên nào không biết JobQueue nghĩa là gì? Có rất nhiều thứ kỹ thuật mà lập trình viên phải biết. Việc chọn những tên kỹ thuật cho những thứ này thường là hợp lý nhất.
Dùng tên miền nghiệp vụ
Khi bạn đang làm với những thứ không phải của lập trình viên (“programmer-eese”), hãy sử dụng tên nghiệp vụ. Ít nhất lập trình viên bảo trì mã của bạn có thể hỏi chuyên gia nghiệp vụ về nghĩa của nó.
Tách những khái niệm nghiệp vụ và giải pháp là một phần của việc của một lập trình viên và thiết kế tốt. Mã mà cần phải quan tâm tới những khái niệm nghiệp vụ nên mang tên của nghiệp vụ.
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, v.v. Í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 xem phương thức ở mã dẫn 2-1. Liệu những biến này cần bối cảnh có ý nghĩa hơn? Tên của phương thức chỉ cung cấp một phần của bối cảnh; thuật toán cung cấp phần còn lại. Một khi bạn đọc hết phương thức, bạn thấy ba biến number, verb và pluralModifier là phần của thông báo “guess statistics”. Thật không may là chúng ta phải phỏng đoán bối cảnh. Lần đầu khi bạn nhìn phương thức, nghĩa của những biến này là không rõ ràng.
Mã dẫn 2-1: Biến trong bối cảnh không rõ ràng.
Phương thức hơi dài và biến được dùng từ đầu tới cuối. Để chia hàm ra thành nhỏ hơn, chúng ta cần tạo lớp GuessStatisticsMessage và để ba biến này thành thuộc tính của lớp này. Điều này tạo ra một bối cảnh rõ ràng cho cả ba biến. Chúng rõ ràng là phần của GuessStatisticsMessage. Sự cải thiện về bối cảnh này cũng cho phép thuật toán rõ ràng hơn bằng cách chia nhỏ thành những hàm nhỏ hơn (Xem mã dẫn 2-2).
Mã dẫn 2-2: Biến có bối cảnh.
Đừng thêm những bối cảnh vô căn cứ
Trong ứng dụng tưởng tượng có tên “Gas Station Deluxe”, việc thêm tiền tố GSD vào tên các lớp là một ý tưởng tồi. Thành thật mà nói, bạn đang làm việc chống lại công cụ của chính mình. Khi bạn gõ G và nhấn phím để hoàn thành, thì bạn nhận được một danh sách rất dài các lớp trong hệ thống. Đó là việc làm khôn ngoan? Tại sao lại làm khó cho việc IDE giúp bạn?
Tương tự, khi bạn tạo lớp MailingAddress trong mô-đun kế toán (accounting) của GDS, bạn đặt tên lớp là GSDAccountAddress. Sau đó, bạn cần một địa chỉ thư cho ứng dụng danh bạ khách hàng. Bạn có sử dụng GSDAccountAddress? Liệu đó có phải là một tên đúng? Mười trong 17 ký tự là thừa và không có ý nghĩa.
Tên ngắn thường tốt hơn tên dài, nếu chúng rõ ràng. Việc không thêm bối cảnh là cần thiết.
accountAddress và customerAddress là tên tốt cho những thể hiện của lớp Address, nhưng lại là tên lớp tồi. Address là tên lớp tốt. Nếu tôi cần phân biệt giữa địa chỉ MAC, địa chỉ cổng và địa chỉ Web, thì tôi nên xem xét PostalAddress, MAC và URI. Những tên này chính xác hơn.
Lời cuối
Việc đặt tên khó bởi nó yêu cầu kỹ năng mô tả tốt và một nền văn hóa chia sẻ. Đó là việc dạy hơn là vấn đề kỹ thuật, kinh doanh hoặc quản lý. Kết quả là, nhiều người trong lĩnh vực này không học để làm rất tốt.
Mọi người thường sợ việc đổi tên bởi họ lo lắng là một số nhà phát triển khác sẽ đánh giá. Chúng tôi không khuyến khích sự sợ hãi này và thực tế thì chúng ta được mang ơn khi đổi tên (theo hướng tốt hơn). Chúng ta sử dụng công cụ hiện đại để giải quyết những tiểu tiết để từ đó có thể tập trung vào liệu việc đoạn mã có giống như đoạn và câu không, hoặc ít nhất cũng giống như bảng và cấu trúc dữ liệu (Không phải lúc nào một câu cũng là cách tốt nhất để hiển thị dữ liệu). Có thể bạn làm ai đó ngạc nhiên khi đổi tên, giống như những cải tiến mã nguồn khác. Đừng để nó cản đường bạ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.
Techtalk via tạp chí lập trình
