Hướng dẫn đặt tên phương pháp súc tích có ý nghĩa


25

Gần đây tôi bắt đầu phát hành một dự án nguồn mở, trong khi tôi là người dùng duy nhất của thư viện tôi không quan tâm đến tên, nhưng tôi biết tôi muốn gán tên thông minh cho từng phương thức để dễ học hơn, nhưng tôi cũng cần sử dụng tên súc tích để họ cũng dễ viết.

Tôi đã suy nghĩ về một số hướng dẫn về việc đặt tên, tôi nhận thức được rất nhiều hướng dẫn chỉ quan tâm đến vỏ chữ cái hoặc một số ghi chú đơn giản. Ở đây, tôi đang tìm kiếm các hướng dẫn cho việc đặt tên có ý nghĩa nhưng ngắn gọn.

Ví dụ, đây có thể là một phần của hướng dẫn tôi đang tìm kiếm:

  • Sử dụng Thêm khi một mục hiện có sẽ được thêm vào mục tiêu, Sử dụng Tạo khi một mục mới đang được tạo và thêm vào mục tiêu.
  • Sử dụng Xóa khi một mục hiện có sẽ bị xóa khỏi mục tiêu, Sử dụng xóa khi một mục sẽ bị xóa vĩnh viễn.
  • Ghép nối các phương thức AddXXX với các phương thức RemoveXXX và Ghép các phương thức CreatXXX với các phương thức DeleteXXX, nhưng không trộn lẫn chúng.

Như các mẫu trên cho thấy, tôi muốn tìm một số tài liệu trực tuyến giúp tôi về phương pháp đặt tên và mục khác tuân theo ngữ pháp tiếng Anh và nghĩa của từ.

Hướng dẫn trên có thể trực quan cho người nói tiếng Anh bản địa, nhưng đối với tôi, tiếng Anh là ngôn ngữ thứ hai của tôi, tôi cần được nói về những điều như thế này.


Chào mừng đến với trang web! Bạn có thể thấy câu hỏi liên quan này hữu ích: lập trình
viên.stackexchange.com/

1
Tôi nghĩ phần ngắn gọn quan trọng hơn phần ý nghĩa, vì sơ đồ của bạn đã có ý nghĩa. Nếu bạn sẽ đi thêm một dặm nữa, hãy làm điều đó cho thống nhất.
yannis

7
Mô tả là quan trọng hơn ngắn gọn. Hầu hết hoàn thành đề nghị của IDE, vì vậy độ dài không phải là một trở ngại và tên mô tả dễ hiểu và dễ nhớ hơn.
Caleb

@AnnaLear Tôi đang hỏi điều gì đó khác nhau, Câu hỏi của tôi liên quan đến những điều như thuật ngữ được đề xuất để đặt tên hoặc ghi chú ngữ pháp có thể giúp người khác hiểu mục đích của phương pháp tốt hơn.
000

3
Đọc được là quan trọng hơn súc tích. Tất cả các IDE hiện đại đều có các phương tiện hoàn thành mã, do đó, giúp dễ dàng khám phá những gì một phương thức làm có giá trị hơn là làm cho nó dễ gõ hơn.

Câu trả lời:


34

Đặt tên. Một trong những điều khó nhất về phát triển phần mềm :)

Khi tôi đặt tên cho một cái gì đó, đây là tập hợp ưu tiên của tôi:

  • Thực hiện theo các thành ngữ của ngôn ngữ của tôi. Ruby thích dấu gạch dưới. Javascript thích trường hợp lạc đà. Bất cứ ngôn ngữ nào bạn tham gia là quy ước để tuân theo.
  • Tiết lộ ý định của API. Nó không phải là "send_http_data" mà là "post_twitter_status"
  • Tránh rò rỉ chi tiết thực hiện. Nói, tiền tố một biến với một loại.
  • Không sử dụng nhiều ký tự hơn mức cần thiết mà không vi phạm các nguyên tắc trước đó.

Rõ ràng đây là một cách tiếp cận khá đơn giản. Đặt tên là sắc thái.

Để nghiên cứu thêm, tôi khuyên bạn nên đọc The Art of Readable Code , vì nó cung cấp một số lời khuyên tuyệt vời, ngắn gọn về cách đặt tên phương thức. Đối với nhiều nghiên cứu hơn nữa, tôi không thể khuyên nhiều hơn về Clean Code của Bob Martin


