Apa alasan menggunakan huruf kecil untuk kata pertama dalam variabel lokal (mis., EmployeeCount, firstName)


20

Saya menerima banyak kritik dari programmer lain karena saya menggunakan casing yang tepat untuk semua variabel saya. Sebagai contoh, programer tipikal Anda akan digunakan employeeCountuntuk nama variabel, tetapi saya menggunakan EmployeeCount. Saya menggunakan casing penuh yang tepat untuk semuanya , baik itu metode kosong, metode pengembalian, variabel, properti, atau konstan. Saya bahkan mengikuti konvensi ini dalam Javascript. Yang terakhir benar-benar membuat kegaduhan orang.

Alasan khas yang diberikan mengapa saya tidak harus mengikuti konvensi casing "non-standar" ini adalah karena case yang tepat harus disediakan untuk properti dan metode batal. Variabel lokal dan metode yang mengembalikan nilai harus memiliki kata pertama dalam huruf kecil suka int employeeCount = getEmployeeCount().

Namun, saya tidak mengerti mengapa.

Ketika saya mempertanyakan ini, sepertinya saya hanya mendapatkan jawaban sewenang-wenang dari standar itu . Apa pun jawabannya, biasanya selalu menjadi seperti itu dan saya tidak mempertanyakannya. Saya hanya mengikutinya. . Jawaban sewenang-wenang tidak pernah cukup baik bagi saya.

Sejak hari-hari awal saya memprogram makro Excel 97 dengan Office IDE, saya tidak pernah membutuhkan konvensi casing untuk memberi tahu saya apakah sesuatu itu variabel lokal atau properti. Ini karena saya selalu menggunakan konvensi penamaan yang sangat intuitif. Misalnya, GetNuggetCount()dengan jelas menyarankan suatu metode yang pergi ke suatu tempat dan mendapat hitungan dari semua nugget. SetNuggetCount(x)menunjukkan bahwa Anda menetapkan nilai baru ke hitungan nugget. NuggetCountdengan sendirinya menyarankan properti atau variabel lokal yang hanya memegang nilai. Untuk yang terakhir, orang mungkin tergoda untuk mengatakan, "Ah ha! Itu pertanyaannya. Properti atau variabel? SIAPA ITU?" Untuk itu, saya akan menjawab dengan, "Apakah itu penting?"

Jadi, inilah tl; dr ;: Apa tujuan, logis, alasan non-arbitrer untuk menggunakan huruf kecil untuk kata pertama dalam variabel Anda atau metode pengembalian?

Edit: Untuk MainMa

Ganti kode ini dengan contoh kode pertama dalam jawaban Anda dan lihat seberapa baik argumen Anda bertahan:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var Snapshots = this.LiveMeasurements.IsEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!Snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var MeasurementCount = Measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in Snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

7
Jika mereka berada dalam huruf besar akan ada orang lain yang bertanya mengapa mereka tidak dalam huruf kecil ...
m3th0dman

11
bukankah akan menyenangkan jika IDE kita yang sangat kuat dapat memiliki plugin yang memetakan preferensi pribadi kita untuk masalah gaya seperti ini dan memungkinkan kita untuk menggunakannya tetapi di belakang layar, untuk "versi nyata" dari file sumber, diterapkan semantik gaya "proyek". Ini sepenuhnya merupakan masalah visual sampai Anda perlu mengaudit versi file resmi. hanya bermimpi ...
Sassafras_wot

59
Sayangnya untuk Anda, alasan sebenarnya dan valid adalah "karena itu standar". Membayar orang di tim yang sama untuk mengikuti standar gaya kode yang sama. Jika Anda gagal melihat alasannya, maka mungkin Anda harus mengajukan pertanyaan lain: "mengapa standar bermanfaat?"
Andres F.

3
Saya selalu berasumsi bahwa pengembang memilih camelCase karena terlihat kewl. Tidak ada alasan 'obyektif' untuk camelCase sendiri di atas PascalCase. Saya pribadi menemukan PascalCase (seperti contoh Anda) lebih mudah dibaca, dan menggunakannya di sebagian besar tempat selain JavaScript, tempat saya menyimpan camelCase, jadi saya tidak akan ketinggalan undangan pesta.
GrandmasterB

