Adakah orang lain yang menemukan kelas dan metode penamaan sebagai salah satu bagian tersulit dalam pemrograman? [Tutup]

Jadi saya sedang mengerjakan kelas ini yang seharusnya meminta dokumentasi bantuan dari vendor melalui layanan web. Saya mencoba untuk nama itu DocumentRetriever, VendorDocRequester, DocGetter, tetapi mereka hanya tidak terdengar benar. Saya akhirnya menjelajah melalui dictionary.com selama setengah jam mencoba mencari kata yang memadai.

Mulai pemrograman dengan nama-nama buruk seperti memiliki rambut yang sangat buruk di pagi hari, sisa hari menurun dari sana. Rasakan aku

Apa yang Anda lakukan sekarang baik-baik saja, dan saya sangat menyarankan Anda tetap menggunakan sintaks Anda saat ini, menjadi:

konteks + kata kerja + caranya

Saya menggunakan metode ini untuk memberi nama fungsi / metode, procs yang disimpan SQL, dll. Dengan tetap menggunakan sintaks ini, itu akan membuat Intellisense / Code Panes Anda jauh lebih rapi. Jadi Anda ingin EmployeeGetByID () EmployeeAdd (), EmployeeDeleteByID (). Saat Anda menggunakan sintaks yang lebih baik secara tata bahasa seperti GetEmployee (), AddEmployee () Anda akan melihat bahwa ini menjadi sangat berantakan jika Anda memiliki beberapa Gets di kelas yang sama karena hal-hal yang tidak terkait akan dikelompokkan bersama.

Saya mirip dengan penamaan file dengan tanggal, Anda ingin mengatakan 2009-01-07.log bukan 1-7-2009.log karena setelah Anda memiliki banyak dari mereka, pesanan menjadi sama sekali tidak berguna.

Satu pelajaran yang saya pelajari, adalah bahwa jika Anda tidak dapat menemukan nama untuk suatu kelas, hampir selalu ada yang salah dengan kelas itu:

• kamu tidak membutuhkannya
• itu terlalu banyak

Konvensi penamaan yang baik harus meminimalkan jumlah kemungkinan nama yang dapat Anda gunakan untuk variabel, kelas, metode, atau fungsi apa pun. Jika hanya ada satu nama yang mungkin, Anda tidak akan pernah kesulitan mengingatnya.

Untuk fungsi dan untuk kelas tunggal, saya meneliti fungsi untuk melihat apakah fungsi dasarnya adalah untuk mengubah satu jenis hal menjadi jenis lain. Saya menggunakan istilah itu dengan sangat longgar, tetapi Anda akan menemukan bahwa sejumlah besar fungsi yang Anda tulis pada dasarnya mengambil sesuatu dalam satu bentuk dan menghasilkan sesuatu dalam bentuk lain.

Dalam kasus Anda, sepertinya kelas Anda mengubah Url menjadi Dokumen. Agak aneh untuk berpikir seperti itu, tetapi sangat benar, dan ketika Anda mulai mencari pola ini, Anda akan melihatnya di mana-mana.

Ketika saya menemukan pola ini, saya selalu nama fungsi x Fromy .

Karena fungsi Anda mengubah Url menjadi Dokumen, saya akan menamainya

DocumentFromUrl

Pola ini sangat umum. Sebagai contoh:

atoi -> IntFromString
GetWindowWidth -> WidthInPixelsFromHwnd // or DxFromWnd if you like Hungarian
CreateProcess -> ProcessFromCommandLine

Anda juga dapat menggunakan UrlToDocumentjika Anda lebih nyaman dengan pesanan itu. Apakah Anda mengatakan x Fromy atau y Tox mungkin masalah selera, tapi aku lebih suka Fromagar karena dengan begitu awal nama fungsi sudah memberitahu Anda apa jenis itu kembali.

Pilih satu konvensi dan patuhi itu. Jika Anda berhati-hati untuk menggunakan nama yang sama dengan nama kelas Anda di Anda x Fromy fungsi, itu akan menjadi jauh lebih mudah untuk mengingat nama-nama apa yang Anda digunakan. Tentu saja, pola ini tidak bekerja untuk semuanya, tetapi tidak berfungsi di mana Anda menulis kode yang dapat dianggap sebagai "fungsional."

Terkadang tidak ada nama yang bagus untuk kelas atau metode, itu terjadi pada kita semua. Namun, sering kali, ketidakmampuan untuk menghasilkan nama bisa menjadi petunjuk untuk sesuatu yang salah dengan desain Anda. Apakah metode Anda memiliki terlalu banyak tanggung jawab? Apakah kelas Anda merangkum ide yang koheren?

Utas 1:

function programming_job(){
    while (i make classes){
         Give each class a name quickly; always fairly long and descriptive.
         Implement and test each class to see what they really are. 
         while (not satisfied){
            Re-visit each class and make small adjustments 
         }
    }
}

Utas 2:

while(true){
      if (any code smells bad){
           rework, rename until at least somewhat better
      }
}

Tidak ada Thread.sleep (...) di mana saja di sini.

Saya menghabiskan banyak waktu juga mengkhawatirkan nama-nama apa pun yang dapat diberi nama saat saya pemrograman. Saya akan mengatakan itu terbayar dengan sangat baik. Kadang-kadang ketika saya terjebak saya meninggalkannya untuk sementara waktu dan selama rehat kopi saya bertanya-tanya sedikit jika seseorang memiliki saran yang bagus.

Untuk kelas Anda, saya sarankan VendorHelpDocRequester.

Kode buku Lengkap oleh Steve Mcconnell memiliki bab yang bagus tentang variabel penamaan / kelas / fungsi / ...

Saya pikir ini adalah efek samping.

Bukan penamaan sebenarnya yang sulit. Yang sulit adalah proses penamaan membuat Anda menghadapi kenyataan mengerikan bahwa Anda tidak tahu apa yang sedang Anda lakukan.

Saya sebenarnya baru saja mendengar kutipan ini kemarin, melalui blog Signal vs. Noise di 37Signals, dan saya setuju dengan itu:

"Hanya ada dua hal yang sulit dalam Ilmu Komputer: pembatalan cache dan penamaan hal-hal." - Phil Karlton

Bagus, sulit. Ini memaksa Anda untuk memikirkan masalah, dan apa yang seharusnya dilakukan kelas. Nama yang baik dapat membantu mengarah pada desain yang baik.

Sepakat. Saya suka menjaga nama dan variabel tipe saya sejelas mungkin tanpa terlalu panjang, tetapi kadang-kadang hanya ada konsep tertentu yang Anda tidak dapat menemukan kata yang tepat untuk itu.

Dalam hal ini, selalu membantu saya untuk meminta masukan rekan kerja - bahkan jika mereka pada akhirnya tidak membantu, biasanya membantu saya untuk setidaknya menjelaskannya dengan keras dan membuat roda saya berputar.

Saya baru saja menulis tentang konvensi penamaan bulan lalu: http://caseysoftware.com/blog/useful-naming-conventions

Intinya:

verbAdjectiveNounStructure - dengan Structure dan Adjective sebagai bagian opsional

Untuk kata kerja , saya tetap menggunakan kata kerja tindakan: simpan, hapus, beri tahu, perbarui, atau hasilkan. Sekali-sekali, saya menggunakan "proses" tetapi hanya untuk secara khusus merujuk ke antrian atau backlog kerja.

Untuk kata benda , saya menggunakan kelas atau objek yang sedang berinteraksi. Dalam proyek web2, ini sering Tugas atau Proyek. Jika Javascript berinteraksi dengan halaman, mungkin tubuh atau tabel. Intinya adalah bahwa kode tersebut dengan jelas menggambarkan objek yang berinteraksi dengannya.

The Struktur adalah opsional karena unik untuk situasi. Layar daftar mungkin meminta Daftar atau Array. Salah satu fungsi inti yang digunakan dalam Daftar Proyek untuk web2proyek hanyalah getProjectList. Itu tidak mengubah data yang mendasarinya, hanya representasi data.

Kata sifat adalah sesuatu yang sama sekali berbeda. Mereka digunakan sebagai pengubah kata benda. Sesuatu yang sederhana seperti getOpenProjects mungkin mudah diimplementasikan dengan getProjects dan parameter switch, tetapi ini cenderung menghasilkan metode yang memerlukan sedikit pemahaman tentang data yang mendasarinya dan / atau struktur objek ... belum tentu sesuatu yang Anda ingin mendorong. Dengan memiliki fungsi yang lebih eksplisit dan spesifik, Anda dapat sepenuhnya membungkus dan menyembunyikan implementasi dari kode yang menggunakannya. Bukankah itu salah satu poin dari OO?

Lebih dari sekadar memberi nama kelas, membuat struktur paket yang tepat bisa menjadi tantangan yang sulit tetapi bermanfaat. Anda perlu mempertimbangkan memisahkan kekhawatiran modul Anda dan bagaimana mereka berhubungan dengan visi aplikasi.

Pertimbangkan tata letak aplikasi Anda sekarang:

• Aplikasi
  • VendorDocRequester (baca dari layanan web dan berikan data)
  • VendorDocViewer (gunakan pemohon untuk memberikan dokumen vendor)

