Kapan nama metode Java terlalu panjang? [Tutup]


173

Dalam minggu-minggu terakhir saya telah melihat beberapa orang menggunakan nama yang sangat panjang untuk Metode atau Kelas (50 karakter), ini biasanya di bawah premis bahwa itu meningkatkan keterbacaan, pendapat saya adalah bahwa nama panjang seperti ini adalah indikator bahwa kita mencoba melakukan banyak atau terlalu banyak dalam kelas metode jika kita membutuhkan nama yang panjang, namun saya ingin tahu apa yang kalian pikirkan tentang itu.

Contohnya adalah:

getNumberOfSkinCareEligibleItemsWithinTransaction

19
YA itu adalah "bau kode" ... c2.com/cgi/wiki?LongMethodSmell
Dan Rosenstark

23
Ketika itu> 666 karakter lama maka Anda tahu Anda memiliki masalah.
Thomas Eding

8
@yar dalam contoh Anda, kebalikan dari "Metode Panjang" adalah "Metode Pendek" yang dianggap sebagai hal yang baik. Jadi itu jelas tidak merujuk pada nama metode; itu mengacu pada baris kode (atau yang serupa). misalnya, f()adalah fungsi yang sangat singkat, tetapi tentu saja ini bukan praktik yang baik ... dan sesuatu yang harus Anda sampaikan kepada beberapa matematikawan pemrograman di luar sana :)
sfussenegger

3
@ sfussenegger, itu benar. Tapi saya bertaruh pada korelasi antara panjang nama-metode dan panjang metode. f()mungkin bukan fungsi yang hebat, tapi $()orang itu seperti rockstar di dunia metode Javascript.
Dan Rosenstark

7
@yar, tautan yang Anda berikan merujuk pada panjang metode dalam baris, bukan panjang nama metode .
Thorbjørn Ravn Andersen

Jawaban:


398

Nama dalam Java, atau bahasa lain, terlalu panjang ketika ada nama pendek yang sama-sama menyampaikan perilaku metode.


65
Secara matematis elegan.
Ricket

304
Jadi, misalnya, boolean doesShorterNameExistThatEquallyConvaysTheBehaviorOfTheMethod(String s)harus di refactored ke boolean isTooLong(String s).
z5h

6
Saya tidak terlalu setuju, karena Anda tidak hanya ingin menyampaikan perilaku tetapi juga menjaga konvensi proyek dan bahasa. Jadi dengan Python Anda mungkin mengatakan eligible_items_cnttetapi di Jawa biasanya Anda katakan getEligibleItemsCount.
flybywire

17
@flybywire: Konvensi apa pun yang membuat Anda menulis nama yang terlalu panjang adalah manfaat yang meragukan.
MAK

20
@MAK @ S.Banyak apa tentang getLength()vs length()? Saya benar-benar suka melihat pelengkapan otomatis setelah mengetikkan 'get' atau 'set' - jadi saya lebih suka convetion daripada conciseness dalam kasus ini.
sfussenegger

202

Beberapa teknik untuk mengurangi panjang nama metode:

  1. Jika seluruh program Anda, atau kelas, atau modul adalah tentang 'item perawatan kulit' Anda dapat membatalkan perawatan kulit. Sebagai contoh, jika kelas Anda dipanggil SkinCareUtils, itu membawa Anda kegetNumberOfEligibleItemsWithinTransaction

  2. Anda dapat mengubah dalam ke dalam ,getNumberOfEligibleItemsInTransaction

  3. Anda dapat mengubah Transaksi ke Tx, yang membuat Anda melakukannya getNumberOfEligibleItemsInTx.

  4. Atau jika metode menerima param tipe TransactionAnda dapat menjatuhkan InTx sama sekali:getNumberOfEligibleItems

  5. Anda mengubah angkaDari hitungan: getEligibleItemsCount

Nah, itu sangat masuk akal. Dan itu 60% lebih pendek.


11
selain itu, 5) akan menempatkan getEligibleItems()dan di getEligibleItemsCount()samping satu sama lain dalam daftar yang diurutkan berdasarkan abjad (mis. pelengkapan otomatis atau javadoc)
sfussenegger

4
Dan seperti biasanya benar, nama yang lebih pendek cocok dengan aturan haiku.
sal