7
Penelitian tentang Keuntungan Memiliki Gaya Pengodean Standar. Tidak peduli apa standarnya, hanya saja itu diikuti.
Mr.Mindor

Jawaban:


88

Konvensi penamaan sering digunakan ketika orang ingin dapat memberikan variabel nama yang sama dengan tipenya. Sebagai contoh:

Employee employee;

Beberapa bahasa bahkan memberlakukan kapitalisasi itu. Mencegah ini harus menggunakan nama variabel yang menjengkelkan seperti MyEmployee, CurrentEmployee, EmployeeVar, dll Anda dapat selalu mengatakan jika sesuatu adalah jenis atau variabel, hanya dari kapitalisasi. Itu mencegah kebingungan dalam situasi seperti:

employee.function(); // instance method
Employee.function(); // static method

Selain itu, dalam bahasa Inggris, kata benda biasanya tidak memiliki huruf besar, jadi Anda tidak dapat benar-benar mengklaim bahwa huruf besar Anda "benar."

Jadi apa hubungannya dengan situasi Anda? Anda jelas tidak kesulitan membaca kode Anda sendiri, tetapi dengan menjaga hal-hal yang konsisten, Anda mengurangi beban kerja mental orang lain yang perlu membaca kode Anda. Dalam menulis kode seperti dalam tulisan, Anda menyesuaikan gaya Anda agar sesuai dengan pembaca.


1
Perhatikan bahwa masalah masih ada dalam bahasa yang digunakan oleh OP, karena properti dikapitalisasi (tentu saja, properti dapat diawali dengan this., yang menghindari kebingungan; variabel lokal tidak dapat memiliki awalan seperti itu).
Arseni Mourzenko

1
@oscilatingcretin disebut PascalCase.
Mr.Mindor

21
Employee Employeeberfungsi, tapi saya akan berpendapat bahwa itu lebih membingungkan bagi pembaca manusia daripada Employee employee. Yang terakhir terlihat seperti dua hal yang berbeda. Yang pertama terlihat seperti pengulangan yang tidak perlu.
Jamie F

14
@oscilatingcretin Persis: "mengasumsikan bahwa pembaca memahami kerangka dasar ..." Saya suka membaca JavaScript, Java, C #, C ++, dan lainnya dan menerjemahkan kode di kepala saya. Saya tidak suka harus terus berpikir, "Oh, kompiler bahasa ini dapat menangani x ." sementara saya hanya mencoba untuk mendapatkan arti dari kode tersebut.
Jamie F

1
Catatan yang employee.function()juga bisa menjadi metode statis, jika bahasa memungkinkan memanggil metode statis dari suatu objek (seperti Java). Kompiler memberikan peringatan, tetapi diizinkan untuk melakukannya.
Uooo

34

Tidak ada. Itulah yang dilakukan kebanyakan orang, sehingga menjadi standar karena itulah yang dilakukan setiap orang. Banyak literatur mengikuti kebaktian ini sehingga orang-orang mengambil kebiasaan itu.

Konvensi ini tidak sepenting konsistensi di seluruh kode. Selama semuanya dinamai secara konsisten sehingga saya dapat mengetahui hal-hal apa dari melihatnya, tidak masalah apakah huruf pertama ditulis dengan huruf besar atau tidak.

Saya akan menemukan itu menggelegar untuk menemukan kode yang ditulis dengan cara Anda dan akan mengatakan bahwa saya tidak menyukainya. Tapi itu masalah gaya.

Sekarang jika Anda melakukan ini di tempat kerja, akan lebih baik untuk kode dengan gaya tim sehingga kode tetap konsisten di mana-mana. Daripada memiliki kode Anda berbeda dari orang lain.

http://thecodelesscode.com/case/94


