Apakah saya tidak bermoral karena menggunakan nama variabel yang berbeda dari jenisnya hanya berdasarkan kasus?

Misalnya, ambil bagian kode ini:

var person = new Person();

atau untukmu Pythonistas:

person = Person()

Saya terus-menerus diberitahu betapa buruknya ini, tetapi belum melihat contoh amoralitas dari dua baris kode ini. Bagi saya, orang adalah Orang dan mencoba memberinya nama lain hanya membuang-buang waktu. Saya kira di hari-hari sebelum penyorotan sintaks, ini akan menjadi masalah besar. Tapi hari ini, cukup mudah untuk membedakan nama tipe dari nama variabel. Heck, bahkan mudah untuk melihat perbedaannya di SO.

Atau apakah ada sesuatu yang saya lewatkan? Jika demikian, akan sangat membantu jika Anda dapat memberikan contoh kode yang menyebabkan masalah.

Apa alasan mereka mengatakan ini buruk? Saya melakukan ini sepanjang waktu. Ini adalah cara paling sederhana dan ekspresif untuk menamai satu variabel dari suatu tipe. Jika Anda membutuhkan dua Personobjek maka Anda dapat mengawali persondengan kata sifat yang bermakna seperti

fastPerson
slowPerson

jika tidak adil

person

baik-baik saja denganku.

Saya banyak menggunakan pola ini dalam tanda tangan metode. Jika saya tidak dapat memberikan nama deskriptif alternatif selain IMHO, tidak ada yang salah dengan ini.

Apa yang salah jika Anda memiliki dua tipe Orang dan orang maka itu sangat salah.

Saya menggunakannya sepanjang waktu untuk referensi objek sementara. Saya akan menghindarinya seperti wabah untuk tipe data primitif.

Person person = new Person(); // okay

int Int = 42; // pure evil

Jika seseorang mengatakan itu jahat, tanyakan apakah ini lebih baik:

var abc = new Person();

Jika Orang tersebut adalah Orang umum dalam konteksnya, maka "orang" adalah nama yang sangat bagus. Tentu saja jika Orang tersebut memiliki peran tertentu dalam kode tersebut maka lebih baik menamainya menggunakan peran tersebut.

Saya kira saya akan mendapatkan suara negatif karena mengatakan demikian, tapi ...

Baru saja melewati seabad menyaksikan pembunuhan epik dan keserakahan, kami programmer benar-benar diberkati jika hal paling tidak bermoral yang dapat kami lakukan adalah menyebutkan variabel.

Saya tidak berpikir itu selalu "buruk", tetapi jelas jika Anda dapat memenuhi syarat untuk memberikan lebih banyak konteks, seperti orang macam apa itu (Anda hanya berurusan dengan satu dari mungkin banyak orang yang mungkin), maka orang lain yang mengambilnya up mungkin lebih mengerti.

Jason - Saya tidak yakin siapa yang memberi tahu Anda bahwa ini buruk. Sejumlah penulis menggunakan ini sebagai cara standar untuk mengekspresikan Mesin Virtual (huruf kecil) dari Kelas ( huruf besar ).

Saya cukup sering menggunakan ini karena saya menemukan bahwa variabel huruf kecil sebenarnya berkomunikasi kepada saya tidak hanya bahwa ini adalah sebuah instance tetapi juga nama kelasnya.

Kecuali seseorang memiliki argumen yang kuat untuk melawan, saya pasti akan terus melakukan ini.

Alasan itu dianggap buruk adalah jika Anda perlu memiliki 2 Orang di masa depan, Anda dapat berakhir dengan kode yang terlihat seperti itu.

Orang orang = Orang baru ();

Orang person2 = Orang baru ();

Itu kemudian akan berbatasan dengan "Buruk". Namun, dalam hal ini Anda harus memfaktorkan kembali orang asli Anda untuk membedakan keduanya.

Sebagai contoh Anda, nama variabel "person" adalah nama deskriptif yang sempurna untuk objek "Person". Oleh karena itu tidak ada yang salah dengan itu sama sekali.

