Apakah ada teknik atau tes yang baik untuk jenis penamaan?

23

Pertanyaan yang canggung dan terbuka, tapi ini masalah yang selalu saya lawan:

Perangkat lunak yang mudah dirawat dan digunakan adalah perangkat lunak yang dirancang dengan baik. Mencoba membuat desain yang intuitif berarti memberi nama komponen Anda sedemikian rupa sehingga pengembang berikutnya harus dapat menyimpulkan fungsi komponen. Inilah sebabnya kami tidak memberi nama kelas kami "Type1", "Type2", dll.

Saat Anda memodelkan konsep dunia nyata (mis. Pelanggan), ini umumnya sesederhana memberi nama tipe Anda setelah konsep dunia nyata dimodelkan. Tetapi ketika Anda sedang membangun hal-hal abstrak, yang lebih berorientasi sistem, sangat mudah kehabisan nama yang mudah dibaca dan mudah dicerna.

Semakin buruk (bagi saya) ketika mencoba untuk menamai keluarga jenis, dengan tipe-dasar atau antarmuka yang menggambarkan apa yang harus dilakukan komponen, tetapi tidak bagaimana mereka bekerja. Ini secara alami mengarah ke masing-masing jenis turunan yang mencoba menggambarkan rasa implementasi (misalnya IDataConnectiondan SqlConnectiondalam .NET Framework), tetapi bagaimana Anda mengekspresikan sesuatu yang rumit seperti "bekerja dengan refleksi dan mencari set atribut tertentu"?

Kemudian, ketika Anda akhirnya memilih nama untuk tipe yang menurut Anda menggambarkan apa yang ingin dilakukan, kolega Anda bertanya "WTF apakah ini DomainSecurityMetadataProviderbenar - benar dilakukan? "

Apakah ada teknik yang baik untuk memilih nama yang bermaksud baik untuk suatu komponen, atau bagaimana membangun kumpulan komponen tanpa mendapatkan nama yang kacau?

Apakah ada tes sederhana yang dapat saya terapkan pada nama untuk mendapatkan perasaan yang lebih baik untuk apakah nama itu "baik", dan harus lebih intuitif kepada orang lain?

design naming

— Paul Turner
sumber

20

ada enam teknik yang terbukti bekerja untuk saya: 1) menghabiskan banyak waktu untuk menciptakan nama 2) menggunakan ulasan kode 3) jangan ragu untuk mengubah nama 4) menghabiskan banyak waktu untuk menciptakan nama 5) menggunakan ulasan kode 6) jangan ragu untuk mengganti nama

— nyamuk

5

@gnat: Silakan kirim jawaban Anda sebagai jawaban agar kami dapat memilihnya.

— S.Lott

2

Lihat Aturan Ottinger untuk Penamaan Variabel dan Kelas

— Péter Török

3

Saya sering menggunakan tesaurus ketika melakukan pengembangan baru untuk membantu saya mendapatkan nama baik.

— Apprentice Dr. Wily

3

Saya mencoba untuk menghindari memanggil apa pun "Manajer". Alan Green dan Jeff Atwood berpendapat bahwa istilah itu terlalu sering digunakan dan terlalu samar untuk menyampaikan makna. Saya harus setuju.

— Apprentice Dr. Wily

41

Untuk penamaan, ada enam teknik yang terbukti berhasil untuk saya:

menghabiskan banyak waktu untuk menciptakan nama
gunakan ulasan kode
jangan ragu untuk mengganti nama
menghabiskan banyak waktu untuk menciptakan nama
gunakan ulasan kode
jangan ragu untuk mengganti nama

PS. Jika API Anda akan dipublikasikan, hal di atas berlaku sebelum itu - karena, Anda tahu,

"API Publik, seperti berlian, selamanya. Anda memiliki satu kesempatan untuk melakukannya dengan benar, jadi berikan yang terbaik ..." (Joshua Bloch, Cara Mendesain API yang Baik dan Mengapa Penting )

— agas
sumber

1

Jika itu API publik, ada tiga teknik tambahan yang dapat Anda gunakan ...

— UncleZeiv

1

@UncleZeiv: seperti ....?

— FrustratedWithFormsDesigner

3

@FrustratedWithFormsDesigner: 1. menghabiskan banyak waktu untuk menciptakan nama 2. menggunakan ulasan kode dan 3. jangan ragu untuk mengganti nama