3
Saya berharap sebagian besar programmer seperti Anda. Banyak yang sangat bersemangat dan / atau dogmatis tentang mengikuti standar selubung yang telah saya sebutkan.
oscilatingcretin

1
@ Skie itu penting jika Anda adalah programmer berikutnya untuk mengerjakan proyek.
N4TKD

3
@oscilatingcretin Anda mungkin akan menjadi sangat bersemangat dan / atau dogmatis setelah Anda mengerjakan kode yang penuh var m_someVariableID = GetVariableValueId(). Terutama jika Anda harus melakukannya tanpa dukungan pelengkapan otomatis.
Tacroy

7
Jika Anda berada dalam tim, mengikuti standar tim itu penting. Namun, perhatikan bahwa banyak bahasa pemrograman memiliki standar de facto yang harus Anda coba ikuti, ketika membuat proyek baru di mana tim tidak memiliki standar (atau di mana tim telah meminta Anda untuk mengaturnya). Jika Anda tidak yakin konvensi pengkodean apa yang akan digunakan, mengikuti konvensi yang digunakan oleh vendor bahasa utama atau kerangka kerja yang disertakan lebih disukai daripada standar Anda sendiri, kecuali jika Anda dapat membenarkan standar Anda.
Brian

2
@Schleis pembaruan bagus, saya tidak setuju itu hanya masalah gaya, tetapi konvensi dan konvensi menjadi konvensi untuk alasan yang baik dan harus diikuti. Ini bukan agama dan suatu saat Anda harus sangat dari konvensi, tetapi Anda harus memiliki alasan yang baik.
N4TKD

25

1. Mengapa standar itu ada?

Lagipula, bukankah lebih baik membiarkan semua orang menulis kode sesuai dengan preferensi pribadi, dan berhenti berbicara tentang standar mana yang lebih baik?

Faktanya adalah bahwa ketika Anda terbiasa dengan satu gaya, lebih sulit untuk membaca kode yang menggunakan gaya yang berbeda. Otak Anda menghabiskan lebih banyak waktu untuk mencoba memahami konvensi (jika ada), daripada memahami apa yang dilakukan kode.

Apa yang lebih mudah dibaca di antara kedua kode itu?

public void comp_metrics ()
{
  int Count;
  List<snapshot> measurements=fromMemoryStorage();
  if (_liveMeasurements.enabled)
    measurements = GrabSnapshots(20, _cache);
    if( !measurements.Any() ) {
        this.Report(LogMessage.Measurements_Are_Empty); return;
    }

    Count = measurements.Count ();

    this.Chart.initialize(( Count + 1 )*2);

    foreach(snapshot S in measurements) {
      this.Chart.append_Snapshot ( S );
    }
}

atau:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var snapshots = this.liveMeasurements.isEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var count = measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

Kedua bagian kode mengeksekusi dengan cara yang sama. Satu-satunya perbedaan adalah bahwa dalam kasus pertama, setiap pengembang yang mengerjakan proyek menggunakan gayanya sendiri. Ini membuat kode tidak konsisten, tidak dapat dibaca, dan berbahaya. Fakta bahwa anggota tim tidak dapat menyetujui tentang ukuran indent, ditambah dengan fakta bahwa salah satu dari mereka menolak untuk menggunakan kurung kurawal setelah setiap ifmembuat kode sangat rawan kesalahan: melihat itu, kita mungkin percaya bahwa yang kedua ifadalah dieksekusi hanya ketika yang pertama ifbenar, yang tidak terjadi.

Dalam kasus kedua, semua pengembang mengikuti standar yang sama. Beberapa dari mereka mungkin tidak senang, karena mereka lebih suka dua spasi indentasi atau karena mereka terbiasa dengan metode yang dimulai dengan huruf kecil. Faktanya adalah bahwa kode ini masih jauh lebih mudah dibaca dengan cara ini, dan masih akan terjadi jika mereka menggunakan standar yang berbeda.

Dengan memiliki standar yang ketat dan seragam, itu membuat kode lebih mudah dibaca.

2. Mengapa standar mereka lebih baik daripada yang saya temukan saat ini?

