Naming Tips In Programming

Chọn đúng tên có ý nghĩa tất cả. Gọi tên đúng cho mọi thứ giúp nó dễ hiểu dễ nắm bắt hơn, xóa tan đi nghi ngờ, tăng cường sự thấu hiểu, căng tràn sảng khoái và bạn sẽ trông hấp dẫn trong mắt các lập trình viên khác.

"When I use a word, it means just what I choose it to mean - neither more nor less."

Methods, Classes, Variables

• Do no name methods "ProcessData" or "SomethingManager"

  Những tên này không đem lại nhiều thông tin cũng như quá mơ hồ để hiểu chính xác chức năng của hàm này là gì. Nếu cảm thấy khó để đặt được một tên cụ thể cho nó điều đó có nghĩa lập trình viên cũng đang không hiểu rõ về code của mình, đơn giản hãy chia nhỏ ra thành những hàm nhỏ hơn và dễ hiểu hơn để đặt tên.

• If it's general, it better be generalized

  Một class có tên là FilterCriteria nhưng nó lại thực sự chỉ sử dụng cho mục đích lọc các files. Vậy tại sao nó không thể là FileFilterCriteria. Cho dù cả toàn bộ hệ thống chỉ làm việc với file đi nữa, FilterCriteria chỉ nên là tên của abstract class.

• Avoid discussing hard work

  Cân nhắc việc đặt tên những function thao tác trên một tập hợp là đặc tính của chính nó. Ví dụ như khi sử dụng validateUserCredentials hay powerUpStrength, cả 2 nghe thật nguy hiểm và có vẻ như chứa hàng tá công việc phải làm. Thay vào đó nếu sử dụng validateUser hay powerUp, cảm giác phần lớn công việc đã hoàn thành, người đọc lại cảm thấy thở phào nhẹ nhõm hơn cũng như code có thể dễ dàng viết lại hay sử dụng với thuộc tính khác chứ không bó buộc với Credentials hay Strength.

• Don't hide behind your names

  Giả sử chúng ta cần làm sạch chuỗi ký tự người dùng nhập vào bằng cách chuyển nó về UTF-8, xóa các kí tự invalid đi. Đừng nên gói tất cả vào một hàm Escape(), hãy chia ra thành toUTF8(), normalizeEntities() và EscapeQoute() nó khiến người đọc code nhanh chóng nắm bắt được các công việc phải làm hơn. Tuy nhiên nếu vẫn muốn tận dụng sự tiện lợi của việc sử dụng một hàm duy nhất, hãy chắc chắn nó là một cái tên không rõ ràng nhưng gợi nhớ đến một chuỗi công việc phải làm, như là SantizeInput()

• Consistency

  Sự thống nhất trong cách đặt tên là điều vô cùng quan trọng. Ví dụ bạn có 2 hàm countStudents() và getStudentNumber(), một sử dụng cho chủ thể trường học và một cho lớp học. Thật khó để nói là tên nào hợp lý hơn nhưng não của bạn sẽ tốn thêm một ô nhớ để lưu giữ một cái tên khác cho cùng một công việc. Vì thế hãy để những việc giống nhau có cùng một tên và đừng phát minh thêm ra một cái mới.

• Avoid superlatives

  SuperCollection, StunningPicture, AwesomePeople etc nếu bạn muốn lập trình với tất cả tình cảm, cảm xúc gửi gắm vào trong từng dòng code, điều này có thể chấp nhận được (?!)

• Use singular names for enumerations

  Enumerations/Enum là một tập tất cả các giá trị có thể của một thực thể ví dụ như tập giới tính của con người. Nó nên là humanGender thay vì humanGenders. Tuy nhiên không nên nhầm lẫn với tập các giá trị có thể của thực thể trong một không gian hoàn cảnh nào đó, ví dụ tất cả các thể loại sách của một hiệu sách nào đó lại nên được đặt là bookCategories.

• Don't use negative logic for your variable names

  Good: isHandsome, helpPeople, isGalance

  Bad: isNotHandsome, doNotHelpPeople, isNotGalance

  Đọc những mệnh đề khẳng định bao giờ cũng dễ hiểu hơn phủ định vì bạn không mất công tư duy thêm lần nữa. Nếu ai đó isNotHandSome hay để họ isUgly