— S.Lott

3

Jawaban ini meyakinkan saya bahwa secara umum: tidak, tidak ada cara mudah untuk mendapatkan nama yang benar. Hanya berusaha dengan kerja keras.

— Paul Turner

4

7. Jangan ragu untuk mendesain ulang tipe atau fungsi jika ternyata tidak mungkin untuk merancang nama yang tepat untuk mereka. Kode yang dirancang dengan baik selalu dapat dinamai dengan benar.

— Joren

8

Tes dasar saya adalah jika Anda dapat menggambarkan fungsi variabel hanya menggunakan kata-kata dari variabel:

mis. jika DomainSecurityMetadataProvider baik "Menyediakan Metadata Keamanan Domain" atau "Menyediakan Metadata terkait dengan Keamanan Domain", itu bagus.

Namun, ada nuansa yang berbeda dari orang ke orang:

mis. Untuk saya, original_team_code adalah kode untuk tim asli, sedangkan untuk orang lain mungkin kode asli untuk tim. Salah satu favorit pribadi saya adalah "UnsafeLegacyMutex", yang tidak bisa tidak saya baca sebagai "Ini adalah Legacy Mutex yang Tidak Aman", daripada "Ini adalah Mutex untuk ThreadUnsafe Legacy Code".

Jadi tes lanjutan saya adalah menuliskan variabel di papan / wiki / chat, dan minta orang menebak apa artinya.

— deworde
sumber

7

Apakah ada teknik yang baik untuk memilih nama yang bermaksud baik untuk suatu komponen, atau bagaimana membangun kumpulan komponen tanpa mendapatkan nama yang kacau?

Tidak juga.

Satu tip, bagaimanapun, adalah untuk menghindari "suara pasif".

"DomainSecurityMetadataProvider" pasif. Tidak ada kata kerja, itu semua kata benda dan kata benda digunakan sebagai kata sifat.

"ProvidMetadataForDomainSecurity" lebih aktif. Ada kata kerja.

Pemrograman berorientasi objek adalah semua (benar-benar) kata benda-kata kerja. Kata benda == objek. Verb == metode. Jadi nama kelas umumnya sangat "kata benda". Untuk menghentikan kebiasaan ini, dan mulai memasukkan kata kerja, sulit.

Apakah ada tes sederhana yang dapat saya terapkan pada nama untuk mendapatkan perasaan yang lebih baik untuk apakah nama itu "baik", dan harus lebih intuitif kepada orang lain?

Iya nih. Anda mendefinisikan tes yang sangat baik dalam pertanyaan Anda. Tanyai orang lain.

Di masa lalu kami menyebutnya "penelusuran desain". Itu adalah masalah besar, berkeringat dalam metodologi air terjun. Saat ini, dengan metode Agile, itu harus menjadi kolaborasi biasa antara penulis dan pengguna kelas. Tidak butuh waktu lama. Membahas desain (dan nama-nama) sebelum menulis tes (dan kode) akan mengurangi faktor keheranan dan dapat mencegah WTF.

— S.Lott
sumber

12

Tidak yakin saya setuju dengan ide suara pasif. Bagi saya, Kelas lebih masuk akal sebagai kata benda.

— deworde

7

Secara umum, saya mencoba untuk menjaga nama ketik saya dalam suara pasif, karena sesuai dengan gaya kata benda OOP. Saya akan menganggap ProvideMetadataForDomainSecuritynama tipe yang buruk. Nama metode biasanya lebih mudah dinamai karena saya bebas menggunakan kata kerja. Pembatasan bahasa adalah inti masalahnya.

— Paul Turner

Meskipun saya suka "meminta orang" sebagai ujian nyata, saya harus bertanya kepada kolega saya tentang penamaan setidaknya dua kali sehari. Saya berharap sesuatu yang tidak memerlukan waktu orang lain.

— Paul Turner

2

Kelas memang masuk akal sebagai kata benda. Masalahnya adalah kelas kompleks ini dengan frase kata benda-kata sifat yang panjang. Preposisi juga dapat membantu.

— S.Lott

2

Kolaborasi adalah rahasia dari perangkat lunak yang baik. Kolaborasi membutuhkan waktu. Tidak ada jalan kerajaan untuk menulis yang baik.

— S.Lott

6

Menggunakan tesaurus