Jika standar digunakan oleh ratusan ribu pengembang di seluruh dunia, patuhi saja. Jangan menciptakan milik Anda sendiri: meskipun lebih baik, lebih mudah bagi Anda untuk bermigrasi ke standar global daripada ratusan ribu pengembang untuk mulai menggunakan milik Anda.

Contoh: di perusahaan saya sendiri, saya memiliki konvensi khusus untuk penamaan kunci dan indeks utama dan asing dalam database. Nama-nama itu terlihat seperti:

  • [FK for Application: CreatedByApplicationId],
  • [IX for SessionIPAddress: SessionId] atau
  • [PK for RoleOfPassword: RoleId, PasswordId].

Secara pribadi, saya menemukan konvensi ini sangat bagus dan sangat jelas. Untuk saya. Tapi itu benar-benar menyebalkan. Itu menyebalkan, karena itu milik saya, dan karena tidak satu pun dari ribuan administrator database tidak pernah menggunakannya. Ini berarti:

  • Ketika saya akan menyewa DBA, dia akan dipaksa untuk belajar konvensi baru, daripada memulai pekerjaannya sekarang,

  • Saya tidak dapat membagikan potongan-potongan kode di internet sebagaimana adanya: nama-nama aneh itu akan mengganggu orang yang akan membaca kode saya,

  • Jika saya mengambil kode dari luar untuk menggunakannya di saya sendiri, saya akan dipaksa untuk mengubah nama untuk membuatnya seragam,

  • Jika suatu hari saya memutuskan untuk menggunakan beberapa standar yang terkenal, saya akan dipaksa untuk pergi dan memodifikasi setiap dari beberapa ratus nama.

3. Jadi, bagaimana dengan kapitalisasi?

Properti memiliki cakupan atau visibilitas yang lebih besar daripada bidang atau variabel lokal. Membuat properti dimulai dengan huruf kapital, dan bidang dan variabel - dengan yang kecil mengarah ke arah ini.

Jika Anda menganggap C #, logika ini cukup konsisten.

Jika Anda mempertimbangkan Java, metode dimulai dengan huruf kecil, yang tidak mengikuti logika.

Jadi tidak, tidak ada bukti definitif bahwa konvensi ini lebih baik daripada konvensi Anda. Hanya saja yang digunakan secara global, dan milik Anda tidak. Tidak ada yang lebih baik .

Dalam JavaScript, fungsi dimulai dengan huruf kecil, kecuali jika diperlukan newsebelum. Bukankah lebih baik sebaliknya? Mungkin. Faktanya adalah bahwa selama bertahun-tahun, pengembang JavaScript menggunakan standar ini, dan bukan sebaliknya. Menulis ulang setiap buku dan memaksa setiap pengembang untuk mengubah gaya sekarang akan sedikit rumit.


1
Adapun bagian tentang kode menjadi kurang dapat dibaca karena mengikuti standar yang sedikit berbeda, saya tidak pernah punya masalah itu. Kecuali jika variabel seseorang dinamai seperti hookyDookyDoo, konvensi penamaan atau casing tidak mengurangi keterbacaan. Juga, perlu diingat bahwa saya tidak mengatakan konvensi saya "lebih baik" karena tidak benar-benar membawa sesuatu yang istimewa ke tabel dev. Terakhir, saya tidak mengerti maksud Anda [Properti memiliki cakupan lebih besar ... menuju ke arah ini] . Apa hubungannya ruang lingkup dengan konvensi casing? Pergi ke arah mana?
oscilatingcretin

23
@ Scilatingcretin, pertanyaannya bukan apakah Anda pernah mengalami masalah itu, tetapi apakah rekan Anda pernah. Jelas mereka miliki, atau mereka tidak akan mengeluh.
Karl Bielefeldt

1
Re: suntingan Anda: Contoh kode pertama Anda menunjukkan kode rawan bencana yang dibangun dengan buruk. OP saya bukan tentang kode rawan bencana yang dibangun dengan buruk. Ini tentang kode yang sama persis dengan contoh kedua Anda, tetapi konvensi casing yang berbeda. Saya mengedit contoh kode kedua Anda dan mempostingnya di OP saya dengan konvensi casing saya. Ganti itu dengan contoh kode pertama Anda, silakan.
oscilatingcretin