2
+1 cho câu trả lời tốt và đề xuất Mã sạch. Tôi đánh giá cao cuốn sách này là tốt. Một điều nữa tôi muốn nói thêm, và đây là từ cuốn sách của Martin: "Tôi cũng muốn viết mã dễ dàng" với mức độ ưu tiên thấp hơn nhiều so với khả năng đọc mã. Rõ ràng, có một thứ gọi là một cái tên quá dài, nhưng tôi sẽ luôn nghiêng về những cái tên dài dễ đọc hơn những cái dễ viết. Ngoài ra, hầu hết các IDE hiện đại đều tự động hoàn thành.
DXM

3
Một ý tưởng quan trọng hơn từ cuốn sách của Robert Martin: Đối với các phương pháp - tên ngắn phạm vi dài, tên dài phạm vi ngắn. Đối với các biến, tên ngắn hạn phạm vi ngắn, tên dài phạm vi dài.
Patkos Csaba

"Mã sạch" là cuốn sách lớn nhất giúp tôi hiểu được tác động của khả năng đọc mã và liệt kê các thực tiễn tốt nhất mà tôi tuân theo thường xuyên
Paul

Một câu hỏi, tiết lộ ý định trong tên phương thức, nó không ảnh hưởng đến khả năng sử dụng lại phương thức? post_twitter_status làm cho nó quá cụ thể.
EresDev

Có và không. Phương thức cụ thể đó có thể ít được sử dụng lại, nhưng bạn luôn có thể trích xuất một phương thức với hành vi cốt lõi, chuyển nó sang một lớp chung hơn và để phương thức cũ làm "đường may". Bằng cách này nếu bạn cần tránh trùng lặp, bạn có thể không thay đổi giao diện.
Zee

7

Sự cám dỗ để mã hóa một phong cách hoặc quy ước để đặt tên trong một số trường hợp có thể dẫn đến những thói quen được coi là thực hành kém hiện nay, chẳng hạn như sử dụng Ký hiệu Hungary chẳng hạn. Câu trả lời đơn giản là quên đi quy ước đặt tên và phong cách như thể đó là một điều riêng biệt được xác định riêng biệt, và thay vào đó tập trung vào việc đặt tên mọi thứ trong hệ thống của bạn dựa trên những gì nó thực sự đại diện. Tên phương thức sẽ có xu hướng ngắn gọn một cách tự nhiên nếu bạn giới hạn chức năng của từng phương thức để nó chỉ thực hiện một điều duy nhất và nếu tên phương thức của bạn thực sự mô tả một điều mà phương thức đó phải làm.

Các biến, trường, lớp và tên tệp là một cái gì đó khác. Tôi đề nghị rằng nếu các tên biến trở nên quá dài, thì bạn đang cố gắng mô tả các mục này một cách quá chi tiết hoặc chúng đại diện cho một cái gì đó phức tạp nên được chia thành các phần nhỏ hơn hoặc có thể được mô tả một cách trừu tượng hơn cách thức.

Vào cuối ngày, bạn muốn tránh mã xấu xí với các tên chiếm toàn bộ một hàng, hoặc rất lố lăng để cướp đi giá trị của chúng.


6

Đối với tôi, việc tìm một cái tên hay cho một thứ gì đó luôn quay trở lại khi nghĩ về nó như một đối tượng phải chứng minh sự tồn tại của nó. Tự hỏi mình đi:

  • Lớp / phương thức / biến làm gì, nghĩa là mục đích rộng hơn của nó là gì và để làm gì?
  • Điều gì đặc biệt về mục đích của nó mà nó cần để giao tiếp, tức là phần thiết yếu mà cái tên cần phải có trong đó là gì?

Hầu hết các nhà phát triển sẽ đồng ý rằng khả năng đọc luôn là điều tối quan trọng khi nói đến việc đặt tên. Đừng chỉ viết mã để bạn biết ý của bạn trong khi bạn viết nó, hãy viết nó để ai đó nhìn vào mã lần đầu tiên tại một thời điểm nào đó trong tương lai biết ý của bạn mà không phải suy nghĩ quá nhiều. Bạn sẽ viết mã chỉ một lần, nhưng trong suốt vòng đời của nó, rất có thể nó sẽ phải được chỉnh sửa nhiều lần và đọc nhiều lần hơn nữa.