2
@mercator Menggunakan konvensi standar seperti getEligibleItems over countEligibleItems mengurangi kemungkinan ambiguitas dalam pernyataan. Semakin tidak ambigu untuk apa metode yang seharusnya dilakukan meningkatkan keterbacaan. Tanpa melihat lebih jauh ke dalam metode metode yang "menghitung" kurang jelas dari apa metode yang "mendapat" menyelesaikan dalam jangka panjang.
Bill

53
Saya tidak suka abbr seperti Tx, Cnt, grph, dan seterusnya ... (btw, Txadalah singkatan dari "Transmission" atau "Transmitter")
Meinersbur

14
Ya, saya setuju dengan Anda sampai Anda memutuskan untuk menggunakan "Tx".
Ponkadoodle

183

Hanya untuk perubahan, jawaban non-subyektif: 65536 karakter.

A.java:1: Representasi UTF8 untuk string "xxxxxxxxxxxxxxxxxxxx ..." terlalu panjang untuk kumpulan konstan

;-)


4
ya itu terlalu lama ketika JVM tidak bisa mengatasinya no mo :)
Anurag

35
1 untuk THE jawaban literal.
sal

37
Secara teknis, spesifikasi bahasa Java tidak memiliki batas atas untuk panjang pengenal. Ini adalah batasan implementasi JVM Anda. Bersulang!
uckelman

13
Kompiler Sun tampaknya tidak sesuai dengan spesifikasi. java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.8 mengatakan: "Identifier adalah urutan panjang yang tidak terbatas ..."
Michael Myers

6
Spesifikasi JVM memang memiliki batas atas, seperti yang ditunjukkan pesan kesalahan. Representasi konstanta utf8 terbatas pada 2 ^ 16 byte yang ditentukan di sini . Nama kelas dan nama metode harus disimpan sebagai utf8 di pool konstan.
thejoshwolfe

42

Saya setuju dengan semua orang: nama metode tidak boleh terlalu panjang. Saya ingin menambahkan satu pengecualian:

Namun, nama metode uji JUnit bisa panjang dan harus menyerupai kalimat.

Mengapa?

  • Karena mereka tidak dipanggil kode lain.
  • Karena mereka digunakan sebagai nama uji.
  • Karena mereka kemudian dapat ditulis sebagai kalimat yang menggambarkan persyaratan. (Misalnya, menggunakan AgileDox )

Contoh:

    @Test
    public void testDialogClosesDownWhenTheRedButtonIsPressedTwice() {
        ...
    }

Lihat " Desain Berbasis Perilaku " untuk info lebih lanjut tentang ide ini.


5
+1 Saya setuju dan itu juga apa yang saya lakukan, meskipun metode JUnit 4 tidak diperlukan untuk memulai testlagi, ini juga membuka kemungkinan untuk menggunakan should: seperti dialogShouldCloseWhenTheRedButtonIsPressedTwice(). Atau Anda dapat menghubungi kelas uji DialogShoulddan kemudian metode closeWhenTheRedButtonIsPressedTwice(), sehingga untuk membacanya bersama-sama: DialogShould.closeWhenTheRedButtonIsPressedTwice().
stivlo

Sementara saya setuju, saya juga menyarankan bahwa terlalu lama kalimat mungkin menyarankan tes yang terlalu banyak!
Brian Agnew

17

Konteks "... Dalam Transaksi" harus jelas. Itulah tujuan dari orientasi objek.

Metode ini adalah bagian dari kelas. Jika kelas tidak berarti "Transaksi" - dan jika itu tidak menyelamatkan Anda dari keharusan mengatakan "Dalam Transaksi" sepanjang waktu, maka Anda punya masalah.


2
Bisa mengambil semacam parameter transaksi juga
willcodejavaforfood

3
Seperti yang Anda ketahui dari jawaban skor terbaik di atas, pilih kesederhanaan pedalaman alih-alih saran OO. +1
Dan Rosenstark

@yar Orang-orang tidak pernah salah.
CurtainDog

12

Saya cenderung menggunakan aturan haiku untuk nama:

 Seven syllable class names 
 five for variables
 seven for method and other names

Ini adalah aturan praktis untuk nama maksimal. Saya melanggar ini hanya ketika itu meningkatkan keterbacaan. Sesuatu seperti recalculateMortgageInterest (currentRate, quoteSet ...) lebih baik daripada recalculateMortgageInterestRate atau recalculateMortgageInterestRateFromSet karena fakta bahwa itu melibatkan harga dan seperangkat kutipan harus cukup jelas dari dokumen yang disematkan seperti javadoc atau yang setara dengan .NET.

