Hàm một dòng chỉ được gọi một lần

Hãy xem xét một hàm không tham số ( chỉnh sửa: không nhất thiết) thực hiện một dòng mã duy nhất và chỉ được gọi một lần trong chương trình (mặc dù không thể không cần thiết lại trong tương lai).

Nó có thể thực hiện một truy vấn, kiểm tra một số giá trị, làm một cái gì đó liên quan đến regex ... bất cứ điều gì tối nghĩa hoặc "hacky".

Lý do đằng sau điều này sẽ là để tránh những đánh giá khó đọc:

if (getCondition()) {
    // do stuff
}

nơi getCondition()là hàm một dòng.

Câu hỏi của tôi chỉ đơn giản là: đây có phải là một thực hành tốt? Nó có vẻ ổn với tôi nhưng tôi không biết về lâu dài ...

Phụ thuộc vào một dòng. Nếu dòng có thể đọc và súc tích bằng chính nó, chức năng có thể không cần thiết. Ví dụ đơn giản:

void printNewLine() {
  System.out.println();
}

OTOH, nếu hàm đặt tên tốt cho một dòng mã chứa ví dụ: một biểu thức phức tạp, khó đọc, thì nó hoàn toàn hợp lý (với tôi). Ví dụ có sẵn (được chia thành nhiều dòng để dễ đọc ở đây):

boolean isTaxPayerEligibleForTaxRefund() {
  return taxPayer.isFemale() 
        && (taxPayer.getNumberOfChildren() > 2 
        || (taxPayer.getAge() > 50 && taxPayer.getEmployer().isNonProfit()));
}

Vâng, điều này có thể được sử dụng để đáp ứng thực tiễn tốt nhất. Ví dụ, tốt hơn là có một hàm được đặt tên rõ ràng thực hiện một số công việc, ngay cả khi nó chỉ dài một dòng, hơn là để dòng mã đó trong một hàm lớn hơn và cần một nhận xét một dòng giải thích những gì nó làm. Ngoài ra, các dòng mã lân cận sẽ thực hiện các tác vụ ở cùng mức độ trừu tượng. Một ví dụ sẽ là một cái gì đó như

startIgnition();
petrolFlag |= 0x006A;
engageChoke();

Trong trường hợp này, chắc chắn tốt hơn là chuyển đường giữa thành một hàm có tên hợp lý.

Tôi nghĩ rằng trong nhiều trường hợp, hàm như vậy là kiểu tốt, nhưng bạn có thể coi biến boolean cục bộ là thay thế trong trường hợp khi bạn không cần sử dụng điều kiện này ở đâu đó ở những nơi khác, ví dụ:

bool someConditionSatisfied = [complex expression];

Điều này sẽ đưa ra một gợi ý cho trình đọc mã và tiết kiệm từ việc giới thiệu một chức năng mới.

Ngoài câu trả lời của Peter , nếu điều kiện đó có thể cần được cập nhật tại một thời điểm nào đó trong tương lai, bằng cách đóng gói theo cách bạn đề xuất, bạn sẽ chỉ có một điểm chỉnh sửa duy nhất.

Theo ví dụ của Peter, nếu điều này

boolean isTaxPayerEligibleForTaxRefund() {
  return taxPayer.isFemale() 
        && (taxPayer.getNumberOfChildren() > 2 
        || (taxPayer.getAge() > 50 && taxPayer.getEmployer().isNonProfit()));
}

trở thành cái này

boolean isTaxPayerEligibleForTaxRefund() {
  return taxPayer.isMutant() 
        && (taxPayer.getNumberOfThumbs() > 2 
        || (taxPayer.getAge() > 123 && taxPayer.getEmployer().isXMan()));
}

Bạn thực hiện một chỉnh sửa duy nhất và nó được cập nhật toàn cầu. Bảo trì khôn ngoan, đây là một lợi thế.

Hiệu suất khôn ngoan, hầu hết các trình biên dịch tối ưu hóa sẽ loại bỏ lệnh gọi hàm và nội tuyến khối mã nhỏ. Tối ưu hóa một cái gì đó như thế này thực sự có thể thu nhỏ kích thước khối (bằng cách xóa các hướng dẫn cần thiết cho chức năng gọi, trả lại, v.v.) để thông thường an toàn ngay cả trong các điều kiện có thể ngăn chặn nội tuyến.

Ngoài khả năng đọc (hoặc bổ sung cho nó), điều này cho phép viết các hàm ở mức độ trừu tượng thích hợp.