Saya menyebutkan nama apa adanya: jika variabel mewakili seseorang dengan 2 anjing, sebut saja personWith2Dogs. Jika variabel memiliki ruang lingkup pendek (seperti loop var) maka orang baik-baik saja.

Saya sering menggunakan itu dalam kode saya, dan tidak berpikir ada yang salah dengan itu. Yang mengatakan, saya (mungkin) tidak akan menggunakannya dalam metode yang lebih lama dari, katakanlah satu layar, dan jika ada beberapa contoh kelas Person. Jelas jangan beri nama mereka person1, person2, person3 ... alih-alih gunakan sesuatu yang lebih deskriptif, seperti person_to_del, person_to_ban, person_to_update, dll.

Tidak bermoral, tetapi pencarian global akan menemukan keduanya Persondan personjika Anda gagal mengaktifkan sensitivitas huruf. Saya lebih suka awalan untuk mempermudah pencarian / penggantian global, tetapi sama sekali BUKAN bahasa Hongaria atau sesuatu yang panjang / rumit. Jadi, saya menggunakan ...

Personuntuk kelas / jenis aPersonuntuk variabel lokal thePersonuntuk parameter metode myPersonuntuk variabel contoh ourPersonuntuk variabel kelas

Pada kesempatan langka, saya mungkin menggunakan pdalam konteks lokal di mana saya memiliki BANYAK referensi, tetapi itu biasanya hanya berlaku untuk indeks loop dan sejenisnya.

Tergantung.

Jika Anda memiliki gaya kapitalisasi yang ketat, jadi variabel dimulai dengan huruf kecil (dan gunakan under_scores atau camelCase untuk jeda kata), dan Kelas dimulai dengan Huruf Kapital, maka jelaslah bahwa orang adalah variabel dan Orang adalah kelas, dan ketika seseorang memahami ini , sepertinya tidak akan berada di ruang nama yang tumpang tindih. (Demikian pula, orang hampir tidak pernah bingung antara kata kerja atau kata benda "memoles" dan kata sifat "Polandia".)

Jika Anda tidak memiliki gaya seperti itu, Anda memiliki dua nama yang dapat dengan mudah membingungkan, dan hanya berbeda dalam kasus. Itu buruk.

Apa argumen sebenarnya yang digunakan orang-orang itu?

Jika mereka tidak mengizinkan Anda menggunakan person sebagai nama variabel, Anda dapat mempertimbangkan untuk menambahkan awalan 'a'.

aPerson = Person()

Saya pikir apa yang Anda lakukan baik-baik saja. Saya pikir secara umum penting untuk menyetujui standar pengkodean.

Misalnya saya menggunakan lowerCamelCase untuk instance, variabel dan UpperCamelCase untuk kelas dll

Standar pengkodean harus menghilangkan masalah ini.

Ketika saya melihat program open source yang sukses, mereka sering kali memiliki standar pengkodean

http://drupal.org/coding-standards

http://help.joomla.org/content/view/826/125/

http://wiki.rubyonrails.org/rails/pages/CodingStandards

http://lxr.linux.no/linux/Documentation/CodingStyle

Menyetujui standar pengkodean harus menjadi pertempuran terakhir yang Anda miliki tentang ini.