CATATAN: Bukan haiku asli, karena ini adalah 7-5-7 daripada 5-7-5. Tapi saya masih lebih suka menyebutnya haiku.


13
Kelas mendapat tujuh, variabel kurang dari lima, tujuh sisanya
James

8
"variabel paling banyak lima" (kurang dari lima tidak akurat)
Jason S

Nama yang lebih kecil dapat menyebabkan keterbacaan kode yang lebih rendah.
Deniss M.

10

Java memiliki budaya mendorong nama-nama panjang, mungkin karena IDE dilengkapi dengan pelengkapan otomatis yang baik.

Situs ini mengatakan bahwa nama kelas terpanjang di JRE InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedStateadalah 92 karakter.

Adapun nama metode terpanjang saya telah menemukan ini supportsDataDefinitionAndDataManipulationTransactions, yaitu 52 karakter.


20
Sepertinya kelas itu dinamai oleh orang-orang penamaan yang disewa oleh Departemen Redundancy Deparment untuk menyebutkan hal-hal di Departemen Redundancy Department.
Michael Madsen

1
@MichaelMadsen: Apakah ini benar-benar berlebihan, atau itu menggambarkan sebuah frame yang bersarang di dalam frame lain?
endolith

PEP-8 ingin kata dengan nama kelas itu.
Mateen Ulhaq

9

Jangan pernah menggunakan kata yang panjang ketika yang kecil akan dilakukan.

Saya tidak berpikir tesis Anda tentang "panjang nama metode sebanding dengan panjang metode" benar-benar menahan air.

Ambil contoh yang Anda berikan: "getNumberOfSkinCareEligibleItemsWithinTransaction". Bagi saya itu terdengar seperti hanya melakukan satu hal: menghitung jumlah item dalam transaksi yang termasuk dalam kategori tertentu. Tentu saja saya tidak bisa menilai tanpa melihat kode sebenarnya untuk metode ini, tetapi itu kedengarannya seperti metode yang baik bagi saya.

Di sisi lain, saya telah melihat banyak metode dengan nama yang sangat pendek dan ringkas yang dapat melakukan banyak pekerjaan, seperti "processSale" atau "doStuff" yang populer.

Saya pikir itu akan sulit untuk memberikan aturan yang keras dan cepat tentang panjang nama metode, tetapi tujuannya harus: cukup lama untuk menyampaikan apa fungsi tidak, cukup pendek untuk dibaca. Dalam contoh ini, saya pikir "getSkinCareCount" mungkin sudah cukup. Pertanyaannya adalah apa yang perlu Anda bedakan. Jika Anda memiliki satu fungsi yang menghitung item yang memenuhi syarat perawatan kulit dalam transaksi dan lainnya yang menghitung item yang memenuhi syarat perawatan kulit dalam hal lain, maka "dalam Transaksi" menambah nilai. Tetapi jika itu tidak berarti apa-apa untuk berbicara tentang barang-barang seperti itu di luar transaksi, maka tidak ada gunanya mengacaukan nama dengan informasi yang berlebihan.

Dua, saya pikir itu sangat tidak realistis untuk menganggap bahwa nama dengan panjang yang dapat diatur akan memberi tahu Anda dengan tepat apa fungsi dari semua kecuali kasus yang paling sepele. Tujuan realistis adalah membuat nama yang memberi petunjuk kepada pembaca, dan itu bisa diingat kemudian. Seperti, jika saya mencoba menemukan kode yang menghitung berapa banyak antimateri yang perlu kita konsumsi untuk mencapai kecepatan warp, jika saya melihat nama fungsi dan melihat "calibrateTransporter", "firePhasers", dan "calcAntimatterBurn", cukup jelas bahwa dua yang pertama bukan tapi yang ketiga mungkin. Jika saya memeriksa dan menemukan bahwa itu memang yang saya cari, akan mudah diingat bahwa ketika saya kembali besok untuk menyelesaikan masalah ini lagi. Cukup bagus.

Tiga, nama panjang yang mirip lebih membingungkan daripada nama pendek. Jika saya memiliki dua fungsi yang disebut "calcSalesmanPay" dan "calcGeekPay", saya dapat membuat tebakan yang bagus yang sekilas pandang. Tetapi jika mereka disebut "menghitungMonthlyCheckAmountForSalesmanForExportToAccountingSystemAndReconciliation" dan "menghitungMonthlyCheckAmountForProgrammersForExportToAccountingSystemAndRconcination", saya harus mempelajari nama untuk melihat mana yang mana. Informasi tambahan dalam nama mungkin kontraproduktif dalam kasus tersebut. Ternyata pemikiran setengah detik menjadi pemikiran 30 detik.