Sangat sering saya akan merujuk pada tesaurus ketika melakukan pengembangan baru untuk menemukan kata-kata yang tepat untuk menggambarkan kelas dan metode saya.

Kelas yang terutama berisi logika operasi

Saya cenderung memberi nama kelas yang terutama menyediakan metode operasi dalam struktur kata benda seperti "EntityProvider", "EntityLocator", dll.

Kelas-kelas ini umumnya tidak mengandung banyak negara.

Kelas yang berisi status

Layar UI dan entitas data pada umumnya stateful, jadi saya cukup memberi nama kelas-kelas ini dengan pola kata benda atau kata benda.

Contoh: Orang, Karyawan, Karyawan Lancar, Karyawan Lepas

Kelas utilitas

Kelas yang hanya berisi metode statis umumnya dianggap kelas "utilitas", jadi saya secara konsisten menamainya dengan akhiran "Utilitas".

Contoh: NetworkUtilities, FileUtilities

Tes

Saya tidak memiliki tes yang baik untuk memutuskan apakah ada nama yang salah, tetapi saya akan menyarankan untuk mencoba menggunakan kata benda dan / atau kata kerja tunggal dalam nama, kemudian pikirkan apakah kata benda / kata kerja itu secara akurat menggambarkan apa yang Anda ' penamaan kembali.

Jika Anda merasa bahwa ada lebih banyak ke kelas / metode yang tidak ditangkap oleh nama, maka kelas / metode itu mungkin perlu di refactored.

Alan Green dan Jeff Attwood telah menulis tentang kejahatan penamaan kelas dengan akhiran "Manajer". Mereka berpendapat bahwa istilah "Manajer" terlalu sering digunakan dan terlalu samar untuk menyampaikan sesuatu yang bermakna. Saya harus setuju.

Artikel Jeff juga menyediakan daftar panduan yang disarankan dari Steve McConnell's Code Complete.

variabel

Baru-baru ini saya telah bereksperimen dengan nama variabel / parameter deskriptif yang lebih panjang yang menggabungkan preposisi, seperti "Of", "By", "For", dll. Beberapa contoh ditunjukkan di bawah ini:

string firstNameOfEmployee;

string lastNameOfEmployee;

// here I nimbly avoid worrying about whether to call it "Id" or "ID" :)
int idOfEmployee;

decimal amountForDeposit;

Account accountForDeposit;

Saya menemukan bahwa ini berfungsi baik dengan fitur intellisense Visual Studio membuatnya mudah untuk mengetik nama-nama panjang ini. Saya juga menemukan bahwa ada lebih sedikit duplikasi awalan nama variabel (mis. PersonID, personFirstName, personLastName vs idOfPerson, firstNameOfPerson, lastNameOfPerson), memberikan hash yang lebih baik yang membuat intellisense semakin berguna.

— Apprentice Dr. Wily
sumber

1

Saya akan kedua titik tentang nama variabel panjang, sekali lagi, Visual Studio (jika Anda menggunakannya) membuat ini no-brainer. Jauh lebih tidak berbahaya untuk memiliki nama variabel panjang yang eksplisit daripada nama variabel pendek di mana Anda harus "berpikir" tentang atau menyelidiki apa arti sebenarnya nama itu. Pikirkan juga konteksnya. Saya lebih suka melihat "peopleToDelete" daripada "listOfPeople". Sekali lagi, Visual Studio memberi tahu Anda jenis variabel, tidak perlu menyertakannya.

— John Bubriski

Saya juga tidak menyukai notasi Hungaria yang rumit yang telah Anda tambahkan ke nama variabel. Saya tidak perlu peduli jika kumpulan ID orang adalah List, array, IEnumerableatau ConcurrentQueue. Ini adalah kumpulan ID yang harus saya sebutkan, dan detail implementasi bagaimana penyimpanannya adalah bagasi mental yang tidak perlu. Meskipun secara umum saya setuju bahwa jika nama yang lebih panjang jauh lebih deskriptif, itu harus lebih disukai daripada nama yang lebih pendek dan kurang jelas.

— Allon Guralnek

@ Allon - Lucu, saya akan merevisi jawaban saya berdasarkan komentar SkippyFire. Saya sebenarnya setuju denganmu; contoh saya bernada notasi Hungaria. Satu-satunya pertahanan saya adalah bahwa mudah untuk membaca kode dan memahami tipe data yang terlibat tanpa IDE yang tersedia, seperti jika saya membaca melalui source-control diff. Tapi itu bukan alasan. :) Saya akan merevisi contoh saya agar sejalan dengan firstNameOfEmployee, lastNameOfEmployee, dll.

