Kapan harus menulis pernyataan pengembalian eksplisit di Groovy?


21

Saat ini saya sedang mengerjakan proyek Groovy / Grails (yang saya cukup baru) dan saya bertanya-tanya apakah itu praktik yang baik untuk menghilangkan returnkata kunci dalam metode Groovy. Sejauh yang saya tahu Anda harus secara eksplisit memasukkan kata kunci yaitu untuk klausa penjaga, jadi haruskah seseorang menggunakannya juga di tempat lain? Menurut pendapat saya, returnkata kunci tambahan meningkatkan keterbacaan. Atau apakah itu sesuatu yang harus Anda terbiasa? Apa pengalaman Anda dengan topik itu?

Beberapa contoh:

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
}

Ada masalah serupa di Perl: fungsi mengembalikan ekspresi yang dievaluasi terakhir tanpa adanya returnpernyataan. Secara pribadi, saya selalu menggunakan yang eksplisit return, tetapi saya tidak tahu Groovy.
Keith Thompson

2
Secara pribadi saya akan menggunakan implisit return hanya ketika sudah jelas. toStringadalah contoh khas: ini adalah satu-liner dan nilai yang dihitung jelas merupakan nilai balik. Tapi sekali lagi, saya belum cukup memprogram Groovy untuk mengetahui apakah itu cocok dengan apa yang dipikirkan masyarakat luas.
Joachim Sauer

Jawaban:


7

Saya yakin akan menambahkan pengembalian, karena membuat niat menjadi lebih jelas bagi siapa pun (termasuk Anda) yang mungkin datang dan memperbarui / memelihara kode nanti.

Kalau tidak, itu mungkin terlihat seperti kesalahan mengetik.

Hal lain adalah mengingat untuk mendeklarasikan fungsi / penutupan yang diharapkan mengembalikan kekosongan sebagai 'kekosongan' - lagi untuk membuatnya lebih jelas bagi pengelola masa depan apa yang Anda coba lakukan.


17

Kejelasan adalah Raja.

Lakukan apa yang paling jelas bagi sesama programmer yang harus membaca kode Anda setelah Anda menulisnya.


8

Berikut argumen untuk menghilangkan pernyataan pengembalian ( Sumber ):

Fitur yang Dipertahankan dalam Groovy

Latar Belakang

Saya telah bekerja dengan Groovy untuk sementara, tetapi telah menolak satu fitur: pengembalian implisit dari ekspresi terakhir dievaluasi. Sebagai contoh:

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

Dalam kode di atas, saya akan menggunakan return karena merasa lebih aman bagi saya. Saya cenderung setuju dengan posting Eric (sehubungan dengan pengembalian eksplisit).

Wahyu

Saya mengerti sekarang, dan itu semua berkat metode pengumpulan yang ditingkatkan di Groovy.

Pertimbangkan metode pengumpulan. Itu mengubah daftar dengan menerapkan fungsi. Dalam pseudocode:

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

Dengan mengingat hal itu, inilah contoh lain:

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

Idenya adalah hanya untuk membangun daftar objek Komposer dari daftar string. Seperti disebutkan dalam komentar, penutupan yang disahkan untuk mengumpulkan menggunakan pengembalian implisit ke efek besar. Pada suatu waktu, saya akan mengambil 3-4 baris untuk mengekspresikan ide itu.

Tetapi sekarang, kode ini tidak hanya ringkas: benar-benar elegan. Sangat mengingatkan pada bahasa lain seperti Python.

Pesan Bawa Pulang

Ada banyak daftar fitur Groovy yang sangat baik. Namun kita jarang melihat 'pengembalian implisit' terdaftar. Saya seorang penggemar: itu melumasi roda untuk fitur lainnya.

Saya menyadari ini tersedia dalam banyak bahasa: Saya belum menggunakannya di Groovy. Saya curiga dalam beberapa minggu saya tidak akan bisa hidup tanpanya.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.