Apakah ada konvensi kapitalisasi umum dalam C ++? [Tutup]


13

Saya melakukan banyak pekerjaan dalam Python dan Java, dan kedua bahasa tersebut memiliki konvensi yang cukup umum (meskipun tidak universal) tentang bagaimana kapitalisasi harus digunakan dalam pengidentifikasi: keduanya digunakan PascalCaseuntuk nama kelas dan ALL_CAPSuntuk konstanta "global", tetapi untuk pengidentifikasi lain banyak menggunakan kode Java mixedCasesedangkan banyak menggunakan kode Python underscore_delimiters. Saya tahu bahwa tidak ada bahasa atau pustaka yang memberlakukan kapitalisasi tertentu, tetapi saya telah menemukan bahwa ketika saya tetap pada konvensi standar untuk bahasa yang saya gunakan, kode saya tampaknya jauh lebih mudah dibaca.

Sekarang saya memulai proyek dalam C ++, dan saya ingin menerapkan ide yang sama. Apakah ada konvensi paling umum untuk huruf besar yang harus saya ketahui?


Masalah dengan camelCase adalah ia tidak bermain dengan baik dengan preprocessor. Bukan masalah besar, terutama karena preprocessor biasanya dapat dihindari.
Pubby

Saya harus menghadapi keputusan ini hanya beberapa hari yang lalu. Pada akhirnya, itu adalah no-brainer, karena perpustakaan standar dan boost menggunakan underscore_lowercase_delimiters. Karena saya menggunakan boost sebagai penguat STL, itu akan menaburkan semua tentang kode saya. Pustaka lain yang saya gunakan yaitu PascalCase (SFML) dapat lebih mudah dimuat sehingga metode apa pun yang diberikan cukup standar.
Maks.

@ Pubby8: ingin tahu: bagaimana camelCase berbenturan dengan preprocessor?
Joachim Sauer

@ JoachimSauer Kata-kata individual di camelCase mungkin memiliki case yang berbeda, tetapi macro tidak dapat mengubah case. Ini menjadi masalah jika Anda ingin makro yang mengambil bagian dari kata sebagai argumen - Anda mungkin harus menyediakan kedua kasus sebagai argumen: makro (x, X). Ini masalah yang cukup kecil, tetapi harus diketahui jika Anda bermaksud menggunakan preprosesor.
Pubby

Jawaban:


27

Apakah ada konvensi paling umum untuk huruf besar yang harus saya ketahui?

C ++ didasarkan pada C, yang cukup tua untuk mengembangkan sejumlah konvensi penamaan pada saat C ++ diciptakan. Kemudian C ++ menambahkan beberapa, dan C juga tidak menganggur dengan memikirkan yang baru juga. Tambahkan ke bahwa banyak bahasa yang diturunkan C, yang mengembangkan konvensi penamaan C penemu mereka lebih lanjut, ke titik di mana mereka kembali menyuburkan pada C dan C ++ ... Dengan kata lain: C ++ tidak memiliki satu, tetapi banyak dari konvensi semacam itu.

Namun, jika Anda mencari satu konvensi penamaan, Anda mungkin juga melihat konvensi penamaan perpustakaan standar , karena ini adalah satu-satunya yang harus diketahui dan digunakan oleh semua pengembang C ++.

Namun, apa pun yang Anda gunakan aturan yang paling penting adalah: Bersikaplah konsisten!

Menariknya, ketika saya mulai dengan campuran PascalCase dan camelCase, dan terlibat dalam banyak proyek dengan konvensi penamaan yang lebih banyak lagi, selama bertahun-tahun saya merasa semakin sering terjebak dengan standard_library_convention. Jangan tanya kenapa.


Terima kasih atas informasinya ... jadi perpustakaan standarnya adalah garis bawah, lalu? (paling tidak lebih dari yang lainnya?) Saya berpikir seperti itu, tetapi agak sulit untuk mengatakannya karena hal-hal seperti iostream di mana separuh nama metode tampaknya sama dengan fragmen kata yang disatukan dengan ANSI C :-P
David Z

5
@ David: Pustaka iostreams mungkin berusia 25 tahun, dan (kecuali untuk lib C, atau kursus) mungkin merupakan bagian tertua dari lib std + C ++. Mudah-mudahan, tidak ada orang waras yang akan mendesainnya seperti sekarang ini, dan mudah-mudahan bahkan mereka yang tidak waras tidak akan memilih pengidentifikasi seperti yang mereka gunakan di perpustakaan stream. (Ayo, ada fungsi bernama egptr,, sputndan uflowjuga underflow. Itu hanya lucu!) Bagaimanapun, ya, std lib saat ini menggunakan all_lowercase_with_underscores.
sbi

@ SBI Saya menemukan bahwa perpustakaan iostream tidak lagi mempertimbangkan perpustakaan standar untuk C ++. Dan seperti yang Anda sebutkan, pengenalnya tidak berguna sebagai konvensi pemrograman ;-)
umlcat

