Tại sao việc sử dụng các liên từ trong tên phương thức là một quy ước đặt tên xấu? [đóng cửa]


12

Trong nhóm của tôi, chúng tôi làm việc chặt chẽ với một vài kiến ​​trúc sư phần mềm. Họ phê duyệt tất cả các quyết định thiết kế của các dự án của chúng tôi, thực hiện một số đánh giá mã, v.v.

Các dự án của chúng tôi chủ yếu bao gồm chức năng phụ trợ được triển khai trong PHP bằng cách sử dụng khung công tác Symfony 2. Vì vậy, về mặt cú pháp, mã, quy ước đặt tên và cấu trúc dự án trông gần giống với giao diện của Java (Symfony 2 khuyến khích cấu trúc như vậy). Tôi đang đề cập đến điều này bởi vì các quy ước dành riêng cho Java cũng được áp dụng trong trường hợp của chúng tôi (nếu có thể).

Gần đây, họ đề xuất một cái gì đó mà tôi thấy rất lạ: tất cả các phương thức nên có liên từ trong tên của họ getEntityOrNull, setValueOrExceptionv.v.

Một quy ước đặt tên như vậy cảm thấy rất sai đối với tôi, nhưng tôi không thể đưa ra bất kỳ lập luận cụ thể hoặc các bài báo / trang trực tuyến nào thách thức điều này.

Điều duy nhất tôi nghĩ ra là:

  • thông tin đó phải được trình bày trong các chú thích của phương thức, như @returnhoặc@throws
  • việc sử dụng các liên từ ("và", "hoặc" v.v.) trong các tên phương thức thường cho thấy Nguyên tắc Trách nhiệm duy nhất không được tôn trọng đúng mức

Một số lập luận cụ thể khác chống lại quy ước đặt tên này là gì?


nói chung, bạn không thể
gnat

5
the use of conjunctions ("and", "or" etc.) in method names usually suggest that the Single Responsibility Principle is not properly respectedĐây không phải là trường hợp cho các ví dụ bạn đã liệt kê, trong đó kết hợp được sử dụng để làm rõ cơ chế được sử dụng để xử lý các lỗi, không cho biết nó có thể làm điều này hay cách khác. Ngay cả hàm được xác định hẹp nhất cũng có thể có các điều kiện lỗi hợp pháp, ví dụ: xuất hiện một ngăn xếp trống.
Doval

4
Xem xét: (1) sử dụng "tùy chọn" thay vì "hoặc null". "GetOptionalEntity" nghe tốt hơn tai tôi so với "GetEntityOrNull". (2) thư viện lớp cơ sở .NET sử dụng quy ước rằng nếu bạn có hai phương thức chỉ khác nhau về những gì chúng ném, hãy đặt tên cho phương thức không thể ném "TryB nhớ". Ví dụ, Int32.TryParseInt32.Parse- cả hai phân tích một chuỗi thành một số nguyên, nhưng cái trước trả về Boolean cho thấy thành công và cái sau ném vào thất bại.
Eric Lippert

Tôi sẽ không sử dụng hậu tố cho biến thể ném, nhưng tôi sẽ sử dụng một hậu tố cho biến thể trả về null. Có thể là Try..., ...OrNull, ...OrDefault. @EricLippert Đó không phải là quy ước duy nhất trong .net. Xem xét Singleso với SingleOrDefault, rất gần với OrNullOP đề xuất.
CodeInChaos

Câu trả lời:


11

Có lẽ họ đang làm như vậy vì xung đột đặt tên. Tôi giả sử rằng bạn không thể có hai phương thức được đặt tên getEntity, một phương thức có thể đưa ra một ngoại lệ và một phương thức trả về null. Do đó, bạn phải đặt tên cho chúng phù hợp.

Tôi, đối với một người, không thích thực hành có nhiều cách gọi khác nhau cho cùng một phương thức trừ khi nó đang thực hiện một số thay đổi mà chỉ có lớp cụ thể đó có thể thực hiện.

Nói cách khác, nếu getValueOrNullchỉ đơn giản là gọi getValueOrException, nắm bắt ngoại lệ và trong trường hợp đó trở lại null, điều này có thể được thực hiện bởi người gọi. Nó kết thúc lớp học với các phương thức không thực sự đóng góp bất cứ điều gì hữu ích. Thay vào đó tôi thích getValue, và biết rằng nó ném ngoại lệ. Vẫn tốt hơn, tôi muốn biết rằng tất cả các phương thức đều có khả năng đưa ra ngoại lệ và nullthay vào đó không có phương thức nào trở lại để hành vi được thống nhất trong dự án của tôi, hoặc ngược lại, tất cả đều có khả năng quay lại nullvà biết rằng người gọi sẽ phải ném ngoại lệ nếu đó là mong muốn.