Sebenarnya lihat entri wikipedia (dari http://en.wikipedia.org/wiki/CamelCase )

Pemrograman dan gaya pengkodean

Kapitalisasi internal terkadang disarankan untuk menunjukkan batas kata dengan pedoman gaya pengkodean untuk menulis kode sumber (misalnya, bahasa pemrograman Mesa dan bahasa pemrograman Java). Rekomendasi yang terdapat dalam beberapa pedoman ini didukung oleh alat analisis statis yang memeriksa kepatuhan kode sumber.

Rekomendasi ini sering membedakan antara UpperCamelCase dan lowerCamelCase, biasanya menentukan varietas mana yang harus digunakan untuk jenis entitas tertentu: variabel, bidang catatan, metode, prosedur, jenis, dll.

Salah satu gaya pengkodean Java yang banyak digunakan menyatakan bahwa UpperCamelCase digunakan untuk kelas, dan lowerCamelCase digunakan untuk instance dan metode. [19] Menyadari penggunaan ini, beberapa IDE, seperti Eclipse, mengimplementasikan pintasan berdasarkan CamelCase. Misalnya, dalam fitur bantuan Konten Eclipse, mengetik hanya huruf besar dari kata CamelCase akan menyarankan nama kelas atau metode yang cocok (misalnya, mengetik "NPE" dan mengaktifkan bantuan konten dapat menyarankan "NullPointerException").

Notasi Hongaria asli untuk pemrograman menentukan bahwa singkatan huruf kecil untuk "tipe penggunaan" (bukan tipe data) harus mengawali semua nama variabel, dengan sisa nama di UpperCamelCase; karena itu adalah bentuk lowerCamelCase. CamelCase adalah konvensi resmi untuk nama file di Java dan untuk komputer pribadi Amiga.

Microsoft .NET merekomendasikan lowerCamelCase untuk parameter dan bidang non-publik dan UpperCamelCase (alias "Pascal Style") untuk jenis pengenal lainnya. [20]

Python merekomendasikan UpperCamelCase untuk nama kelas. [21]

Registri NIEM mengharuskan Elemen Data XML menggunakan UpperCamelCase dan Atribut XML menggunakan lowerCamelCase.

Tidak ada konvensi tunggal untuk memasukkan singkatan huruf besar (terutama akronim dan inisialisme) dalam nama CamelCase. Pendekatannya mencakup membiarkan seluruh singkatan dalam huruf besar (seperti dalam "useHTTPConnection") dan hanya menyisakan huruf pertama dalam huruf besar (seperti dalam "useHttpConnection").

Casing unta sama sekali tidak universal dalam komputasi. Pengguna beberapa bahasa pemrograman modern, terutama yang ada di keluarga Lisp dan Forth, hampir selalu menggunakan tanda hubung. Di antara alasan yang terkadang diberikan adalah bahwa melakukan hal itu tidak memerlukan pengalihan pada sebagian besar keyboard, bahwa kata-kata lebih mudah dibaca saat dipisahkan, dan casing unta mungkin tidak dapat disimpan dengan andal dalam bahasa yang tidak peka huruf besar atau kecil (seperti Common Lisp, yang, meskipun secara teknis merupakan bahasa yang peka huruf besar kecil, mengkanonikalisasi (melipat) pengenal menjadi huruf besar secara default).

Ada kemungkinan untuk membuat argumen yang lebih kuat bahwa nama metode semacam itu tidak hanya tidak berbahaya tetapi juga dapat menjadi indikator kode kualitas yang baik.

• Indikator perincian kode yang baik: Jika metode Anda pendek, bertujuan tunggal, dan diberi nama secara deskriptif, Anda tidak memerlukan banyak informasi dalam nama variabel. Jika Anda memiliki metode panjang yang melakukan banyak hal dan perlu melacak banyak konteks dan status, maka nama variabel Anda harus lebih deskriptif.

• Indikator penghitungan tujuan umum didorong ke dalam metode tujuan umum: jika Anda melakukan manipulasi struktur data menengah dalam metode bisnis, misalnya larik pengguna harus dideduplikasi, Anda harus memiliki variabel dalam ruang lingkup dengan nama seperti users[]dan deduplicatedUsers[]. Jika Anda memindahkan deduplikasi ke metode utilitas, Anda dapat memanggil metode tersebut Utils.dedup(array), dan Anda dapat memanggil array terduplikasi deduplicatedArrayatau hanya result.

• Pengurai Java sering menggunakan skema seperti itu untuk menamai variabel lokal (variabel instance dan kelas biasanya tersedia di bytecode, tetapi variabel lokal tidak), dan hasilnya lebih mudah dibaca daripada yang Anda harapkan, bahkan seringkali lebih mudah dibaca daripada sumber asli.

• Lihat prinsip Larry Wall tentang "Ambiguitas Lokal OK" - http://www.wall.org/~larry/natural.html .

Saya akan mengatakan bahwa Anda mungkin memiliki beberapa kegunaan khusus setiap kali Anda membuat objek. Jenisnya sendiri sangat jarang mencerminkan penggunaan itu.

Jadi jika Anda ingin membuat kontak baru di aplikasi buku alamat Anda, Anda mungkin ingin memanggil variabel newContact.

Dan jika Anda menguji unit kode Anda untuk memeriksa perilaku Personobjek tanpa nama yang disetel, Anda mungkin ingin memanggilnya unnamedPersonatau sesuatu yang serupa.

Menyebutnya akan personmenghilangkan peluang besar untuk membuat kode Anda terdokumentasi sendiri.

Hanya jika Anda memprogram di VB6. Dalam hal ini , apa yang Anda lakukan adalah ilegal, tetapi tidak amoral.

Saya melakukannya juga, dan saya juga tidak mengerti mengapa itu harus 'tidak bermoral'. Meskipun saya dapat memahami bahwa itu 'mungkin' kadang-kadang membingungkan, tetapi hari ini kami memiliki IDE dengan intellisense dan syntax highlighting yang akan memastikan bahwa (jika Anda membuat kesalahan dan mereferensikan variabel Anda, bukan kelas Anda, dan sebaliknya) Anda akan melihat kesalahan Anda cukup cepat. Dan kami juga memiliki kompiler. :)