2
@umlcat: Pustaka iostreams (dalam templatized dari yang diterima untuk C ++ 03) paling pasti dianggap bagian dari pustaka standar C ++.
sbi

Saya sudah turun rute yang sama juga. Saya pikir alasan saya miliki adalah camelCase sedikit lebih mudah untuk mengetik & saya ingin menjadi malas di sana. Kemudian saya mengetahui bahwa saya menghabiskan lebih banyak waktu membaca dan refactoring kode saya daripada menulisnya, dan snake_case lebih mudah dibaca. Jadi itu semua tentang meminimalkan pengeluaran energi. Sekarang saya bermain dengan menggunakan nama huruf kecil untuk kelas. Ini tidak konvensional, namun saya pikir beralih di sekitar dan meningkatkan Instans penting dan tipe yang lebih rendah sebenarnya meningkatkan keterbacaan kode saya. Saya pikir mungkin ini jalan yang harus ditempuh. Huruf besar yang penting, seperti pada manusia.
PSkocik

19

Pertama-tama mari kita sepakat bahwa SEMUA UPPERCASE adalah merusak pemandangan dan harus diminimalkan.

Dalam C dan C ++ karena itu digunakan sebagai konvensi untuk makro, dan makro saja, karena makro sama jeleknya, tidak untuk mengatakan kejahatan.

Awal C tidak memiliki const, jadi konstanta harus dinyatakan sebagai makro. Selain itu, pada masa-masa awal program jauh lebih pendek, sehingga praktik yang tidak baik hari ini dapat digunakan (misalnya IIRC Brian Kernighan menulis kode dengan banyak makro non-huruf besar). Dan juga, pada masa itu keyboard yang tidak memiliki huruf kecil memang ada; Saya menggunakan satu seperti itu, di komputer Norwegia Tandberg EC-10, sekitar 1980 atau 1979 saya pikir itu.

Jadi, Java mengambil konvensi huruf besar untuk konstanta dari awal C. Sementara itu, dan mungkin bahkan sebelum itu (saya tidak yakin kronologi di sini), C mendapat konstanta. Namun, sementara tentu saja beberapa / banyak programmer C terjebak dalam konvensi-oleh-kebutuhan sebelumnya sebagai makro huruf besar, programmer C ++ lebih masuk akal.

Masalah besar saat ini adalah ketika orang-orang diajarkan Java pertama, atau C (dengan konvensi dari abad pertengahan) pertama, dan kemudian datang ke C ++, membawa konvensi huruf besar busuk itu bersama mereka.

Begitu,

    int const answer = 42;    // Nice, good, OK.
    const int ANSWER = 0x2A;  // Ouch!
    #define COMPANYNAME_ANSWER 052  // Oh kill me, please.

Yah Anda mungkin berpikir saya menyebutkan keyboard hanya huruf besar bercanda. Oh tidak. Karena itu hanyalah batasan teknologi tertua dan paling kuno yang mendorong konvensi penamaan, atau paling tidak memengaruhi betapa salah / benarnya mereka. Selanjutnya, ada masalah transmisi serial 7-bit, yang menyebabkan masalah terkait dengan kode karakter (pengkodean karakter kertas koran) yang digunakan, yang berarti Anda harus membatasi diri pada huruf-huruf alfabet bahasa Inggris, A hingga Z.

Sebenarnya saya sarankan tetap melakukan itu. Di situlah kita berada! Kami belum mendapatkan lebih jauh.

Saat ini, pada 2011, standar C ++ mendukung Unicode umum dalam nama (dan telah melakukannya sejak 1998), sedangkan implementasi C ++ yang sebenarnya tidak. Khususnya kompilator g ++ adalah karakter nasional yang ditantang. Ini bermula dari keterbatasan teknologi zaman kegelapan itu.

Begitu,

    double blueberryJamViscosity  = 0.0;    // OK
    double blåbærsyltetøyViskositet = 0.0;  // Ouch!

Akhirnya, tentang masalah garis bawah versus huruf besar diselingi,

  • Cadangan formulir yang mudah dikenali untuk nama jenis.
  • Cadangan SEMUA UPPERKASE untuk makro.
  • Bersikaplah konsisten.

Saya pikir itu itu, sungguh, kecuali untuk aturan seperti "umumnya menghindari nama satu huruf kecuali untuk (loop, template param, bla bla)", dan "hindari menggunakan l, mudah bingung dengan 1" dan "hindari huruf besar O, mudah bingung dengan 0 ". Selain itu, tentu saja, hindari menggunakan nama yang dicadangkan seperti mulai dengan garis bawah diikuti dengan huruf besar, berisi dua garis bawah berturut-turut, atau mulai dengan garis bawah dan berada di ruang nama global.

Ceria & hth


Alf, ISTR Stroustrup menyebutkan dalam menyalin D&E C constdari C ++, jadi ini pasti terjadi sangat lama, dan jauh sebelum Jawa, mungkin untuk C89.
sbi