Mã phải được tự ghi lại, đó là, việc đặt tên của bạn sẽ làm cho nó rõ ràng những gì làm. Nếu bạn cần giải thích một dòng mã làm gì trong một nhận xét và đổi tên mọi thứ không cải thiện đủ, bạn nên nghiêm túc xem xét việc tái cấu trúc dòng đó thành một phương thức mới với một tên mô tả phù hợp, để đọc phương thức ban đầu, cuộc gọi phương thức mới mô tả những gì đang xảy ra. Đừng sợ có tên dài; tất nhiên bạn không nên viết tiểu thuyết bằng tên lớp / phương thức / biến, nhưng tôi muốn có một cái tên quá dài và mô tả hơn là quá ngắn và tôi cần phải tìm ra những gì nó làm bằng cách nhìn dưới mui xe. Ngoại trừ một số trường hợp ngoại lệ rõ ràng như tọa độ x / y và các từ viết tắt thường được sử dụng, tránh các tên và ký tự viết tắt. Gọi một cái gì đó "bkBtn" thay vì "backButton"

Nhiều như ngôn ngữ của bạn cho phép, làm cho mã của bạn đọc giống như một câu tiếng Anh. Đối tượng sử dụng danh từ, phương thức sử dụng động từ. Các phương thức Boolean thường bắt đầu bằng "là", nhưng có nhiều tùy chọn khác truyền đạt ý nghĩa thậm chí còn tốt hơn, tùy thuộc vào trường hợp sử dụng, chẳng hạn như "có thể", "nên" hoặc "không". Tất nhiên, không phải tất cả các ngôn ngữ đều có thể tốt như Smalltalk về điều này, nhưng một số biểu tượng thường được hiểu là một phần của câu. Hai công ước Smalltalk mà cá nhân tôi muốn đưa vào các ngôn ngữ khác càng nhiều càng tốt là tiền tố tên của các tham số vòng lặp với "mỗi" và các tham số phương thức tiền tố với bài viết "a" (hoặc "an" hoặc "some" cho các bộ sưu tập) . Đây có thể không phải là một tiêu chuẩn phổ biến trong Java và bất kỳ ai cũng được hoan nghênh bỏ qua bit này, nhưng tôi thấy rằng điều này giúp tăng cường khả năng đọc mã. Ví dụ (ví dụ trong Java):

public boolean shouldConsiderAbbreviating(List<String> someNames) {
  for (String eachName : someNames) {
    if (isTooLong(eachName)) {
      return true;
    }
  }
  return false;
}

Điều này có thể đọc được đối với những người chỉ cần một chút kiến ​​thức về Java như một thứ như thế này:

Để xác định xem bạn có nên xem xét viết tắt một danh sách một số tên (là các chuỗi) hay không, lặp lại một số tên và đối với mỗi tên, hãy xác định xem nó có quá dài không; nếu vậy, trở về true; Nếu không quá dài, trở lại false.

Đối chiếu mã trên chỉ với việc đặt tên đối số stringsvà biến vòng lặp string, đặc biệt là trong một phương thức phức tạp hơn. Bạn sẽ phải nhìn kỹ để thấy sự khác biệt thay vì việc sử dụng là rõ ràng từ một cái nhìn thoáng qua vào tên.


3

Tìm một cách đặt tên tốt luôn là một sự thỏa hiệp giữa nhiều yếu tố. Bạn sẽ không bao giờ hài lòng hoàn toàn.

Điều đó nói rằng, ngay cả khi ngôn ngữ mẹ đẻ của bạn không như vậy, hãy xem tiếng Anh là ngôn ngữ có mã thông báo ngôn ngữ lập trình được hình thành. Sử dụng cú pháp giống như tiếng Anh làm cho mã đọc "trôi chảy" hơn vì không có "quy tắc đọc bị hỏng" mỗi khi tìm thấy từ khóa.

Nói chung, xem xét những thứ như object.method(parameters)để phù hợp với một chương trình như thế nào subject.verb(complements).