Saya juga tidak melihat ada masalah dengan latihan ini. Selama hanya ada satu variabel dari kelas itu, maka mudah untuk ditulis dan dibaca. Imo, itu bahkan berlaku di editor teks dasar. Saya pribadi tidak dapat mengingat siapa pun yang menyebut ini buruk atau bahkan tidak bermoral. Terus lakukan ini :)

Saya pikir 'aturan' yang mungkin Anda pikirkan lebih ditujukan untuk tipe primitif, dan kelas di mana nama kelas membuat nama variabel yang buruk.

Misalnya, jika Anda berurusan dengan penghitungan harga barang tertentu di toko online, kode berikut bukanlah bentuk yang baik:

Decimal _decimal = item.BaseCost + item.Tax;

Sebaliknya, nama yang lebih deskriptif akan disarankan, seperti '_total', atau '_cost'.

Satu-satunya masalah dengan hal semacam ini yang saya temukan adalah jika Anda menginginkan nama yang sama untuk anggota pribadi dan juga milik umum.

Jika ini hanya berbeda dalam kasus, ini akan berfungsi dengan baik dalam bahasa yang peka huruf besar kecil seperti C #, tetapi tidak di VB.NET.

Jadi, misalnya, dalam VB, saya akan menulis

Private _name As String

tapi

Public Property Name() As String
    Get
        Return _name
    End Get
    Set(ByVal Value As String)
        _name = Value
    End Set
End Property

Saya akan melakukan hal yang sama di C #, sehingga terjemahan dari satu ke yang lain tidak menimbulkan rasa sakit. Ini juga membuatnya sedikit tidak rawan kesalahan, karena sangat mudah untuk salah dibaca, atau memang kata-kata yang salah ketik yang berbeda hanya berdasarkan kasus.

Bukan tidak bermoral, tetapi jika nama terbaik Anda untuk variabel Anda adalah nama jenisnya, ada yang salah atau Anda hanya membuat bukti konsep atau semacamnya. Bagi saya nama variabel harus mengacu pada arti dalam konteks bisnis dan bukan pada bahasa pemrograman. Akan lebih sulit untuk memahami kodenya.

Saya sering menggunakan Person person = new Person()diri saya sendiri. Biasa digunakan di Java / C #.

Meskipun saya akhirnya bertanya-tanya mengapa kemarin

private enum DataType {NEW, OLD}

tidak bekerja di C # ...

Terutama melihat bagaimana Anda dapat menggunakan String, string, Double, double, ... di akan di C #.

Person person = new Person()

baik-baik saja di buku saya.

Yang menjadi mengerikan adalah ketika Anda memiliki:

string Person;
string person;

Sangat mudah untuk mencampur 2.

Apa yang telah diungkapkan kepada saya, selain tidak memenuhi Standar Pengkodean kami, adalah menghindari kebingungan tambahan ketika orang lain membaca kode saya. Saya pribadi melihat tidak ada masalah dengan itu, selama artinya jelas.