Saya berani menebak bahwa ada banyak hal yang terjadi di dalam beberapa kelas. Jika Anda merevisi ini menjadi pendekatan yang lebih berorientasi MVC, dan memungkinkan kelas kecil untuk menangani tugas individu, Anda mungkin berakhir dengan sesuatu seperti:

• Aplikasi
  • VendorDocs
    • Model
      • Dokumen (objek biasa yang menyimpan data)
      • WebServiceConsumer (berurusan dengan seluk beluk dalam layanan web)
    • Pengendali
      • DatabaseAdapter (menangani persistensi menggunakan ORM atau metode lain)
      • WebServiceAdapter (memanfaatkan Konsumen untuk mengambil Dokumen dan menempelnya di basis data)
    • Melihat
      • HelpViewer (gunakan DBAdapter untuk mengeluarkan dokumentasi)

Kemudian nama kelas Anda bergantung pada namespace untuk memberikan konteks penuh. Kelas-kelas itu sendiri dapat secara inheren terkait dengan aplikasi tanpa harus secara eksplisit mengatakannya. Hasilnya, nama kelas lebih sederhana dan lebih mudah untuk didefinisikan!

Satu saran lain yang sangat penting: tolong lakukan sendiri dan ambil salinan Pola Desain Kepala Pertama. Buku yang fantastis dan mudah dibaca ini akan membantu Anda mengatur aplikasi dan menulis kode yang lebih baik. Menghargai pola desain akan membantu Anda memahami bahwa banyak masalah yang Anda temui telah dipecahkan, dan Anda akan dapat memasukkan solusi ke dalam kode Anda.

Leo Brodie, dalam bukunya "Thinking Forth", menulis bahwa tugas yang paling sulit bagi seorang programmer adalah memberi nama dengan baik, dan ia menyatakan bahwa alat pemrograman yang paling penting adalah tesaurus.

Coba gunakan tesaurus di http://thesaurus.reference.com/ .

Selain itu, jangan gunakan Notasi Hongaria PERNAH, hindari singkatan, dan konsisten.

Semoga sukses.

Singkatnya:
Saya setuju bahwa nama-nama baik itu penting, tetapi saya tidak berpikir Anda harus menemukannya sebelum menerapkannya dengan cara apa pun.

Tentu lebih baik memiliki nama baik sejak awal. Tetapi jika Anda tidak dapat menghasilkan satu dalam 2 menit, penggantian nama di lain waktu akan memakan waktu lebih sedikit dan merupakan pilihan yang tepat dari sudut pandang produktivitas.

Panjang:
Umumnya sering kali tidak layak untuk berpikir terlalu lama tentang suatu nama sebelum diterapkan. Jika Anda menerapkan kelas Anda, beri nama "Foo" atau "Dsnfdkgx", sementara menerapkan Anda melihat apa yang seharusnya Anda beri nama itu.

Terutama dengan Java + Eclipse, mengubah nama hal-hal itu tidak menyakitkan sama sekali, karena dengan hati-hati menangani semua referensi di semua kelas, memperingatkan Anda tentang tabrakan nama, dll. Dan selama kelas belum dalam repositori kontrol versi, saya tidak tahu t berpikir ada yang salah dengan mengganti nama 5 kali.

Pada dasarnya, ini adalah pertanyaan tentang bagaimana Anda berpikir tentang refactoring. Secara pribadi, saya suka, meskipun itu kadang-kadang mengganggu teman satu tim saya, karena mereka percaya tidak pernah menyentuh sistem yang sedang berjalan . Dan dari semua yang Anda bisa refactor, mengubah nama adalah salah satu hal paling berbahaya yang dapat Anda lakukan.

Mengapa bukan HelpDocumentServiceClient yang seteguk, atau HelpDocumentClient ... tidak masalah itu vendor, intinya adalah klien ke layanan web yang berurusan dengan dokumen Bantuan.

Dan ya penamaan itu sulit.

Hanya ada satu nama yang masuk akal untuk kelas itu:

HelpRequest

Jangan biarkan detail implementasi mengalihkan Anda dari maknanya.

Investasikan dalam alat refactoring yang bagus!

Saya berpegang pada dasar-dasar: VerbNoun (argumen). Contoh: GetDoc (docID).

Tidak perlu mewah. Akan mudah untuk memahami satu tahun dari sekarang, apakah itu Anda atau orang lain.

Bagi saya, saya tidak peduli berapa lama metode atau nama kelas asalkan deskriptif dan di perpustakaan yang benar. Lama berlalu adalah hari-hari di mana Anda harus ingat di mana setiap bagian API berada.

Intelisense ada untuk semua bahasa utama. Karena itu ketika menggunakan API pihak ke-3 saya suka menggunakan intelisense-nya untuk dokumentasi yang bertentangan dengan menggunakan dokumentasi 'aktual'.