+1 untuk jawaban buruk yang dideritanya.
Dan Rosenstark

7

Rancang antarmuka Anda seperti yang Anda inginkan, dan sesuaikan implementasi.

Sebagai contoh, mungkin saya akan menuliskannya sebagai

getTransaction().getItems(SKIN_CARE).getEligible().size()

atau dengan stream Java 8:

getTransaction().getItems().stream()
    .filter(item -> item.getType() == SKIN_CARE)
    .filter(item -> item.isEligible())
    .count();

6

Aturan saya adalah sebagai berikut: jika sebuah nama sangat panjang sehingga harus muncul pada baris sendiri, maka itu terlalu panjang. (Dalam praktiknya, ini berarti saya jarang di atas 20 karakter.)

Ini didasarkan pada penelitian yang menunjukkan bahwa jumlah garis kode vertikal yang terlihat berkorelasi positif dengan kecepatan / efektivitas pengkodean. Jika nama kelas / metode mulai menyakitinya secara signifikan, nama itu terlalu panjang.

Tambahkan komentar di mana metode / kelas dideklarasikan dan biarkan IDE membawa Anda ke sana jika Anda ingin deskripsi panjang untuk apa itu.


Saya suka aturan seperti ini. Selama Anda ingat bahwa Anda / tim Anda mengarangnya secara acak, semuanya baik-baik saja. Di sisi lain, saya tidak dapat memperbaiki ini karena "penelitian menunjukkan" benar-benar memerlukan tautan ke penelitian itu, atau sesuatu tentang itu ...
Dan Rosenstark

5

Panjang metode itu sendiri mungkin merupakan indikator yang lebih baik untuk melakukan terlalu banyak, dan bahkan itu hanya memberi Anda ide kasar. Anda harus berusaha untuk keringkasan, tetapi deskripsi lebih penting. Jika Anda tidak dapat menyampaikan arti yang sama dalam nama yang lebih pendek, maka nama itu sendiri mungkin baik-baik saja.


3

Ketika Anda akan menulis nama metode lain kali, pikirkan saja kutipan di bawah ini

"The man who is going to maintain your code is a phyco who knows where you stay"

13
Untung dia hanya rumput laut dan bukan 'psiko'
StingyJack

2

Nama metode itu pasti terlalu panjang. Pikiranku cenderung mengembara ketika aku membaca nama metode sebesar itu. Ini seperti membaca kalimat tanpa spasi.

Secara pribadi, saya lebih suka kata-kata sesedikit mungkin dalam metode. Anda terbantu jika paket dan nama kelas dapat menyampaikan makna. Jika tanggung jawab kelas sangat singkat , tidak perlu nama metode raksasa. Saya ingin tahu mengapa "Transaksi Dalam" di sana.

"getNumberOfSkinCareEligibleItemsWithinTransaction" dapat menjadi:

com.mycompany.app.product.SkinCareQuery.getNumEligibleItems ();

Kemudian ketika digunakan, metode ini dapat terlihat seperti "query.getNumEligibleItems ()"


2

Nama variabel terlalu panjang ketika nama yang lebih pendek akan memungkinkan pembacaan kode yang lebih baik atas seluruh program, atau bagian penting dari program.

Jika nama yang lebih panjang memungkinkan Anda untuk menyampaikan lebih banyak informasi tentang suatu nilai. Namun, jika sebuah nama terlalu panjang, itu akan mengacaukan kode dan mengurangi kemampuan untuk memahami sisa kode. Ini biasanya terjadi dengan menyebabkan garis membungkus dan mendorong baris kode lain dari halaman.

Caranya adalah menentukan mana yang akan menawarkan keterbacaan yang lebih baik. Jika variabel digunakan sering atau beberapa kali dalam ruang yang singkat, mungkin lebih baik untuk memberikannya nama pendek dan menggunakan komentar yang mengklarifikasi. Pembaca dapat merujuk kembali ke komentar dengan mudah. Jika variabel sering digunakan di seluruh program, sering sebagai parameter atau dalam operasi rumit lainnya, mungkin yang terbaik adalah memotong nama, atau menggunakan akronim sebagai pengingat kepada pembaca. Mereka selalu bisa merujuk komentar dengan deklarasi variabel jika mereka lupa artinya.