Adapun tipe CLR (int, string, dll.) Anda dapat menggunakan String atau string (dll.) Untuk mendeklarasikan tipe, jadi saya akan menghindari menggunakan sesuatu seperti

int Int = 0;
string String = "hi there";

Membuat kapitalisasi satu-satunya perbedaan itu berbahaya ... terus lakukan ini untuk proyek besar dan saya jamin Anda akan mengalami kesalahan aneh yang tidak dapat Anda temukan.

fastPerson / slowPerson seperti di atas baik-baik saja ... mereka deskriptif dan dibedakan dari nama tipe variabel ... tapi ayolah man, memanggil int "Int" akan menjadi malas.

Saya akan mengatakan itu tidak pernah tidak bermoral - itu benar-benar hanya nama variabel garis dasar Anda. Jika Anda tidak bisa memikirkan nama yang lebih baik, penamaan itu setelah itu tipe adalah standar yang baik (Untuk jenis kompleks. Hanya - untuk dibangun pada jenis yang jahat ) Dan banyak waktu sebenarnya tidak ada nama yang lebih baik menyebabkan Anda don' Saya tidak tahu apa-apa lagi tentang variabel. Suka dengan metode ini

void SaveToDatabase(Person person) {...}

Tentang satu-satunya hal lain yang bisa Anda lakukan untuk menelepon seseorang adalah person_to_save atau sesuatu seperti itu yang tampaknya berlebihan.

Namun dalam banyak kasus, Anda dapat meningkatkan keterbacaan kode Anda dengan mengganti orang dengan nama yang lebih deskriptif. Misalnya ini kurang deskriptif

void AddToAccount(Account account, Person person)  {...}

dari ini

void AddToAccount(Account account, Person dependent)  {...}

Namun tolong, tolong - cukup tolong jangan meletakkan 'a' atau 't' di depan nama jenis. IE aPerson untuk 'a person' atau tPerson untuk 'the person'. Ini terlalu rumit dan tidak menambah banyak nilai. Ditambah Anda mulai mencemari ruang lingkup Anda dengan sekumpulan variabel yang dimulai dengan a atau t yang dapat meminimalkan nilai intelli-sense.

Saya tidak akan mengatakan itu mengerikan. Saya biasanya mengawali nama variabel dengan 'a' dalam hal semacam ini untuk menunjukkan bahwa itu adalah contoh tunggal dari jenisnya, jadi saya akan melakukannya

Person aPerson = new Person();

Itu membuat kode membaca lebih alami menurut saya.

Sama sekali tidak ada yang salah dengan itu tunduk pada peringatan yang ditunjukkan oleh orang lain (meringkas di sini untuk kenyamanan): tidak melakukannya dengan tipe primitif, memfaktorkan ulang instance asli jika instance lain ditambahkan kemudian, tidak menggunakan char-case untuk membedakan nama kelas, dll.

Aturan praktis saya? Pernyataan dalam kode harus dibaca seperti kalimat bahasa Inggris sederhana.

Orang orang = Orang baru ();

Karyawan karyawan = person.getRole (EMPLOYEE);

Induk orang tua = person.getRole (PARENT);

person.getFullName ();

karyawan.getSalary ();

parent.getChildren ();

parent.getFullName (); // mengasumsikan pola dekorator sedang dimainkan

if (person.hasRole (EMPLOYEE)) {

  ...

}

Dan seterusnya.

Jika ruang lingkup variabel terbatas (metode enkapsulasi adalah 10-15 baris, misalnya) saya bahkan mungkin menggunakan 'p' daripada 'person'. Nama variabel yang lebih pendek tidak terlalu mengganggu saat mencoba memahami konteks di kepala Anda. Hindari awalan yang tidak beralasan seperti notasi Hungaria 'a' atau (bergidik) dan cabangnya. (Ingat, saya tidak menentang awalan seperti itu bila digunakan dalam konteks yang sesuai - kode API C ++ / COM / ATL / Win32 dll., Di mana hal itu membantu menjaga tugas / typecasting tetap lurus).

Dua bit (!) Saya :-)