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


95

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.


Saya selalu bertanya-tanya tentang ini. Pertanyaan bagus!
William Brendel

18
Menyebut seseorang itu kejam. Ada apa dengan "bob"?
Sam Meldrum

17
Jangan lupa sebelum var ada keindahan zen dari Person person = new Person ();
Jamie Ide

1
@Jamie apakah Anda menelepon mengetik statis seperti zen?
orokusaki

Saya ingin melangkah lebih jauh ke dalam pertanyaan ini: Apakah hal ini benar-benar salah Person Person=new Person();? Seperti yang dinyatakan dalam The Question, kita hidup di masa penyorotan sintaks yang luar biasa dan pengenalan konteks yang tidak pernah dikeluhkan oleh compiler saya saat melakukan hal itu. Saya hanya menyukai variabel saya CamelCased - mengapa tidak saya (dalam situasi di mana Person Personinstansiasi umum dan hanya kelas dan tidak ada konflik yang hadir atau mungkin)?
Robert Synoradzki

Jawaban:


94

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.


8
"Apa alasan mereka mengatakan ini buruk?" - Entahlah. Itulah mengapa saya memulai topik ini. :-)
Jason Baker

Jelas Anda tidak pernah harus masuk ke kode orang lain. Saya tahu bahwa ketika saya dipanggil untuk meneliti beberapa bug yang baru ditemukan dalam kode beberapa tahun oleh seorang programmer yang sudah lama meninggalkan perusahaan - apa pun yang menghalangi saya adalah waktu untuk tidak memperbaiki masalah. Jika salah satu kendala itu mencoba mencari tahu apa itu instance dan apa itu kelas hanya karena programmer tidak mau repot-repot mengatakan "var currentPerson = New Person ();" maka itu tidak berguna, waktu yang terbuang. ... dan ketika pelanggan Anda menunggu perbaikan, waktu adalah yang terpenting.
David

3
@David - Anda menangkap saya! Saya tahu bahwa pengkodean dalam ruang hampa akan memunculkan kepalanya yang jelek cepat atau lambat :) Namun serius - saya merasa sulit untuk percaya bahwa Anda tersandung karena tidak dapat membedakan antara jenis dan contoh mereka berdasarkan pada konvensi penamaan ini.
Andrew Hare

2
@David - itu seharusnya menjadi masalah untuk alat analisis kode. Juga, itulah mengapa ada konvensi bahwa tipe dimulai dengan huruf besar dengan Python.
ilya n.

69

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.


1
"Apa yang salah jika Anda memiliki dua tipe Orang dan satu orang maka itu sangat salah." - Ini sangat masuk akal bagiku.
Jason Baker

1
Jika Anda membuat API VB tidak akan dapat menangani kode karena tidak peka huruf besar / kecil.
JoshBerke

1
Hei, dalam kasus API Anda terganggu tentang nama atau properti metode publik, bukan nama variabel, karena yang terakhir tidak akan diekspos ke kode klien. Adapun pertanyaan Jason, saya juga menggunakan penamaan ini sepanjang waktu. Sama sekali tidak ada yang salah dengan itu.
Frederick The Fool

1
Persis maksud saya Frederick mengapa memiliki dua jenis yang berbeda hanya kasus dasar adalah ide yang buruk ;-)
JoshBerke

1
Bahkan jika tidak salah, itu membuat kode lebih sulit untuk dibaca. Keterbacaan juga penting.
J3r3myK

45

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 benar-benar tidak ada makna semantik, saya dapat memberikan primitif, saya akan menggunakan i atau s, selain indeks loop, saya tidak dapat memikirkan skenario lain seperti itu.
AnthonyWJones

1
Saya akan merekomendasikan untuk tidak menggunakan i, terutama jika Anda menulis kode dengan loop. i hampir secara universal dianggap sebagai nama variabel loop.
Jason Baker