Dengan pemikiran itu saya baik-baik saja untuk membuat nama metode seperti

StevesPostOnMethodNamesBeingLongOrShort

Lama - tapi terus kenapa. Siapa yang tidak menggunakan layar 24 inci hari ini!

Saya harus setuju bahwa penamaan adalah seni. Akan sedikit lebih mudah jika kelas Anda mengikuti "pola desigh" tertentu (pabrik dll).

Ini adalah salah satu alasan untuk memiliki standar pengkodean. Memiliki standar cenderung membantu memunculkan nama saat dibutuhkan. Ini membantu membebaskan pikiran Anda untuk digunakan untuk hal-hal lain yang lebih menarik! (-:

Saya akan merekomendasikan membaca bab yang relevan dari Kode Lengkap ( tautan Amazon ) Steve McConnell yang membahas beberapa aturan untuk membantu keterbacaan dan bahkan pemeliharaan.

HTH

Bersulang,

rampok

Tidak, debugging adalah hal yang paling sulit bagi saya! :-)

DocumentFetcher? Sulit dikatakan tanpa konteks.

Ini dapat membantu untuk bertindak seperti ahli matematika dan meminjam / menciptakan leksikon untuk domain Anda saat Anda mulai: menyelesaikan kata-kata sederhana yang menyarankan konsep tanpa mengeja setiap kali. Terlalu sering saya melihat frase panjang latinate yang berubah menjadi akronim, membuat Anda membutuhkan kamus untuk singkatan pula .

Bahasa yang Anda gunakan untuk menggambarkan masalah, adalah bahasa yang harus Anda gunakan untuk variabel, metode, objek, kelas, dll. Secara longgar, kata benda mencocokkan objek dan metode kata kerja yang cocok. Jika Anda kehilangan kata-kata untuk menggambarkan masalah, Anda juga tidak memiliki pemahaman (spesifikasi) masalah yang lengkap.

Jika hanya memilih di antara serangkaian nama, maka itu harus didorong oleh konvensi yang Anda gunakan untuk membangun sistem. Jika Anda datang ke tempat baru, ditemukan oleh konvensi-konvensi sebelumnya, maka selalu ada gunanya menghabiskan upaya untuk memperpanjangnya (dengan benar, konsisten) untuk membahas kasus baru ini.

Jika ragu, tidur di atasnya, dan pilih nama yang paling jelas pertama, keesokan paginya :-)

Jika Anda bangun suatu hari dan menyadari bahwa Anda salah, segera ubah itu.

Paul.

BTW: Document.fetch () cukup jelas.

Saya menemukan saya memiliki masalah paling besar dalam variabel lokal. Sebagai contoh, saya ingin membuat objek bertipe DocGetter. Jadi saya tahu itu DocGetter. Mengapa saya harus memberikan nama lain? Saya biasanya berakhir memberinya nama seperti dg (untuk DocGetter) atau temp atau sesuatu yang sama-sama tidak deskriptif.

Jangan lupa pola desain (bukan hanya yang GoF) adalah cara yang baik untuk menyediakan kosa kata umum dan nama mereka harus digunakan setiap kali seseorang sesuai situasi. Itu bahkan akan membantu pendatang baru yang akrab dengan nomenklatur untuk dengan cepat memahami arsitektur. Apakah kelas ini yang sedang Anda kerjakan seharusnya bertindak seperti Proxy, atau bahkan Façade?

Bukankah seharusnya dokumentasi vendor menjadi objeknya? Maksud saya, yang satu itu nyata, dan bukan hanya sebagai antropomorfisasi bagian dari program Anda. Jadi, Anda mungkin memiliki VendorDocumentationkelas dengan konstruktor yang mengambil informasi. Saya berpikir bahwa jika nama kelas berisi kata kerja, seringkali ada yang tidak beres.

Aku pasti merasakanmu. Dan aku merasakan sakitmu. Setiap nama yang saya pikirkan sepertinya sampah bagi saya. Semuanya tampak sangat umum dan saya ingin akhirnya belajar bagaimana menyuntikkan sedikit bakat dan kreativitas ke dalam nama saya, membuat mereka benar-benar mencerminkan apa yang mereka gambarkan.

Satu saran yang saya miliki adalah berkonsultasi dengan Thesaurus. Word memiliki yang bagus, seperti halnya Mac OS X. Itu benar-benar dapat membantu saya keluar dari awan dan memberi saya tempat awal yang baik serta beberapa inspirasi.

Jika nama itu akan menjelaskan dirinya kepada seorang programmer awam maka mungkin tidak perlu mengubahnya.