Khi nào nên viết một tuyên bố trả lại rõ ràng trong Groovy?

21

Hiện tại tôi đang làm việc trong một dự án Groovy / Grails (mà tôi còn khá mới) và tôi tự hỏi liệu có nên bỏ qua returntừ khóa trong các phương pháp Groovy không. Theo như tôi biết, bạn phải chèn từ khóa một cách rõ ràng vào các mệnh đề bảo vệ, vậy người ta có nên sử dụng nó ở mọi nơi khác không? Theo tôi returntừ khóa bổ sung làm tăng khả năng đọc. Hay đó là thứ bạn chỉ cần làm quen? Kinh nghiệm của bạn với chủ đề đó là gì?

Vài ví dụ:

def foo(boolean bar) {
    // Not consistent
    if (bar) {
        return positiveBar()
    }
    negativeBar()
}

def foo2() {
    // Special Grails example
    def entitiy = new Entity(foo: 'Foo', bar: 'Bar')
    entity.save flush: true
    // Looks strange to me this way
    entity
}

coding-style groovy

— Roland Schneider
nguồn

Có một vấn đề tương tự ở Perl: một hàm trả về biểu thức được đánh giá cuối cùng trong trường hợp không có returncâu lệnh. Cá nhân, tôi luôn sử dụng rõ ràng return, nhưng tôi không biết Groovy.

— Keith Thompson

2

Cá nhân tôi muốn sử dụng ngầm return chỉ khi nó hoàn toàn rõ ràng. toStringlà một ví dụ điển hình: đó là giá trị một lớp và giá trị được tính toán rõ ràng là giá trị trả về. Nhưng một lần nữa, tôi đã không lập trình đủ Groovy để biết liệu điều đó có phù hợp với những gì cộng đồng lớn hơn nghĩ hay không.

— Joachim Sauer

7

Tôi chắc chắn sẽ thêm lợi nhuận, vì nó làm cho ý định rõ ràng hơn với bất kỳ người nào (bao gồm cả chính bạn), những người có thể đến và cập nhật / duy trì mã sau này.

Nếu không, nó có thể trông giống như một lỗi đánh máy.

Một điều khác là hãy nhớ khai báo các hàm / bao đóng được dự kiến sẽ trả về một khoảng trống là 'void' - một lần nữa để làm rõ hơn cho các nhà bảo trì trong tương lai những gì bạn đang cố gắng làm.

— adrianmcmenamin
nguồn

17

Rõ ràng là vua.

Làm những gì rõ ràng nhất cho các lập trình viên đồng bào phải đọc mã của bạn sau khi bạn viết nó.

— Robert Harvey
nguồn

8

Đây là một đối số để bỏ qua các câu lệnh return ( Nguồn ):

Một tính năng không phù hợp trong Groovy

Lý lịch

Tôi đã làm việc với Groovy một lúc, nhưng không thích một tính năng: lợi nhuận ngầm của biểu thức cuối cùng được đánh giá. Ví dụ:

def getFoo() {
  def foo = null
  if (something) {
    foo = new Foo()
  }
  foo // no 'return' necessary
}

Trong đoạn mã trên, tôi sẽ sử dụng return vì nó cảm thấy an toàn hơn với tôi. Tôi có xu hướng đồng ý với bài viết của Eric (liên quan đến lợi nhuận rõ ràng).

Mặc khải

Tôi hiểu ngay bây giờ và tất cả là nhờ các phương pháp thu thập nâng cao trong Groovy.

Hãy xem xét phương pháp thu thập. Nó biến đổi một danh sách bằng cách áp dụng một chức năng. Trong mã giả:

[ a, b, c, d] => [ f(a), f(b), f(c), f(d) ]

Với ý nghĩ đó, đây là một ví dụ khác:

class Composer {
  def name
  // def era, etc
}

def list = [ 'Bach', 'Beethoven', 'Brahms' ]

// the closure returns the new Composer object, as it is the last
// expression evaluated.

def composers = list.collect { item -> new Composer(name : item) }

assert 'Bach' == composers[0].name

Ý tưởng chỉ đơn giản là xây dựng một danh sách các đối tượng Trình soạn thảo từ danh sách các chuỗi. Như đã lưu ý trong bình luận, việc đóng cửa được chuyển để thu thập sử dụng lợi nhuận ngầm cho hiệu quả tuyệt vời. Có một lần, tôi sẽ mất 3-4 dòng để thể hiện ý tưởng đó.

Nhưng bây giờ, mã này không chỉ đơn giản là súc tích: nó thực sự thanh lịch. Rất gợi nhớ đến các ngôn ngữ khác như Python.

Tin nhắn mang về nhà

Có rất nhiều danh sách các tính năng Groovy tuyệt vời. Tuy nhiên, chúng tôi hiếm khi thấy "lợi nhuận ngầm" được liệt kê. Tôi là một fan hâm mộ: nó bôi trơn các bánh xe cho các tính năng khác.

Tôi nhận ra nó có sẵn bằng nhiều ngôn ngữ: Tôi chỉ chưa sử dụng nó trong Groovy. Tôi nghi ngờ trong một vài tuần tôi sẽ không thể sống mà không có nó.

— Chad
nguồn