Ini bukan trade off yang mudah untuk dibuat, karena Anda harus mempertimbangkan apa yang pembaca kode mungkin coba pahami, dan juga memperhitungkan bagaimana kode akan berubah dan tumbuh dari waktu ke waktu. Itu sebabnya penamaan itu sulit.

Keterbacaan adalah alasan mengapa dapat diterima untuk menggunakan saya sebagai penghitung lingkaran alih-alih Des deskriptifLoopCounterName. Karena ini adalah penggunaan yang paling umum untuk suatu variabel, Anda dapat menghabiskan paling sedikit ruang layar untuk menjelaskan mengapa variabel itu ada. Nama yang lebih panjang hanya akan membuang-buang waktu dengan membuatnya lebih sulit untuk memahami bagaimana Anda menguji kondisi loop atau pengindeksan ke dalam array.

Di ujung lain spektrum, jika suatu fungsi atau variabel jarang digunakan dalam operasi yang kompleks, seperti diteruskan ke panggilan fungsi multi-parameter, Anda dapat memberikannya nama yang terlalu deskriptif.


1

Seperti halnya bahasa lain: ketika tidak lagi menjelaskan aksi tunggal fungsi melakukan.


1

Saya katakan menggunakan kombinasi jawaban yang bagus dan masuk akal.

Jelaskan secara lengkap dan jelas apa yang dilakukan metode ini.

Jika nama metode tampak terlalu panjang - refactor metode untuk melakukan lebih sedikit.


1

Itu terlalu panjang ketika nama metode membungkus ke baris lain dan panggilan ke metode adalah satu-satunya hal di telepon dan mulai cukup dekat dengan margin. Anda harus memperhitungkan ukuran rata-rata layar orang yang akan menggunakannya.

Tapi! Jika namanya tampak terlalu panjang maka mungkin terlalu panjang. Cara menyiasatinya adalah dengan menulis kode Anda sedemikian rupa sehingga Anda berada dalam suatu konteks dan namanya pendek tetapi digandakan dalam konteks lain. Ini seperti ketika Anda bisa mengatakan "dia" atau "dia" dalam bahasa Inggris alih-alih nama lengkap seseorang.


1

Itu terlalu lama ketika terlalu verbal menjelaskan tentang apa masalahnya.

Misalnya, nama-nama ini secara fungsional setara.

di Jawa: java.sql.SQLIntegrityConstraintViolationException

dalam Python / Django: django.db.IntegrityError

Tanyakan pada diri Anda, dalam paket SQL / db, berapa banyak lagi tipe kesalahan integritas yang dapat Anda temukan? ;) Karenanya db.IntegrityErrorsudah cukup.


Anda selalu bisa berdebat sebaliknya. Ketika dijelaskan secara verbal apa masalahnya, jelas apa yang dilakukan metode ini selain itu dapat menyebabkan kebingungan dan mungkin memicu penggunaan metode yang salah.
Jonas Geiregat

0

Nama pengenal terlalu panjang ketika melebihi panjang yang dapat ditangani oleh kompiler Java Anda.


3
Apa?! Saya tidak mengerti mengapa saya tidak dipilih karena hal ini. Pertanyaannya tidak menanyakan kondisi yang diperlukan, hanya yang mencukupi!
uckelman

0

Ada dua cara atau sudut pandang di sini: Salah satunya adalah bahwa itu benar-benar tidak peduli berapa lama nama metode itu, asalkan itu deskriptif mungkin untuk menggambarkan apa metode ini lakukan (aturan dasar praktik terbaik Java). Di sisi lain, saya setuju dengan posting flybywire. Kita harus menggunakan kecerdasan kita untuk mencoba mengurangi sebanyak mungkin nama metode, tetapi tanpa mengurangi deskriptivitasnya. Penjelasan lebih penting :)


0

Nama terlalu panjang jika:

  • Membutuhkan lebih dari 1 detik untuk membaca
  • Memakan lebih banyak RAM daripada yang Anda alokasikan untuk JVM Anda
  • Adalah sesuatu yang anehnya dinamai
  • Jika nama yang lebih pendek masuk akal
  • Jika membungkus IDE Anda

Jujur nama hanya perlu menyampaikan tujuannya kepada para Pengembang yang akan menggunakannya sebagai metode API publik atau harus mempertahankan kode ketika Anda pergi. Ingat saja CIUMAN (tetap bodoh sederhana)

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.