— Apprentice Dr. Wily

2

Kemudian, ketika Anda akhirnya memilih nama untuk tipe yang menurut Anda menggambarkan apa yang coba dilakukan, kolega Anda bertanya "WTF apakah sebenarnya DomainSecurityMetadataProvider ini melakukannya?"

Apa nama yang Anda harapkan untuk kelas khusus kompleks dan domain? Ini adalah tentang sebaik yang akan didapat tanpa membuat nama kelas Anda kalimat (yang akan membuat semua orang berpikir Anda telah memberikan terlalu banyak tanggung jawab ke satu kelas)

Saya akan mempertimbangkan menjatuhkan penyedia dari nama. Jika secara spesifik menyebutkan Metadata, semua orang sudah tahu Anda menggunakan refleksi. Anda bisa menjadikannya satu kata lebih ringkas (atau mungkin berubah ke kata lain - itu lebih merupakan konsumen daripada penyedia dari apa yang Anda tulis)

— brian
sumber

Metadata yang dipermasalahkan bukan berasal dari refleksi (tetapi ia menjelaskan bagaimana memperlakukan jenis). Tipe mengimplementasikan ISecurityMetadataProviderantarmuka, yang ada titik injeksi dalam infrastruktur keamanan, untuk memberikan informasi kepada subsistem. Penamaan itu sulit.

— Paul Turner

Saya anggap DomainSecurityMetadataProvidersebagai penyedia DomainSecurityMetadataobjek, di mana DomainSecurityMetadatametadata itu sendiri. Nama yang jelas dan mudah dimengerti. Aku bahkan tidak perlu tahu apa DomainSecurityMetadataitu! Ini hanya beberapa objek, yang disediakan penyedia ini. Hanya menghapus Providerakhiran tidak meningkatkan keterbacaan, tetapi justru sebaliknya - kurangi itu. Tanpa akhiran ini saya akan berpikir bahwa itu hanya beberapa metadata (objek kontainer untuk beberapa metadata), tetapi bukan objek untuk mendapatkan metadata dari (penyedia).

— Ruslan Stelmachenko

0

Gunakan metafora untuk menggambarkan bagian-bagian dari sistem. Tidak hanya itu akan membuat Anda menemukan analogi baru, ini akan membantu penamaan yang lebih mudah.

(Saya sadar ini bukan contoh yang kuat tapi pokoknya) Sebagai contoh Anda dapat memanggil variabel atau tipe sebagai mailbox, yang berfungsi sebagai antrian untuk pesan yang diterima untuk kelas.

— nimcap
sumber

-1

Satu hal yang akan saya tegaskan adalah bahwa Nama TIDAK PERNAH boleh dibiarkan salah. Contoh terbaik, selama beberapa factoring, banyak kode berubah, dan beberapa variabel mulai merujuk pada sesuatu selain dari apa yang disarankan oleh nama mereka.

Tidak lama kemudian, seorang programmer menghabiskan waktu lama dan menggunakan beberapa panggilan database yang sangat mahal mencoba untuk mendapatkan potongan-potongan data tertentu yang telah diekstraksi dan disimpan. Saya mengganti nama semuanya dan tiba-tiba kami bisa menghapus satu ton logika yang terlalu rumit dan bermasalah.

— deworde
sumber

1

Anda harus menghapus jawaban ini dan mengeditnya menjadi jawaban awal Anda

— Ryathal

Saya pikir ini adalah jawaban yang berbeda dari jawaban saya yang lain.

— deworde

-1

Semoga kasus di mana Anda harus berpikir keras tentang nama-nama itu jarang terjadi. Ketika kasus-kasus itu muncul, tulis saja sebuah paragraf yang menjelaskan apa yang dilakukan kelas. Berlawanan dengan komentar in-function atau komentar level fungsi, tujuan utama suatu kelas jarang berubah sehingga risiko komentar yang keluar dari tanggal relatif kecil. Jadi, Anda memiliki kemewahan menulis beberapa paragraf atau bahkan menggambar ASCII untuk menjelaskan apa yang dilakukan kelas.

— kizzx2
sumber