• Use proper Hungarian notation when necessary

  Hungarian notation là cách đặt tên khá phổ biến trong đó tên của hàm hay biến đồng thời cũng chỉ ra kiểu giá trị hay ý định sử dụng. Nó được chia là 2 loại phổ biến là Systems Hungarian notation (intCounter, fWidth) và Apps Hungarian notation (usFirstName - unsafe user input, sFirstName - sanitize user input). Mặc dù vẫn còn nhiều ý kiến trái chiều quanh việc sử dụng Hungarian notation nhưng bạn nên tránh việc sử dụng Systems Hungarian notation vì nó là vô nghĩa và thay vào đó hãy sử dụng Apps Hungarian notation trong trường hợp cần thiết.

Databases

Database schemas chủ yếu hướng tới dữ liệu của model, do đó tên mà bạn chọn nên phù hợp với bối cảnh của domain thay vì sự thuận tiện của người lập trình

• Use pluralized names for table

  Good: users, students

  Bad: user, student

  Một bảng chứa rất nhiều bản ghi về một thực thể do đó nó nên là một danh từ ở dạng số nhiều trong khi model nên ở dạng số ít như User, Student.

• Use aux_ and meta_ for tables that contain derived data or housekeeping junk

  Giả sử mọi bảng đều chứa các dữ liệu thật, tuy nhiên nếu nó có chứa dữ liệu kiểu derived hay dữ liệu rác ví dụ như một bảng chứa dữ liệu các user record đã bị xóa, chúng ta nên thêm tiền tố vào trước chúng để phân biệt rõ ý nghĩa ví dụ h_users phân biệt với users

• Use a postfix to show the kind of key

  Có một vài ví dụ điển hình có thể áp dụng để đặt tên cho các thuộc tính của bảng với hậu tố xác định kiểu

  _id for surrogate identities (GUIDs, Identity/Sequence numbers). Ex: category_id, class_id

  _nbr for a string of digits that follows a rigorous standard (driver's license numbers, social-security numbers, etc.). Ex: license_nbr, phone_nbr

  _code for standardized codes (eg: Zip codes, ISO country codes). Ex: zip_code, country_code

  _cat for category names. Ex: book_cat, film_cat

  _class for subclassifications. Ex: file_class, diamond_class

  _type for less-formal class names, such as "motorcycle", "automobile", and "taxi" for driver's license types. Ex: contract_type, lottery_type

Things

• Name physical things what they are, not what they're doing

  Khi bạn cần gọi tên một sự vật có tính chật vật lý, hữu hình hay sử dụng đúng tên mô tả nó là cái gì thay vì nó làm cái gì hay có tác dụng gì.

  Good: accomodation, candy

  Bad: where_to_live, sweet_things

• Name logical things after what they're doing, not what they are

  Giả sử bạn có một bảng hướng dẫn tự động sắp xếp vị trí của các sản phẩm mới theo loại của chúng nhưng không có quy định nào nói rằng bạn không thể trộn lẫn các sản phẩm khác nhau trên cùng một kệ hàng. Và nếu đặt tên là shelf_types, mọi người nhìn vào và sẽ nghĩ rằng mình làm sai nếu xếp 2 sản phẩm khác loại và cùng 1 chỗ. Trong khi đó cái tên shelf_assignment_guides sẽ hợp lý hơn nhiều cũng như mô tả được chính xác chức năng của bảng là gì.

• Avoid the "Category" problem

  Tránh sử dụng category như là một tên của một thuộc tính vì bạn sẽ sớm nhận ra bạn sẽ cần theo dấu rất nhiều kiểu của category. Bạn rồi sẽ có "kind", "variant", "classification" và "subcategory" và bạn không còn ý tưởng "category" dùng làm gì nữa. Hãy sử dụng những danh từ phân loại cụ thể hơn, ví dụ như packaging_type, age_group, film_rating_type

Golden rule

Hãy dành vài phút để nghĩ về tên mà bạn sẽ sử dụng cho các biến của mình.

Nếu bạn cảm thấy có thể viết ra một cái tên ngay khi mà bạn bắt đầu thấy cần chúng trong code mà không cần phải suy nghĩ một giây nào, khá chắc là bạn đã chọn những tên chưa đủ tốt cho chúng.

Nhưng nếu bạn luôn luôn cố gắng và tự nhủ bản thân phải suy nghĩ tìm ra một tên thích hợp cho một variable nào đó ngay cả khi không cần sử dụng các quy tắc trên, tôi tin chắc rằng code của bạn sẽ dễ đọc và trong sáng hơn rất nhiều. Code cũng như đứa con tinh thần của người lập trình vậy, hãy cố gắng dành cho chúng những điều tốt đẹp nhất.