Nó phụ thuộc. Đôi khi, tốt hơn là gói gọn một biểu thức trong một hàm / phương thức, ngay cả khi đó chỉ là một dòng. Nếu nó phức tạp để đọc hoặc bạn cần nó ở nhiều nơi, thì tôi coi đó là một thực hành tốt. Về lâu dài, việc bảo trì sẽ dễ dàng hơn, vì bạn đã giới thiệu một điểm thay đổi duy nhất và khả năng đọc tốt hơn .

Tuy nhiên, đôi khi nó chỉ là thứ bạn không cần. Khi biểu thức dễ đọc dù sao và / hoặc chỉ xuất hiện ở một nơi, thì đừng bao bọc nó.

Tôi nghĩ rằng nếu bạn chỉ có một vài trong số họ thì không sao nhưng vấn đề xuất hiện khi có rất nhiều trong số họ trong mã của bạn. Và khi trình biên dịch chạy hoặc bộ điều khiển (tùy thuộc vào ngôn ngữ bạn sử dụng) Nó sẽ chuyển đến chức năng đó trong bộ nhớ. Vì vậy, giả sử bạn có 3 người trong số họ Tôi không nghĩ máy tính sẽ nhận thấy nhưng nếu bạn bắt đầu có 100 trong số những điều nhỏ nhặt đó thì hệ thống phải đăng ký các chức năng trong bộ nhớ chỉ được gọi một lần và sau đó không bị phá hủy.

Gần đây tôi đã thực hiện điều này chính xác trong một ứng dụng mà tôi đã tái cấu trúc, để làm rõ ý nghĩa thực sự của mã nhận xét sans:

protected void PaymentButton_Click(object sender, EventArgs e)
    Func<bool> HaveError = () => lblCreditCardError.Text == string.Empty && lblDisclaimer.Text == string.Empty;

    CheckInputs();

    if(HaveError())
        return;

    ...
}

Di chuyển một dòng đó thành một phương thức có tên tốt giúp mã của bạn dễ đọc hơn. Nhiều người khác đã đề cập rằng ("mã tự ghi"). Ưu điểm khác của việc chuyển nó thành một phương thức là nó giúp cho việc kiểm tra đơn vị dễ dàng hơn. Khi nó được phân lập thành phương thức riêng và đơn vị được kiểm tra, bạn có thể chắc chắn rằng nếu / khi phát hiện ra lỗi, nó sẽ không nằm trong phương thức này.

Đã có rất nhiều câu trả lời hay, nhưng có một trường hợp đặc biệt đáng nói .

Nếu câu lệnh một dòng của bạn cần một nhận xét và bạn có thể xác định rõ ràng (có nghĩa là: tên) mục đích của nó, hãy xem xét trích xuất một hàm trong khi nâng cao nhận xét vào tài liệu API. Bằng cách này bạn thực hiện chức năng gọi dễ dàng nhanh hơn và dễ hiểu hơn.

Thật thú vị, điều tương tự có thể được thực hiện nếu hiện tại không có gì để làm, nhưng một nhận xét nhắc nhở về việc mở rộng cần thiết (trong tương lai rất gần ¹⁾ ), vì vậy,

def sophisticatedHello():
    # todo set up
    say("hello")
    # todo tear down

cũng có thể thay đổi thành này

def sophisticatedHello():
    setUp()
    say("hello")
    tearDown()

¹⁾ bạn nên thực sự chắc chắn về điều này (xem nguyên tắc YAGNI )

Nếu ngôn ngữ hỗ trợ nó, tôi thường sử dụng các hàm ẩn danh có nhãn để thực hiện việc này.

someCondition = lambda p: True if [complicated expression involving p] else False
#I explicitly write the function with a ternary to make it clear this is a a predicate
if (someCondition(p)):
    #do stuff...

IMHO đây là một sự thỏa hiệp tốt vì nó mang lại cho bạn lợi ích dễ đọc khi không có biểu thức phức tạp làm lộn xộn ifđiều kiện trong khi tránh làm lộn xộn không gian tên toàn cầu / gói với các nhãn nhỏ. Nó có thêm lợi ích là chức năng "định nghĩa" là đúng nơi nó được sử dụng giúp dễ dàng sửa đổi và đọc định nghĩa.

Nó không phải chỉ là chức năng vị ngữ. Tôi cũng thích đặt các nồi hơi lặp đi lặp lại trong các chức năng nhỏ như thế này (Nó hoạt động đặc biệt tốt cho việc tạo danh sách pythonic mà không làm lộn xộn cú pháp ngoặc). Ví dụ, ví dụ đơn giản hóa sau đây khi làm việc với PIL trong python

#goal - I have a list of PIL Image objects and I want them all as grayscale (uint8) numpy arrays
im_2_arr = lambda im: array(im.convert('L')) 
arr_list = [im_2_arr(image) for image in image_list]