Tuy nhiên, cũng đúng là bạn không chịu trách nhiệm về điều đó. Lời khuyên của tôi là mang nó lên, nhưng đừng đổ mồ hôi những thứ nhỏ nhặt. Cuối cùng, trách nhiệm của những quy ước đặt tên như vậy rơi vào vai họ, bất kể họ có đưa ra lời khuyên của bạn hay không, và vì đó là lừa đảo của họ, tôi tin rằng đó là đặc quyền của họ khi nói không, theo quan điểm khiêm tốn của tôi.


Nếu bạn phải chọn chỉ một, tốt hơn là nên trả lại null(hoặc tốt hơn là loại Tùy chọn / Có thể) vì ném tương đối đắt. Viết một trình trợ giúp kiểm tra xem một giá trị không hợp lệ và ném không thêm nhiều chi phí. Tuy nhiên, khi bạn muốn phiên bản không ném, nuốt ngoại lệ sẽ không trả lại cho bạn hiệu suất mà bạn đã ném.
Doval

1
@Doval Điểm tốt, và có lẽ quan trọng hơn, ngoại lệ nên là ngoại lệ . Nếu bạn thường xuyên ném ngoại lệ, bạn không sử dụng chúng đúng. Chỉ có vấn đề với việc trả lại nullnullthực sự có thể là một khoản hoàn trả hợp lệ trong một số trường hợp và do đó bạn sẽ phải đi chệch khỏi định mức và ném ngoại lệ trong những trường hợp như vậy.
Neil

3

Mặc dù việc sử dụng các liên từ thường chỉ ra sự vi phạm SRP, nhưng trong trường hợp này, nó chỉ cho thấy giá trị trả về của kiểu dữ liệu đại số của một người nghèo có thể là một trong hai giá trị, hoặc là giá trị null"thành công".

Họ đang sử dụng một loại Ký hiệu Hungary để bù đắp cho những điểm yếu trong hệ thống loại, cụ thể là thiếu loại không có giá trị. Nói cách khác, không có cách nào để chỉ định trong @returnchú thích của bạn rằng hàm sẽ không bao giờ quay trở lại null, và ngược lại, không có cách nào để chỉ định trong @returnchú thích của bạn rằng hàm có thể trả về null.

Ngoài ra, tôi tin rằng @throwscác chú thích không bắt buộc trong php, vì vậy sự vắng mặt của chú thích không cho thấy sự vắng mặt của một ngoại lệ, mặc dù điều đó được giải quyết tốt hơn bằng cách bắt buộc chú thích trong hướng dẫn phong cách của bạn.

Với những hạn chế của ngôn ngữ bạn đang sử dụng, đó không phải là một phong cách hoàn toàn vô lý.


2

Trong mã của tôi, đôi khi tôi tạo các cặp phương thức với các tên như getEntity () và getEntityOrNull (). Tên làm cho hành vi dự kiến ​​rõ ràng. Nếu getEntity () không tìm thấy thực thể thì một ngoại lệ được đưa ra. getEntityOrNull () sẽ trả về null.

Bằng cách này, mã cuộc gọi trở nên rõ ràng hơn một chút. Nếu mã gọi phải có một thực thể thì getEntity sẽ thực hiện thủ thuật. Nếu thực thể là một số loại tùy chọn thì getEntityOrNull là phương thức được lựa chọn.

Điều tương tự có thể được thực hiện với một phương thức duy nhất nhưng sau đó chuyển một phần gánh nặng sang chương trình gọi. Bạn luôn cần kiểm tra null hoặc bạn cần một khối thử / bắt. Dù bằng cách nào, đó là mã bổ sung cần được sao chép mỗi lần phương thức được gọi.

Nếu các kiến ​​trúc sư của bạn không sử dụng các loại cặp phương thức này thì có, tôi sẽ đặt câu hỏi về sự cần thiết của hậu tố.

Chưa bao giờ thực sự thấy một phương thức setValueOrException. Không thể nghĩ ra một trường hợp sử dụng phổ biến tốt cho điều đó.

Bạn có thể xem xét hỏi các kiến ​​trúc sư tại sao. Những người tôi biết luôn vui mừng giải thích quyết định của họ. Thường trong chi tiết lớn (và đôi khi rất khó chịu).


Điều đó getEntity sẽ đưa ra một ngoại lệ đối với thất bại không rõ ràng đối với tôi, tôi sẽ mong đợi một NULL đơn giản.
Elise van Looij

1

Hai đối số của bạn là âm thanh. Nhưng nếu họ là những người chịu trách nhiệm quyết định quy ước đặt tên, hãy cố gắng đừng cảm thấy quá tệ về việc đó là điều bạn không đồng ý.

Trong khi bạn đang ở đó, bạn nên thuyết phục họ không sử dụng các phần "get" và "set" trừ khi các phương thức đó thực sự trực tiếp đặt hoặc lấy biến thành viên.

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.