5
@oscilatingcretin: Contoh kode pertama menunjukkan kode yang tidak dibangun dengan buruk, tetapi kode yang ditulis oleh tim di mana setiap pengembang mengikuti gayanya sendiri. Ini terjadi dengan terlalu banyak basis kode, diberikan waktu yang cukup (misalnya lima tahun). Catatan: apakah Anda melewatkan: "Faktanya adalah bahwa kodenya masih jauh lebih mudah dibaca dengan cara ini, dan akan tetap demikian jika mereka menggunakan standar yang berbeda." ?
Arseni Mourzenko

6
@oscilatingcretin Ada banyak penelitian yang menunjukkan konsistensi secara signifikan mengurangi upaya kognitif yang diperlukan untuk memahami sesuatu yang Anda baca. Untuk prosa reguler, ejaan yang buruk, tanda baca yang buruk, dan tata bahasa yang buruk semuanya membuat seseorang lebih sulit untuk membaca - apakah mereka memperhatikannya secara sadar atau tidak. Kode cukup sulit untuk dibaca, tanpa membuatnya lebih sulit - kepatuhan pada "standar umum" (untuk tumpukan pilihan teknologi Anda) meningkatkan konsistensi keseluruhan, dan membebaskan neuron untuk berkonsentrasi pada bisnis penting dari apa yang kode lakukan, alih-alih bagaimana ada tertulis.
Bevan

10

Secara teknis, itu tidak masalah (atau setidaknya, dalam sebagian besar bahasa itu tidak penting).

Namun, sebagian besar komunitas pemrograman (apakah mereka adalah komunitas di seluruh dunia yang telah membentuk sekitar satu bahasa tertentu, sub-kelompok dari komunitas tersebut, kelompok-kelompok yang telah terbentuk di sekitar perpustakaan atau toolkit populer, atau hanya tim individu) telah mengembangkan standar pengkodean yang telah ditetapkan. Persis rincian yang relatif tidak penting (meskipun dalam banyak kasus, argumen yang baik dapat dibuat untuk mereka), apa yang penting adalah bahwa Anda tetap pada mereka.

Bukan karena mereka yang terbaik, tetapi karena mereka adalah yang digunakan orang lain; jika Anda tetap menggunakan standar, kode Anda akan konsisten dengan sebagian besar kode lain yang pada akhirnya akan Anda gunakan - pustaka, kode rekan tim, bahasa bawaan. Penamaan yang konsisten adalah salah satu senjata produktivitas yang kuat, karena itu berarti bahwa ketika Anda menebak nama sesuatu, Anda biasanya akan menebak dengan benar. Apakah itu file.SaveTo(), File.saveTo(), file.save_to(), FILE.save_to()? Konvensi penamaan akan memberi tahu Anda.

Membawa preferensi pribadi Anda ke dalam setiap bahasa yang Anda temui sangat berbahaya, karena pertama-tama, setiap bahasa memiliki budaya sendiri, dan konvensi penamaan seringkali tidak sesuai; dan kedua, ada banyak perbedaan halus antara bahasa sejauh menyangkut penamaan.

Hanya satu contoh: di C #, tipe dan variabel tinggal di ruang nama yang terpisah; kompiler cukup pintar untuk mengetahui perbedaannya. Namun, di C, kedua jenis nama tersebut berbagi ruang nama, sehingga Anda tidak dapat memiliki tipe dan variabel nama yang sama dalam cakupan yang sama. Karena itu, C membutuhkan konvensi penamaan yang membedakan tipe dari variabel, sementara C # tidak.