Điểm mấu chốt, nếu bạn phải hỗ trợ lập trình chung, là chọn một bộ "động từ" tốt và nhất quán (đặc biệt là những động từ cần được sử dụng trong các thuật toán chung).

Về danh từ, các lớp nên được đặt tên cho những gì chúng are(theo khái niệm), trong khi các đối tượng cho những gì chúng are for.

Điều đó nói rằng, giữa list.add(component)component.add_to(list)thích đầu tiên. Nói chung, các động từ "chuyển tiếp chủ động" thể hiện tốt hơn các hành động tôn trọng các đối tác thụ động hoặc phản xạ của chúng. Trừ khi thiết kế hạn chế foce bạn.


2

Đừng lo lắng về độ dài của tên phương thức. Hãy chắc chắn rằng tên phương thức phản ánh rõ ràng những gì họ đang làm. Điều này là tối quan trọng đối với bất cứ điều gì khác. Nếu bạn cảm thấy tên phương thức quá dài, hãy sử dụng từ điển đồng nghĩa để tìm một từ ngắn hơn có nghĩa tương tự. Ví dụ sử dụng Findthay vì Retrieve.

Ngoài ra, điều quan trọng không kém là tên bạn chọn cho các lớp học của mình. Chúng cung cấp rất nhiều bối cảnh khi nhìn vào tên phương thức. Một chữ ký phương thức như vậy:

public User Find(int userId);

dễ hiểu hơn:

public Person Find(int personId);

bởi vì bối cảnh thu được từ tên lớp Usercho người lập trình biết rằng Find()để định vị một loại người cụ thể, người dùng hệ thống của bạn. Phiên bản sử dụng Personlớp không cung cấp cho bạn bất kỳ bối cảnh nào về lý do tại sao bạn thậm chí sẽ cần sử dụng phương thức này ngay từ đầu.


1

Nhìn vào cách những người khác trên nền tảng của bạn làm điều đó - một số người chơi lớn hơn thậm chí có thể có phong cách mã và hướng dẫn đặt tên.

Một số nền tảng thích các tên ngắn (ví dụ, trong API Win32 C _tcsstrlà chức năng tìm chuỗi trong chuỗi - không rõ ràng phải không?), Các nền tảng khác có thể dễ đọc theo hướng ngắn gọn (trong khung Cacao của Apple cho Objective-C , phương thức thay thế một chuỗi con trong một chuỗi bằng một chuỗi khác và trả về kết quả là một bản sao được gọi stringByReplacingOccurrencesOfString: withString:). Tôi thấy phần sau dễ hiểu hơn nhiều và chỉ khó viết hơn (đặc biệt là hoàn thành mã).

Vì bạn đọc mã thường xuyên hơn bạn viết nó (đôi khi đúng với các thư viện nguồn mở) và việc đọc khó hơn viết, tối ưu hóa cho việc đọc. Tối ưu hóa cho ngắn gọn chỉ cuối cùng, và chỉ mất càng nhiều càng tốt mà không làm loãng sự rõ ràng.


1
  1. Giả sử tiếng Anh, trừ khi mọi nhà phát triển từng làm việc với mã này sẽ nói cùng một ngôn ngữ không phải tiếng Anh.

  2. Nghiên cứu quy ước đặt tên thường được chấp nhận và phong cách. Nguyên tắc hướng dẫn của bạn nên được rõ ràng. Kiểu dáng khác nhau theo ngôn ngữ lập trình.

  3. Không có bất cứ điều gì bạn có thể làm với việc đặt tên sẽ giúp dễ hiểu mối quan hệ giữa các đối tượng khác nhau trong mã của bạn. Đối với điều đó, bạn vẫn cần bình luận và tài liệu bằng văn bản.


Ngay cả khi mọi nhà phát triển từng làm việc với mã sẽ nói tiếng Anh, vẫn sử dụng tiếng Anh ...!
Mvision

0
  1. Sử dụng tiền tố. Nếu một loạt các phương thức được sử dụng để làm một cái gì đó tương tự hoặc có thể được nhóm lại theo một cách nào đó, hãy đặt một tiền tố chung trước tên của chúng để hiển thị những gì các phương thức này có điểm chung.
  2. Không sử dụng chữ viết tắt không rõ ràng nếu bạn muốn người khác hiểu tên ngay lập tức (quan trọng trong việc đặt tên API)
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.