3
Sepakat. Sebuah nama variabel huruf tunggal berteriak "Saya sementara." Indeks loop harus i, j, k, lainnya harus a, b, c, x, y, z, atau huruf lain yang tidak dapat disalahartikan sebagai hal lain, seperti l dan o.
Bill the Lizard

bravo! 42 terlalu banyak. :)
Vishal Seth

18

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

var abc = new Person();

2
@ Chris: persis! Atau lebih baik lagi: var temp = new Person();(Penafian: Saya tahu benar-benar ada tempat untuk satu kali menggunakan variabel sementara, tetapi seringkali tidak ketika saya melihat ini di kode seseorang, penulis tidak pernah kembali untuk memberi var nama yang sesuai dan mungkin juga menjadi "abc".)
Dinah

15

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.


9

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.


6
Atau, jika keputusan moral yang bisa kita buat tidak begitu penting, kita dikutuk. Saya tidak yakin saya ingin pidato pemakaman saya berkonsentrasi pada gaya pengkodean saya. Saya ingin setidaknya sekilas menyebutkan bahwa saya adalah bagian dari sebuah keluarga.
David Thornley

1
@David: Benar lagi. Dengan cucu pertamaku dalam perjalanan, kurasa itu basi, tapi aku peduli dunia macam apa yang akan kita turunkan.
Mike Dunlavey

8

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.


6

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.


6

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.


3

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.


3

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.


3

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.


3

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.


Hai lagi David. Saya tidak ingat apakah Anda yang mengedit salah satu posting saya karena saya telah menulis "pollish", atau apakah itu "polish", ketika saya bermaksud untuk menggosok sesuatu sampai bersinar? Baiklah, saya masih tidak yakin mana yang benar :-)
Mike Dunlavey

Saya tidak berpikir saya membuat perubahan seperti itu, jadi mungkin orang lain. BTW, itu "polesan".
David Thornley

2

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()

2
Itu akan lebih buruk, menurut saya. Ini lebih sulit untuk dibaca dan tidak memberikan informasi tambahan apapun.
Joachim Sauer

Ya tapi setidaknya namanya berbeda dari nama kelas, yang jelas mereka inginkan.
Gerrie Schenck

Itu akan mengikuti hukum yang berlaku, tapi jelas bukan rohnya.
Joachim Sauer

1
+1, Saya menggunakan thePerson untuk parameter dan myPerson untuk penduduk lokal yang saya kelola.
Amy B

2

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).


2

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 .


2

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.


Sebut saja anonim! :)) var anonymous = new Person (); Atau bahkan lebih baik: var you_know_who = new Person (); :))
Vadim Ferderer

@Vadim Ferderer: var he_who_must_not_be_named = new Person();? :-)
Platinum Azure

2

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


1

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. :)


1

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 :)


1

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'.


1

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.


Satu-satunya hal yang saya tidak suka tentang pendekatan ini adalah bahwa variabel yang diawali dengan satu garis bawah cenderung dikaitkan dengan anggota privat kelas. Tetapi saya kira pendekatan umum itu layak.
Jason Baker

Ya, inilah yang saya ilustrasikan di sini. Mendefinisikan variabel lokal, seperti 'Redupkan orang sebagai Orang Baru' tidak masalah. Sangat (sangat) kadang-kadang dengan kompilator VB, ada ambiguitas, dan kapitalisasi otomatis meyakinkan yang normal tidak terjadi. Ini adalah petunjuk visual yang bagus bahwa semuanya tidak baik.
ChrisA

1

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.


1

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 #.


enum hanya mendukung byte, sbyte, short, ushort, int, uint, long, ulong. yaitu jenis nilai numerik non pecahan
Kev

1
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.


1

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";

1

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.


1

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 setuju dengan paragraf terakhir. Saya tidak melihat alasan untuk menambahkan karakter asing hanya untuk menghindari masalah gaya kecil.
Jason Baker

0

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.


0

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 :-)

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.