Jadi benar-benar tampak bahwa beberapa bahasa lama telah membuka jalan untuk standar pengkodean bahasa masa depan (seperti contoh C / C # Anda). Itu sangat disayangkan karena harus melacak bagaimana variabel kasus dan anggota objek hanya menambah tingkat kompleksitas yang tidak perlu yang dapat dilakukan tanpa.
oscilatingcretin

4
@oscilatingcretin Ketika semua orang menggunakan konvensi yang sama, itu tidak menambah kompleksitas yang sedang berlangsung, konvensi menjadi bagian dari model mental Anda untuk bahasa yang dipertanyakan DAN memudahkan penggunaan bahasa itu. Ini bisa dibuktikan dan diukur.
Mr.Mindor

Saya akan memilih Anda tetapi Anda pertama kali mengatakan bahwa itu tidak masalah maka Anda menulis beberapa paragraf yang menjelaskan mengapa itu penting. Jika Anda menghapus "tidak masalah" di awal saya akan memilih Anda.
Tulains Córdova

10

Saya terkejut tidak ada orang lain yang mengatakan ini, tapi saya pikir perbedaan kapitalisasi sangat membantu karena satu alasan: itu bagus dan nyaman untuk dapat mengetahui apakah suatu variabel hanya dibatasi secara lokal atau tidak. Jika variabelnya lokal, saya tidak terlalu khawatir tentang efek samping mengubahnya, seperti refactoring nama. Jadi saya suka konvensi yang membedakan anggota kelas versus variabel kelas privat versus variabel lokal.

Dengan Intellisense modern, ini semakin penting, tetapi masih memberi saya beberapa landmark ketika saya membaca kode untuk mengetahui di mana saya harus mencari untuk menemukan definisi.

Dan sedikit ini mungkin tersisa dari gaya buruk saya tahun yang lalu, ketika metode tidak mungkin cocok pada satu layar.


Sejumlah proyek yang saya kerjakan menentukan sesuatu seperti ini di panduan gaya mereka.
anaximander

7

Ini tampaknya lebih seperti masalah konvensi daripada konvensi spesifik Anda.

Untuk setiap konvensi yang Anda hancurkan, Anda hanya menambahkan lebih banyak pekerjaan untuk semua orang. Mungkin di dunia yang sempurna, seluruh perusahaan mengerjakan satu produk sepanjang hidup mereka ... namun, pada kenyataannya, ini tidak benar. Orang-orang melompat di antara proyek, kadang-kadang di perusahaan atau bahkan untuk bersenang-senang. Semakin acak kode ini, semakin sulit dan mahal untuk dikerjakan. Sebagai pemilik bisnis atau pemangku kepentingan, saya tidak ingin mempekerjakan pengembang yang berpikir egois daripada demi kebaikan proyek.

Ini bermuara pada profesionalisme: kadang-kadang kita perlu mengesampingkan gaya pribadi kita dan pergi dengan apa yang lebih efisien untuk adopsi massa. Ini mendorong kolaborasi dan menghilangkan hambatan asing yang seharusnya tidak ada di tempat pertama.

Adapun konvensi Anda yang sebenarnya, CapitalCamelCase biasanya dicadangkan untuk nama kelas (atau dalam Javascript, konstruktor). Jika saya melihat variabel dengan huruf besar, tebakan yang berpendidikan akan menentukan saya harus membuat Instantiate untuk menggunakannya. Jika itu salah, saya akan kesal karena kode tersebut tidak mengikuti standar komunitas. Bahkan dengan sebagian besar bahasa lain, semua orang yang melihatnya untuk pertama kali langsung tersesat. Saya ingin kode menjadi jelas, bukan menyesatkan.


"Jika saya melihat variabel dengan huruf besar, tebakan yang berpendidikan akan menentukan saya harus membuat instantiate untuk menggunakannya." Saya tidak mengerti. Bagaimana melihat variabel dengan huruf kapital membuat Anda berpikir Anda harus membuat instantiate sebelum menggunakannya? Karena itu terlihat seperti nama kelas? Jadi, Anda tidak tahu perbedaan antara MyClass MyClass = nulldan class MyClass { }?
oscilatingcretin

3
Ya, saya melihat perbedaannya. Konvensi itu ada untuk mencegah ambiguitas. var car = new Car();Sesuai baris terakhir saya - mengapa tidak membuatnya jelas?
Adrian Schneider

3
@oscilatingcretin Ada perbedaan, tentu saja. Tetapi otak manusia mendapat manfaat dari isyarat visual yang tidak dibutuhkan oleh parser komputer. Sepertinya Anda mempertanyakan perlunya konvensi / standar ... yang merupakan pertanyaan valid, jika berbeda dari yang Anda tanyakan sebelumnya.
Andres F.

2

"karena case penuh yang tepat harus disediakan untuk properti dan metode void. Variabel lokal dan metode yang mengembalikan nilai harus memiliki kata pertama dalam huruf kecil" dan karena itu adalah konvensi standar.

Pemrogram lain sedang menarik kode Anda sekarang dan berpikir ini adalah properti dan itu benar-benar variabel lokal, Anda membuat pekerjaan mereka lebih sulit.


1
Apakah Anda membaca pertanyaan saya sepenuhnya? Lihatlah ke ujung di mana saya berkata:NuggetCount all by itself suggests a property or local variable that is simply holding a value. To that last one, one may be tempted to say, "Ah ha! That is the question. Property or variable? WHICH IS IT?" To that, I'd reply with, "Does it really matter?"
oscilatingcretin

8
Ya dan Ya itu penting, programmer berikutnya seharusnya tidak perlu memikirkan NuggetCount, Anda harus dapat melihat nama dan memberi tahu. Buku yang bagus untuk dibaca adalah "Kode Bersih" Anda harus bisa membaca kode seperti cerita dan tahu apa yang terjadi.
N4TKD

2
@oscilatingcretin Saya pikir frustrasi yang Anda lihat dengan orang-orang yang menjawab pertanyaan yang sedikit berbeda dari yang Anda tanyakan adalah bukti dari kebingungan yang dapat dihasilkan ketika Anda melanggar konvensi yang diterima.
Mr.Mindor

7
Konvensi membawa makna. Jika menurut konvensi, NuggetCount mengimplikasikan sebuah properti, itu berarti ia memiliki ruang lingkup melebihi apa yang variabel lokal miliki. Yang berarti saya harus meneliti lebih banyak untuk menentukan ruang lingkup itu. Saya perlu menentukan: Apakah ada efek samping untuk mengubahnya? Dapatkah saya mempercayai nilainya untuk tidak diubah oleh utas lain saat saya menggunakannya? nuggetCount menyiratkan ruang lingkup lokal dan saya harus dapat menganggap keseluruhan ceritanya lokal.
Mr.Mindor

5
@creatingcretin YA! Persis! Saya percaya bahwa apa yang mereka tulis mengikuti kebaktian dan membawa serta semua yang menyertainya. Saya percaya mereka bekerja sebagai bagian dari tim dan saya bisa memetik manfaat dari menggunakan konvensi itu (mengetahui apa nuggetCount secara sekilas) Jika mereka tidak melakukannya, saya mungkin melakukan apa yang telah dilakukan rekan kerja Anda: Saya mencoba mendidik yang bertanggung jawab , dan saya membuang lebih banyak waktu lain kali saya harus mengikuti mereka dengan tidak percaya. Dengan tidak mengikuti konvensi, mereka telah menghasilkan kode yang kurang mudah dibaca dan kurang dapat dikelola. Apakah Anda punya alasan untuk menentang konvensi?
Mr.Mindor

0

Seperti yang orang lain katakan tidak ada alasan sebenarnya, kecuali untuk mendapatkan konvensi penamaan. Jika Anda bisa membuat seluruh tim Anda berada di halaman yang sama, Anda mungkin bisa menghemat waktu. Sebagai contoh secara pribadi saya memulai standar pengkodean hal yang masuk ke ini dan kami menggunakan camelCase untuk semua varian pribadi serta hal-hal yang dilewati olehVal, sedangkan kami menggunakan PascalCase untuk hal-hal yang bersifat publik serta hal-hal yang disahkan oleh Ref.

Garis menjadi sedikit buram ketika berhadapan dengan hal-hal seperti dilindungi atau Keluar atau sesuatu.


-2

Bahasa (dengan aspek formal dan konvensional) penting untuk mengatur pemikiran Anda, ia memiliki kekuatan atas cara berpikir Anda. Jadi itu hanya rasa sakit untuk berpindah dari satu gaya ke gaya lainnya.

Simbol huruf kecil dan huruf besar memiliki perbedaan semantik besar di Haskell, juga perbedaannya sedikit di Scala dan saya telah menggunakan keduanya. Bahasa lain yang saya gunakan tidak membuat perbedaan antara kedua jenis pengidentifikasi ini, tetapi menjaga pikiran agar Haskell memahami pengidentifikasi jauh lebih mudah bagi saya daripada memecah-mecah pikiran saya untuk bahasa yang berbeda.


-2

Bagi saya itu adalah harapan.

Ketika saya membaca sebagian besar kode, saya mengharapkan sesuatu yang dimulai dengan lowerCasemenjadi variabel lokal atau fungsi (dalam C # itu hanya variabel). Jika saya melihat variabel lokal ProperCase, saya mungkin akan tersandung dan bingung untuk sementara waktu, berpikir bahwa itu adalah nama kelas atau properti atau sesuatu yang lain. Itu akan menyebabkan saya membaca ulang kode, dan akan mengganggu saya.

Kemungkinan itulah yang terjadi dalam kasus Anda.

Plus, lebih mudah untuk mengetahui peran apa yang dimainkan variabel hanya dengan melihat huruf pertama, dan itu menghindari bentrokan antara nama instance dan nama kelas.


-3

Huruf kecil harus digunakan untuk variabel lokal untuk kemudahan mengetik (kecepatan / tidak ada tombol shift). Huruf besar digunakan untuk membantu keterbacaan dengan memisahkan kata-kata di dalam nama. Kode dengan nama variabel lokal satu kata (yang seharusnya umum) cepat dan mudah diketik. Penggunaan huruf besar untuk setiap kata baru dalam nama juga lebih cepat (dan lebih sedikit ruang) daripada menggunakan garis bawah yang menambahkan karakter lain - ini juga dikenal sebagai kasus unta.


Saya pikir ini adalah jawaban yang sangat bagus dan saya tidak mengerti down-vote. Ini jawaban logis - berdasarkan fakta seperti yang diminta oleh OP. Jika Anda memilih, mohon jelaskan diri Anda. Menekan tombol shift di semua tempat sangat besar. Pikirkan tentang hal ini, hampir setiap kata yang Anda ketikkan dalam kode Anda akan memulai PascalCase dan untuk setiap kata Anda akan perlu menekan tombol shift lain. Jika Anda ingin menjadi minimalis dan efektif masuk akal untuk menghapus penekanan tombol shift yang tidak perlu. Dan secara logis Anda ingin menjadi lebih produktif, yang dari tempat saya berdiri berarti lebih sedikit menekan tombol. Mengapa lebih banyak menekan?
AIon

-3

Saya setuju dengan OP di sini. camelCase terlihat salah. Saya juga setuju dengan kenyataan bahwa itu adalah standar dan kita harus tetap berpegang pada standar yang sama atau apa gunanya memiliki standar. Ini juga masuk akal bahwa PascalCaps digunakan untuk metode dll dan camelCase untuk variabel Anda sendiri dll sebagai cara untuk membedakan ketika tidak menggunakan IDE yang mewarnai metode untuk Anda.

Untuk menyiasatinya, saya selalu mengawali nama objek saya dengan jenis objeknya. Jadi jika itu adalah variabel string yang saya sebut strMyVariable. Jika itu adalah semacam objek saya menyebutnya objMyObject, dll. Dengan begitu ia dimulai dengan topi kecil sesuai standar dan terlihat benar.


3
ini tampaknya tidak menawarkan sesuatu yang substansial atas poin yang dibuat dan dijelaskan dalam 11 jawaban sebelumnya
nyamuk
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.