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

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);
    }
}

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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