Nếu có một phương pháp

bool DoStuff() {
    try {
        // doing stuff...
        return true;
    }
    catch (SomeSpecificException ex) {
        return false;
    }
}

nó nên được gọi là IsStuffDone()?

Cả hai tên có thể bị người dùng hiểu sai: Nếu tên đó là DoStuff()lý do tại sao nó trả về một boolean? Nếu tên là IsStuffDone()không rõ liệu phương thức thực hiện một nhiệm vụ hay chỉ kiểm tra kết quả của nó.

Có một quy ước cho trường hợp này? Hoặc một cách tiếp cận khác, vì cách này được coi là thiếu sót? Ví dụ: trong các ngôn ngữ có tham số đầu ra, như C #, một biến trạng thái boolean có thể được truyền cho phương thức dưới dạng một và kiểu trả về của phương thức sẽ là void.

EDIT: Trong xử lý ngoại lệ vấn đề cụ thể của tôi không thể ủy thác trực tiếp cho người gọi, vì phương thức này là một phần của việc triển khai giao diện. Do đó, người gọi không thể bị buộc tội đối phó với tất cả các ngoại lệ của các triển khai khác nhau. Nó không quen thuộc với những ngoại lệ đó. Tuy nhiên, người gọi có thể xử lý một ngoại lệ tùy chỉnh StuffHasNotBeenDoneForSomeReasonExceptionnhư được đề xuất trong câu trả lời và nhận xét của npinti .

Trong .NET, bạn thường có các cặp phương thức trong đó một trong số chúng có thể đưa ra một ngoại lệ ( DoStuff) và phương thức kia trả về trạng thái Boolean và, khi thực hiện thành công, kết quả thực tế thông qua tham số out ( TryDoStuff).

(Microsoft gọi đây là "Mô hình phân tích thử" , vì có lẽ ví dụ nổi bật nhất cho nó là các TryParsephương thức của các kiểu nguyên thủy khác nhau.)

Nếu Trytiền tố không phổ biến trong ngôn ngữ của bạn, thì có lẽ bạn không nên sử dụng nó.

Điều gì nếu bạn chỉ đơn giản là ném ngoại lệ cho mã gọi?

Bằng cách này, bạn đang ủy thác việc xử lý ngoại lệ cho những người đã từng sử dụng mã của bạn. Điều gì sẽ xảy ra nếu trong tương lai bạn muốn làm như sau:

• Nếu không có ngoại lệ được ném, hãy hành động A
• Nếu (ví dụ) a FileNotFoundExceptionbị ném, hãy thực hiện hành động B
• Nếu có bất kỳ ngoại lệ nào khác được ném, hãy hành động C

Nếu bạn ném lại ngoại lệ của mình, thay đổi ở trên chỉ đơn giản là đòi hỏi phải thêm một catchkhối bổ sung . Nếu bạn để nguyên như vậy, bạn sẽ cần thay đổi phương thức và địa điểm mà phương thức được gọi, tùy thuộc vào độ phức tạp của dự án, có thể ở nhiều vị trí.

DoStuff() là đủ và giá trị trả về của hàm phải được ghi lại và bạn không cần đề cập đến nó trong tên hàm, tìm kiếm nhiều API có sẵn:

PHP

// this method update and return the number affected rows 
// called update instead of updateAndGetAffectedCount
$affected = $query->update(/* values */);

C-sắc nét

// Remove item from the List
// returns true if item is successfully removed; otherwise, false.
public bool Remove( T item )

Trong Java, API Collection xác định một phương thức add trả về boolean. Về cơ bản nó trả về việc add đã thay đổi bộ sưu tập. Vì vậy, đối với Listnó thường sẽ trả về true, vì mục này đã được thêm vào, trong khi đối với Setnó, nó có thể trả về false, nếu mục đó đã ở đó, vì Sets cho phép mỗi mục duy nhất nhiều nhất một lần.

Điều đó nói rằng, nếu bạn thêm một mục không được bộ sưu tập cho phép, ví dụ: giá trị null, thì add sẽ ném NullPointerExceptionthay vì trả về false.

Khi bạn áp dụng logic tương tự cho trường hợp của bạn, tại sao bạn cần trả về một boolean? Nếu đó là để che giấu một ngoại lệ, đừng. Chỉ cần ném ngoại lệ. Bằng cách đó bạn có thể thấy những gì đã sai. Nếu bạn cần một boolean, vì nó có thể chưa được thực hiện, vì một số lý do khác ngoài một ngoại lệ, hãy đặt tên cho phương thức DoStuff(), vì điều đó thể hiện hành vi. Nó làm công cụ.

Có thể thất bại vì những lý do khác nhau, Ngoại lệ, điều kiện bình thường, vì vậy sẽ sử dụng điều này:

boolean doStuff() - returns true when successful

Quan trọng là ghi lại ý nghĩa của boolean.

Tôi thường có các phương thức trả về một OperationResult(hoặc OperationResult<T>) và đặt thuộc IsSuccesstính một OperationResultcách thích hợp. Nếu phương thức 'thông thường' là void thì trả về OperationResult, nếu phương thức 'thông thường' trả về một đối tượng thì trả về OperationResult<T>và đặt thuộc Itemtính trên một OperationResultcách thích hợp. Tôi cũng đề nghị có các phương pháp OperationResultnhư .Failed(string reason)và .Succeeded(T item). OperationResultnhanh chóng trở thành một loại quen thuộc trong hệ thống của bạn và các nhà phát triển biết cách xử lý nó.

Nó thực sự phụ thuộc vào ngôn ngữ mà bạn đang sử dụng. Giống như đối với một số ngôn ngữ, có những quy ước và giao thức thực sự không tồn tại trong nhiều ngôn ngữ hoặc bất kỳ ngôn ngữ nào.

Ví dụ: trong ngôn ngữ Objective-C và tên phương thức SDK của iOS / Mac OS X thường đi theo dòng:

- (returndatatype) viewDidLoad {
- (returndatatype) isVisible {
- (returndatatype) appendMessage:datatype variablename with:datatype variablename {

Như bạn có thể thấy, có một phương thức có tên là viewDidLoad. Tôi thích sử dụng kiểu đặt tên này bất cứ khi nào tôi tạo các ứng dụng của riêng mình. Điều này có thể được sử dụng để kiểm tra nếu một cái gì đó được cho là xảy ra như bạn nói. Tôi tin rằng bạn đang suy nghĩ quá sâu về những gì bạn đặt tên cho phương pháp của mình. Hầu hết các phương thức trả về trạng thái của những gì chúng làm bất kể, lấy ví dụ:

Trong PHP, mysql_connect () sẽ trả về false nếu kết nối không thành công. Nó không nói nó sẽ làm, nhưng nó và tài liệu nói rằng nó làm như vậy nó không thể bị hiểu sai cho lập trình viên.

Tôi muốn đề nghị sử dụng tiền tố 'Thử'. Đây là một mô hình nổi tiếng cho các tình huống mà phương pháp có thể thành công hay không. Mẫu đặt tên này đã được Microsoft sử dụng trong .NET Framework (ví dụ: TryPudeInt).

Nhưng, có lẽ đây không phải là về đặt tên. Đó là về cách bạn thiết kế các tham số đầu vào / đầu ra của phương thức.

Ý tưởng của tôi là nếu một phương thức có giá trị trả về, thì mục đích của việc gọi phương thức đó là để có được giá trị trả về đó. Vì vậy, bạn nên tránh sử dụng loại trả về để chỉ trạng thái của một hoạt động.

Trong C #, tôi thích sử dụng tham số out. Sử dụng một ra tôi đang đánh dấu tham số là một tham số phụ. Đặc biệt là C # 6 sẽ hỗ trợ khai báo biến nội tuyến.

DoStuff(out var isStuffDone); // The out parameter name clearly states its purpose.
DoStuff(out var _); // I use _ for naming parameters that I am ignoring.

Tôi sẽ chọn một tên dựa trên vai trò chính của phương thức. Thực tế, phương thức đó trả về giá trị boolean không bắt buộc tiền tố 'Is'. Chúng ta hãy có một số mã Java, sử dụng tiền tố 'Is' khá mở rộng. Hãy nhìn vào java.io.File.delete(). Nó trả về boolean, nhưng nó không được gọi isFileDeleted(). Lý do là vai trò chính của metod là xóa một tập tin. Ai đó gọi phương thức này với ý định xóa một tập tin.

Boolean ở đó chỉ để kết hợp lại kết quả của công việc. Mặt khác, hãy xem java.util.Map.isEmpty(). Rõ ràng, bạn gọi một phương thức như vậy để tìm hiểu xem bộ sưu tập có trống không. Bạn không muốn bất cứ thứ gì được thực hiện. Bạn chỉ muốn tìm hiểu những gì hiện trạng.

Vì vậy, cá nhân, tôi chắc chắn sẽ gắn bó với DoStuff().

Đây là một vấn đề rất quan trọng đối với tôi. Nhiều lần khi tôi duy trì mã kế thừa, tôi vấp phải thứ mà tôi gọi là "phương pháp nói dối" cá nhân. Tên gợi ý hành động A, nhưng cơ thể thực hiện hành động B. Ví dụ kỳ lạ nhất là phương pháp getter thay đổi dữ liệu trong cơ sở dữ liệu.