2
Oh, dan sepenuh hati +1untuk "Konsisten!" Membacanya saya bertanya-tanya mengapa saya lupa menyebutkan ini, yang paling penting, aturan dalam jawaban saya, ketika itu yang saya tidak pernah lupa untuk memberi tahu siswa saya. Saya kira Anda akan memaafkan saya jika saya sekarang menambahkannya ke jawaban saya sebagai renungan?
sbi

2

Saya biasanya cenderung tetap dengan konvensi yang paling saya lihat di basis kode yang ada untuk bahasa. Dalam kasus C ++, saya biasanya melihat camelCase. Dalam kasus Ruby atau PHP saya biasanya melihat stuff_like_this.

Berbicara secara realistis, yang paling penting adalah Anda memilih konvensi gaya yang tidak sepenuhnya gila (dOnT_dO_tHiS) dan konsisten dengannya. Buat agar gaya tidak berubah sepanjang kode untuk proyek tertentu. Jika Anda mengerjakan proyek yang sudah ada, Anda akan ingin pergi dengan gaya yang sudah ada.


1

Nah, ada Sistem Hungaria yang benar-benar umum bahkan sekarang, tapi saya lebih suka memotong tenggorokan saya sendiri daripada merekomendasikannya. Aplikasi Hongaria lebih baik karena tanda anotatifnya benar-benar menunjukkan semantik, meskipun saya merasa agak terlalu tertarik pada singkatan ketika kata pendek akan berlaku. (Untuk menggunakan contoh dari halaman Wikipedia itu, mengapa digunakan rwuntuk baris ketika rowhanya satu karakter yang lebih panjang? Ini tidak seperti ada kekurangan vokal global.)

Namun secara realistis, hal terpenting adalah mengikuti konvensi orang-orang yang bekerja dengan Anda . Betulkah. Kebanyakan konvensi bekerja dengan cukup baik, terutama jika digunakan secara konsisten. Inkonsistensi adalah yang terburuk (bahkan lebih daripada Sistem Hungaria, yang saya benci). Dan jika Anda sendiri, gunakan apa pun yang Anda inginkan.


1

Dari apa yang saya lihat, ini bervariasi di antara berbagai proyek.

Garis bawah yang disematkan mungkin lebih tradisional / lebih umum digunakan dalam C pada Unix. Perpustakaan standar berikut ini juga, sehingga harus hampir pasti diperlakukan sebagai default, yang akan digunakan kecuali ada cukup kode yang ada menggunakan konvensi lain untuk benar-benar memaksa menggunakan bahwa konvensi lainnya.

Windows (misalnya) menggunakan camel case untuk sebagian besar fungsinya, jadi beberapa orang yang mengembangkan untuk Windows melakukan hal yang sama. Ini juga cukup umum di antara orang-orang yang benar-benar lebih terbiasa dengan bahasa lain, dan berusaha untuk memperlakukan C ++ seolah-olah itu hanya varian aneh dari sesuatu yang lain.


1

Saya telah menggunakan perpustakaan standar dan meningkatkan sebagai referensi untuk konvensi penamaan. Namun, ada masalah dengan solusi ini.

Perpustakaan standar menggunakan konvensi penamaan yang dirancang untuk mencoba mengurangi tabrakan dengan kode Anda. Bagian dari solusinya adalah dengan menggunakan semua huruf kecil. Oleh karena itu penggunaan garis bawah bukan camelCase.

Saya menemukan bahwa camelCase dapat dibaca. PascalCase sering digunakan untuk nama kelas karena mewakili padanan kata benda yang tepat. Namun, saya akan melanggar aturan itu untuk functors yang lebih mewakili kata kerja.

Saya mencoba untuk tidak menggunakan makro. Namun ketika saya melakukannya, makro dibuat agar terlihat seperti fungsi ketika mereka bisa. Saya juga menggunakan nilai const atau enum alih-alih konstanta manifes, lebih jauh menghindari semua huruf besar. Saya biasanya awalan simbol-simbol ini dengan 'k' untuk menunjukkan bahwa mereka konstan.

// instead of a manifest constant
#define HOURS 24

// use const
const int kHours = 24; 

// or enum
enum {
    kHours   = 24,
    kMinutes = 60
};

0

Referensi ini menggambarkan konvensi penamaan yang sangat mirip dengan yang saya lihat digunakan dengan sukses di setidaknya tiga perusahaan tempat saya bekerja sebelumnya.

Berlawanan dengan jawaban sebelumnya, saya akan menghindari mengikuti konvensi penamaan C ++ Standard Library dalam kode saya sendiri, jika karena alasan lain selain menghindari tabrakan nama dengan Perpustakaan Standar.

Ini jawaban SO sebelumnya pada topik yang terkait mungkin juga menarik: /programming/228783/what-are-the-rules-about-using-an-underscore-in-ac-identifier


Umm, Anda dapat menggunakan konvensi penamaan yang sama tanpa menggunakan nama yang sama ... dan jika Anda benar-benar menginginkan nama yang sama, Anda masih dilindungi oleh ruang nama, mis . std::stringVs. gnawme::string
einpoklum
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.