Konvensi Penamaan Umum
Catatan
Konten ini dicetak ulang oleh izin Pearson Education, Inc. dari Panduan Desain Kerangka Kerja: Konvensi, Idiom, dan Pola untuk Pustaka .NET yang Dapat Digunakan Kembali, Edisi ke-2. Edisi itu diterbitkan pada tahun 2008, dan buku tersebut telah sepenuhnya direvisi pada edisi ketiga. Beberapa informasi di halaman ini mungkin sudah kedaluarsa.
Bagian ini menjelaskan konvensi penamaan umum yang berkaitan dengan pilihan kata, pedoman penggunaan singkatan dan akronim, dan rekomendasi tentang cara menghindari penggunaan nama khusus bahasa.
Pilihan kata
✔️ PILIH nama pengidentifikasi yang mudah dibaca.
Misalnya, properti bernama HorizontalAlignment lebih dapat dibaca dalam bahasa Inggris daripada AlignmentHorizontal.
✔️ UTAMAKAN keterbacaan atas keringkasan.
Nama properti CanScrollHorizontally lebih baik daripada ScrollableX (referensi tidak jelas ke sumbu X).
❌ JANGAN menggunakan garis bawah, tanda hubung, atau karakter nonalfanumerik lainnya.
❌ JANGAN menggunakan notasi Hungaria.
❌ HINDARI menggunakan pengidentifikasi yang bertentangan dengan kata kunci bahasa pemrograman yang banyak digunakan.
Menurut Peraturan 4 dari Spesifikasi Bahasa Umum (CLS), semua bahasa yang sesuai harus menyediakan mekanisme yang memungkinkan akses ke item bernama yang menggunakan kata kunci bahasa itu sebagai pengenal. C#, misalnya, menggunakan tanda @ sebagai mekanisme keluar dalam kasus ini. Namun, masih merupakan ide yang baik untuk menghindari kata kunci umum karena jauh lebih sulit menggunakan metode dengan kombinasi karakter daripada yang tanpanya.
Menggunakan Singkatan dan Akronim
❌ JANGAN gunakan singkatan atau kontraksi sebagai bagian dari nama pengidentifikasi.
Misalnya, gunakan GetWindow daripada GetWin.
❌ JANGAN gunakan akronim apa pun yang tidak diketahui secara luas, dan bahkan meskipun demikian, gunakan hanya jika perlu.
Menghindari Nama Bahasa Khusus
✔️ GUNAKAN nama semantik yang menarik daripada kata kunci khusus bahasa untuk nama jenis.
Misalnya, GetLength adalah nama yang lebih baik daripada GetInt.
✔️ GUNAKAN nama jenis CLR generik, bukan nama khusus bahasa, dalam kasus yang jarang terjadi ketika pengidentifikasi tidak memiliki makna semantik di luar jenisnya.
Misalnya, metode yang mengonversi ke Int64 harus bernama ToInt64, bukan ToLong (karena Int64 adalah nama CLR untuk alias longC#-spesifik ). Tabel berikut menyajikan beberapa jenis data dasar menggunakan nama jenis CLR (serta nama jenis yang sesuai untuk C#, Visual Basic, dan C++).
| C# | Visual Basic | C++ | CLR |
|---|---|---|---|
| sbyte | SByte | Char | SByte |
| byte | Byte | char yang tidak bertanda | Byte |
| pendek | Pendek | pendek | Int16 |
| ushort | UInt16 | short tidak bertanda | UInt16 |
| int | Bilangan bulat | int | Int32 |
| uint | UInt32 | int tidak bertanda | UInt32 |
| long | Long | __int64 | Int64 |
| ulong | UInt64 | __int64 tidak bertanda | UInt64 |
| float | Satu | float | Satu |
| Double | Laju | Double | Laju |
| bool | Boolean | bool | Boolean |
| Char | Char | wchar_t | Char |
| tali | String | String | String |
| object | Objek | Objek | Objek |
✔️ GUNAKAN nama umum, seperti value atau item, daripada mengulangi nama jenis, dalam kasus yang jarang terjadi ketika pengidentifikasi tidak memiliki arti semantik dan jenis parameter tidak penting.
Menamai Versi Baru API yang Ada
✔️ GUNAKAN nama yang mirip dengan API lama saat membuat versi baru dari API yang ada.
Ini membantu menjelaskan hubungan antara API.
✔️ LEBIH BAIK menambahkan sufiks daripada prefiks untuk menunjukkan versi baru dari API yang ada.
Ini akan mempermudah pencarian saat menjelajahi dokumentasi, atau menggunakan IntelliSense. Versi lama API akan diatur dekat dengan API baru, karena sebagian besar browser dan IntelliSense menampilkan pengidentifikasi dalam urutan abjad.
✔️ PERTIMBANGKAN untuk menggunakan pengidentifikasi baru namun bermakna, daripada menambahkan sufiks atau prefiks.
✔️ GUNAKAN sufiks numerik untuk menunjukkan versi baru dari API yang ada, terutama jika nama API yang ada adalah satu-satunya nama yang masuk akal (yaitu, jika itu adalah standar industri) dan jika menambahkan sufiks yang bermakna (atau mengubah nama) bukanlah pilihan yang tepat.
❌ JANGAN gunakan sufiks "Ex" (atau yang serupa) untuk pengidentifikasi guna membedakan dari versi sebelumnya dari API yang sama.
✔️ GUNAKAN akhiran "64" saat memperkenalkan versi API yang beroperasi pada integer 64-bit (integer panjang) alih-alih integer 32-bit. Anda hanya perlu menggunakan pendekatan ini ketika API 32-bit sudah ada; jangan melakukannya untuk API baru hanya dengan versi 64-bit.
Portions © 2005, 2009 Microsoft Corporation. Semua hak dilindungi undang-undang.
Dicetak ulang dengan izin dari Pearson Education, Inc. dari Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition oleh Krzysztof Cwalina dan Brad Abrams, diterbitkan 22 Okt 2008 oleh Addison-Wesley Professional sebagai bagian dari Seri Pengembangan Microsoft Windows.