Masalah penamaan: Haruskah "Sesuatu" diubah namanya menjadi "Sesuatu"? [Tutup]


68

Bab Paman Bob tentang nama dalam Kode Bersih merekomendasikan agar Anda menghindari penyandian nama, terutama yang berkaitan dengan notasi Hongaria. Dia juga secara spesifik menyebutkan menghapus Iawalan dari antarmuka, tetapi tidak menunjukkan contoh ini.

Mari kita asumsikan sebagai berikut:

  • Penggunaan antarmuka terutama untuk mencapai testabilitas melalui injeksi ketergantungan
  • Dalam banyak kasus, ini mengarah pada memiliki antarmuka tunggal dengan implementer tunggal

Jadi, misalnya, apa nama keduanya? Parserdan ConcreteParser? Parserdan ParserImplementation?

public interface IParser {
    string Parse(string content);
    string Parse(FileInfo path);
}

public class Parser : IParser {
     // Implementations
}

Atau haruskah saya mengabaikan saran ini dalam kasus implementasi tunggal seperti ini?


30
Itu tidak berarti agama. Anda harus mencari alasan, bukan hanya seseorang yang X katakan Y.
Mike Dunlavey

35
@ MikeDunlavey Dan itulah alasan untuk pertanyaannya!
Vinko Vrsalovic

14
Jika ada kode yang sudah ada (yang tidak akan Anda tulis ulang), tetap gunakan konvensi apa pun yang digunakannya. Jika kode baru, gunakan apa pun yang sebagian besar orang yang akan mengerjakannya paling bahagia dengan / dulu. Hanya jika kedua hal di atas tidak berlaku maka itu akan menjadi pertanyaan filsafat.
TripeHound

9
Aturan @TripeHound Mayoritas tidak selalu merupakan pilihan terbaik. Jika ada alasan beberapa hal lebih baik daripada yang lain, satu orang dapat meyakinkan anggota tim lainnya untuk membuat kasus berdasarkan alasan tersebut. Hanya tunduk secara buta kepada mayoritas tanpa mengevaluasi sesuatu melalui mengarah pada stagnasi. Saya melihat dari jawaban bahwa untuk kasus konkret ini tidak ada alasan yang baik untuk menghapus Is, tetapi itu tidak membatalkan bertanya sejak awal.
Vinko Vrsalovic

35
Buku "Paman Bob" berfokus pada JAVA, bukan C #. Sebagian besar paradigma sama dengan C #, tetapi beberapa konvensi penamaan berbeda (juga lihat nama fungsi lowerCamelCase di Jawa). Saat Anda menulis dalam C #, gunakan konvensi penamaan C #. Tapi bagaimanapun, ikuti poin utama babnya tentang penamaan: nama yang dapat dibaca yang mengkomunikasikan makna item!
Bernhard Hiller

Jawaban:


191

Sementara banyak, termasuk "Paman Bob", menyarankan untuk tidak menggunakan Iawalan untuk antarmuka, melakukannya adalah tradisi mapan dengan C #. Secara umum, itu harus dihindari. Tetapi jika Anda menulis C #, Anda harus benar-benar mengikuti konvensi bahasa itu dan menggunakannya. Tidak melakukannya akan menyebabkan kebingungan besar dengan orang lain yang akrab dengan C # yang mencoba membaca kode Anda.


Komentar bukan untuk diskusi panjang; percakapan ini telah dipindahkan ke obrolan .
maple_shaft

9
Anda tidak memberikan dasar untuk "Secara umum, itu harus dihindari". Di Jawa, saya harus dihindari. Dalam C # itu harus dipeluk. Bahasa lain mengikuti konvensi mereka sendiri.
Dasar

4
Prinsip "secara umum" sederhana: Klien harus memiliki hak untuk tidak tahu apakah itu berbicara ke antarmuka atau implementasi. Kedua bahasa salah. C # salah konvensi penamaan. Java salah bytecode. Jika saya beralih implementasi ke antarmuka dengan nama yang sama di Jawa saya harus mengkompilasi ulang semua klien meskipun nama dan metode tidak berubah. Itu bukan "mengambil racunmu". Kami baru saja salah melakukannya. Silakan pelajari dari ini jika Anda membuat bahasa baru.
candied_orange

39

Antarmuka adalah konsep logis yang penting, oleh karena itu, antarmuka harus membawa nama generik. Jadi, saya lebih suka

interface Something
class DefaultSomething : Something
class MockSomething : Something

dari

interface ISomething
class Something : ISomething
class MockSomething : ISomething

Yang terakhir memiliki beberapa isue:

  1. Sesuatu hanyalah satu implementasi dari ISomething, namun itu adalah sesuatu dengan nama generik, seolah-olah itu entah bagaimana istimewa.
  2. MockSomething tampaknya berasal dari Sesuatu, namun mengimplementasikan ISomething. Mungkin harus diberi nama MockISomething, tapi aku belum pernah melihatnya di alam liar.
  3. Refactoring lebih sulit. Jika Sesuatu adalah kelas sekarang, dan Anda hanya tahu nanti bahwa Anda harus memperkenalkan antarmuka, antarmuka itu harus dinamai sama, karena itu harus transparan kepada klien apakah jenisnya adalah kelas beton, kelas abstrak atau antarmuka . Tidak ada yang memecahkannya.

59
Mengapa Anda tidak mengikuti standar mapan yang disediakan C #? Apa manfaatnya yang melebihi biaya membingungkan dan menjengkelkan setiap programmer C # yang mengikuti Anda?
Robert Harvey

6
@wallenborn Tidak apa-apa, tetapi secara realistis Anda sering kali hanya memiliki satu implementasi antarmuka yang sah, karena itu umum menggunakan antarmuka untuk mockability dalam pengujian unit. Saya tidak ingin menempatkan Defaultatau Realatau Impldalam banyak nama kelas saya
Ben Aaronson

4
Saya setuju dengan Anda, tetapi jika Anda menempuh jalan ini Anda harus bertarung dengan setiap orang yang pernah membuat C #.
RubberDuck

3
Saya melihat tidak ada masalah dengan memiliki kelas instantiable dengan nama yang sama dengan antarmuka jika sebagian besar contoh yang mengimplementasikan antarmuka adalah kelas itu. Sebagai contoh, banyak kode memerlukan implementasi tujuan langsung yang sederhana IList<T>dan tidak terlalu peduli bagaimana itu disimpan secara internal; bisa hanya lop dari Idan memiliki nama kelas yang dapat digunakan tampaknya lebih baik daripada harus tahu secara ajaib (seperti di Jawa) bahwa kode yang ingin implementasi biasa List<T>harus digunakan ArrayList<T>.
supercat

2
@ArtB Beberapa alasan. Satu, tidak ada bahasa di mana konvensi adalah penanda pendek yang bagus di kelas seperti CFoo : Foo. Jadi opsi itu tidak tersedia. Dua, Anda mendapatkan inkonsistensi aneh karena beberapa kelas akan memiliki penanda dan yang lainnya tidak, tergantung pada apakah mungkin ada implementasi lain dari antarmuka yang sama. CFoo : Footapi SqlStore : Store. Itulah satu masalah yang saya miliki Impl, yang pada dasarnya hanya merupakan penanda yang lebih buruk. Mungkin jika ada bahasa dengan konvensi yang selalu menambahkan C(atau apa pun), itu mungkin lebih baik daripadaI
Ben Aaronson

27

Ini bukan hanya tentang konvensi penamaan. C # tidak mendukung multiple inheritance sehingga penggunaan notasi Hungaria yang lama ini memiliki sedikit manfaat meskipun Anda mewarisi dari kelas dasar dan mengimplementasikan satu atau lebih antarmuka. Jadi ini...

class Foo : BarB, IBarA
{
    // Better...
}

... lebih disukai daripada ini ...

class Foo : BarB, BarA
{
    // Dafuq?
}

IMO


7
Ini perlu dicatat bahwa Jawa rapi menghindari masalah ini dengan menggunakan kata kunci yang berbeda untuk warisan kelas dan implementasi antarmuka, yaitu inheritsvs implements.
Konrad Rudolph

6
@KonradRudolph maksudmu extends.
Stop Harming Monica

2
@Andy Nilai tambahnya adalah kita dapat menghindari kesalahan Notasi Hongaria, namun mempertahankan semua kejelasan yang dipuji dalam jawaban ini.
Konrad Rudolph

2
Seharusnya tidak ada kebingungan; jika Anda mewarisi kelas, itu HARUS menjadi yang pertama dalam daftar, sebelum daftar antarmuka yang diterapkan. Saya cukup yakin ini dipaksakan oleh kompiler.
Andy

1
@Andy ... jika Anda mewarisi sebuah kelas, itu HARUS menjadi yang pertama dalam daftar Itu hebat tetapi tanpa awalan Anda tidak akan tahu jika Anda berurusan dengan beberapa antarmuka atau kelas dasar dan antarmuka ...
Robbie Dee

15

Tidak tidak Tidak.

Konvensi penamaan bukan merupakan fungsi fandom Paman Bob Anda. Mereka bukan fungsi dari bahasa, c # atau sebaliknya.

Mereka adalah fungsi dari basis kode Anda. Untuk tingkat yang jauh lebih rendah dari toko Anda. Dengan kata lain yang pertama dalam basis kode menetapkan standar.

Hanya dengan begitu Anda bisa memutuskan. Setelah itu konsisten saja. Jika seseorang mulai tidak konsisten mengambil senjata nerf mereka dan membuat mereka memperbarui dokumentasi sampai mereka bertobat.

Saat membaca basis kode baru jika saya tidak pernah melihat Iawalan saya baik-baik saja, terlepas dari bahasa. Jika saya melihat satu di setiap antarmuka saya baik-baik saja. Jika saya terkadang melihatnya, seseorang akan membayar.

Jika Anda menemukan diri Anda dalam konteks yang jarang dijumpai dalam menetapkan preseden ini untuk basis kode Anda, saya mendorong Anda untuk mempertimbangkan ini:

Sebagai kelas klien saya berhak untuk tidak peduli dengan apa yang saya bicarakan. Yang saya butuhkan hanyalah nama dan daftar hal yang bisa saya panggil terhadap nama itu. Itu mungkin tidak akan berubah kecuali jika saya mengatakannya. SAYA SENDIRI bagian itu. Apa yang saya bicarakan, antarmuka atau tidak, bukan departemen saya.

Jika Anda menyelinap Idalam nama itu, klien tidak peduli. Jika tidak ada I, klien tidak peduli. Apa yang dibicarakannya mungkin konkret. Mungkin tidak. Karena tidak memanggilnya new, tidak ada bedanya. Sebagai klien, saya tidak tahu. Saya tidak ingin tahu.

Sekarang sebagai monyet kode melihat kode itu, bahkan di java, ini mungkin penting. Lagi pula, jika saya harus mengubah implementasi ke antarmuka saya bisa melakukannya tanpa memberi tahu klien. Jika tidak ada Itradisi saya mungkin tidak akan mengganti namanya. Yang mungkin menjadi masalah karena sekarang kita harus mengkompilasi ulang klien karena meskipun sumbernya tidak peduli biner melakukannya. Sesuatu yang mudah dilewatkan jika Anda tidak pernah mengubah namanya.

Mungkin itu bukan masalah bagi Anda. Mungkin tidak. Jika ya, itu alasan yang bagus untuk peduli. Tapi untuk cinta mainan meja jangan mengklaim kita harus membabi buta melakukan ini karena itu cara yang dilakukan di beberapa bahasa. Entah memiliki alasan yang kuat atau tidak peduli.

Ini bukan tentang hidup dengannya selamanya. Ini tentang tidak memberi saya omong kosong tentang basis kode yang tidak sesuai dengan mentalitas khusus Anda kecuali jika Anda siap untuk memperbaiki 'masalah' di mana-mana. Kecuali Anda memiliki alasan yang kuat saya tidak seharusnya mengambil jalan yang paling tidak menentang keseragaman, jangan datang kepada saya untuk mengkhotbahkan konformitas. Aku punya hal yang lebih baik untuk dilakukan.


6
Konsistensi adalah kuncinya, tetapi dalam bahasa yang diketik secara statis dan dengan alat refactoring modern cukup mudah dan aman untuk mengubah nama. Jadi jika pengembang pertama membuat pilihan yang buruk dalam penamaan, Anda tidak harus hidup dengannya selamanya. Tapi Anda bisa mengubah penamaan di basis kode Anda sendiri, tetapi Anda tidak bisa mengubahnya di framework atau pustaka pihak ketiga. Karena awalan-I (suka atau tidak) adalah konvensi yang mapan di seluruh dunia .net, lebih baik mengikuti konvensi daripada tidak mengikutinya.
JacquesB

Jika Anda menggunakan C #, Anda akan melihatnya I. Jika kode Anda menggunakannya, Anda akan melihatnya di mana-mana. Jika kode Anda tidak menggunakannya, Anda akan melihatnya dari kode kerangka kerja, mengarah tepat ke campuran yang tidak Anda inginkan.
Sebastian Redl

8

Ada satu perbedaan kecil antara Java dan C # yang relevan di sini. Di Jawa, setiap anggota adalah virtual secara default. Dalam C #, setiap anggota disegel secara default - kecuali untuk anggota antarmuka.

Asumsi yang sesuai dengan pedoman ini memengaruhi - di Jawa, setiap tipe publik harus dianggap non-final, sesuai dengan Prinsip Pergantian Liskov [1]. Jika Anda hanya memiliki satu implementasi, Anda akan memberi nama kelas Parser; jika Anda membutuhkan beberapa implementasi, Anda hanya akan mengubah kelas menjadi antarmuka dengan nama yang sama, dan mengganti nama implementasi konkret menjadi sesuatu yang deskriptif.

Dalam C #, asumsi utama adalah bahwa ketika Anda mendapatkan kelas (nama tidak dimulai dengan I), itulah kelas yang Anda inginkan. Pikiran Anda, ini tidak mendekati 100% akurat - contoh-contoh khas akan menjadi kelas seperti Stream(yang seharusnya merupakan antarmuka, atau beberapa antarmuka), dan setiap orang memiliki panduan dan latar belakang mereka sendiri dari bahasa lain. Ada juga pengecualian lain seperti Basesufiks yang cukup banyak digunakan untuk menunjukkan kelas abstrak - seperti halnya dengan antarmuka, Anda tahu jenisnya seharusnya polimorfik.

Ada juga fitur kegunaan yang bagus dalam membiarkan nama non-I-awalan untuk fungsi yang berhubungan dengan antarmuka itu tanpa harus menggunakan membuat antarmuka kelas abstrak (yang akan merugikan karena kurangnya kelas multiple-inheritance di C #). Ini dipopulerkan oleh LINQ, yang digunakan IEnumerable<T>sebagai antarmuka, dan Enumerablesebagai tempat penyimpanan metode yang berlaku untuk antarmuka itu. Ini tidak perlu di Java, di mana antarmuka dapat berisi implementasi metode juga.

Pada akhirnya, Iawalan secara luas digunakan di dunia C #, dan dengan ekstensi, dunia .NET (karena sejauh ini sebagian besar. Kode NET ditulis dalam C #, masuk akal untuk mengikuti pedoman C # untuk sebagian besar antarmuka publik). Ini berarti Anda hampir pasti akan bekerja dengan perpustakaan dan kode yang mengikuti notasi ini, dan masuk akal untuk mengadopsi tradisi untuk mencegah kebingungan yang tidak perlu - tidak seperti menghilangkan awalan akan membuat kode Anda lebih baik :)

Saya berasumsi bahwa alasan Paman Bob adalah sesuatu seperti ini:

IBananaadalah gagasan abstrak pisang. Jika ada kelas pelaksana yang tidak memiliki nama yang lebih baik dari itu Banana, abstraksi sama sekali tidak berarti, dan Anda harus meninggalkan antarmuka dan hanya menggunakan kelas. Jika ada nama yang lebih baik (katakanlah, LongBananaatau AppleBanana), tidak ada alasan untuk tidak menggunakan Banananama antarmuka. Oleh karena itu, menggunakan Iawalan menandakan bahwa Anda memiliki abstraksi yang tidak berguna, yang membuat kode lebih sulit untuk dipahami tanpa manfaat. Dan karena OOP yang ketat akan membuat Anda selalu kode terhadap antarmuka, satu-satunya tempat di mana Anda tidak akan melihat Iawalan pada suatu jenis akan berada di konstruktor - kebisingan yang tidak ada gunanya.

Jika Anda menerapkan ini pada IParserantarmuka sampel Anda, Anda dapat dengan jelas melihat bahwa abstraksi sepenuhnya berada di wilayah "tidak berarti". Entah ada sesuatu yang spesifik tentang implementasi konkret dari parser (misalnya JsonParser, XmlParser, ...), atau Anda hanya harus menggunakan kelas. Tidak ada yang namanya "implementasi default" (meskipun di beberapa lingkungan, ini memang masuk akal - terutama, COM), baik ada implementasi spesifik, atau Anda ingin kelas abstrak atau metode ekstensi untuk "default". Namun, dalam C #, kecuali basis kode Anda sudah menghapus I-prefix, simpan. Buat catatan mental setiap kali Anda melihat kode class Something: ISomething- artinya seseorang tidak pandai mengikuti YAGNI dan membangun abstraksi yang masuk akal.

[1] - Secara teknis, ini tidak secara khusus disebutkan dalam makalah Liskov, tetapi ini adalah salah satu dasar dari kertas OOP asli dan dalam pembacaan saya tentang Liskov, dia tidak menentang ini. Dalam interpretasi yang kurang ketat (yang diambil oleh sebagian besar bahasa OOP), ini berarti bahwa setiap kode yang menggunakan tipe publik yang dimaksudkan untuk substitusi (yaitu non-final / disegel) harus bekerja dengan implementasi yang sesuai dari tipe tersebut.


3
Nitpick: LSP tidak mengatakan bahwa setiap jenis harus non-final. Itu hanya mengatakan bahwa untuk jenis yang adalah non-akhir, konsumen harus dapat menggunakan subclass transparan. - Dan tentu saja Java juga memiliki tipe final.
Konrad Rudolph

@KonradRudolph Saya menambahkan catatan kaki tentang ini; terima kasih atas umpan baliknya :)
Luaan

4

Jadi, misalnya, apa nama keduanya? Parser dan ConcreteParser? Parser dan ParserImplementation?

Dalam dunia yang ideal, Anda tidak harus mengawali nama Anda dengan tulisan tangan pendek ("Saya ...") tetapi cukup biarkan nama tersebut mengekspresikan sebuah konsep.

Saya membaca di suatu tempat (dan tidak bisa sumbernya) pendapat bahwa konvensi ISomething ini menuntun Anda untuk mendefinisikan konsep "IDollar" ketika Anda membutuhkan kelas "Dolar", tetapi solusi yang benar adalah konsep yang disebut hanya "Mata Uang".

Dengan kata lain, konvensi ini memberikan jalan keluar yang mudah untuk kesulitan menyebutkan nama dan yang mudah secara halus salah .


Di dunia nyata, klien kode Anda (yang mungkin hanya "Anda dari masa depan") harus dapat membacanya nanti dan terbiasa dengannya secepat mungkin (atau dengan sedikit usaha) mungkin (berikan klien kode Anda apa yang mereka harapkan dapatkan).

Konvensi ISomething, memperkenalkan nama cruft / bad. Yang mengatakan, cruft bukan cruft nyata *), kecuali konvensi dan praktik yang digunakan dalam penulisan kode tidak lagi aktual; jika konvensi mengatakan "gunakan sesuatu", maka yang terbaik adalah menggunakannya, untuk menyesuaikan (dan bekerja lebih baik) dengan pengembang lainnya.


*) Saya bisa lolos dengan mengatakan ini karena "cruft" bukan konsep yang pasti :)


2

Seperti jawaban lain menyebutkan, awalan nama antarmuka Anda dengan Iadalah bagian dari pedoman pengkodean untuk .NET framework. Karena kelas konkret lebih sering berinteraksi dengan daripada antarmuka generik dalam C # dan VB.NET, mereka adalah kelas pertama dalam skema penamaan dan dengan demikian harus memiliki nama paling sederhana - karenanya, IParseruntuk antarmuka dan Parseruntuk implementasi default.

Tetapi dalam kasus Java dan bahasa yang serupa, di mana antarmuka lebih disukai daripada kelas konkret, Paman Bob benar bahwa Iharus dihapus dan antarmuka harus memiliki nama yang paling sederhana - Parseruntuk antarmuka parser Anda, misalnya. Tetapi alih-alih nama berbasis peran seperti ParserDefault, kelas harus memiliki nama yang menjelaskan bagaimana parser diimplementasikan :

public interface Parser{
}

public class RegexParser implements Parser {
    // parses using regular expressions
}

public class RecursiveParser implements Parser {
    // parses using a recursive call structure
}

public class MockParser implements Parser {
    // BSes the parsing methods so you can get your tests working
}

Hal ini, misalnya, bagaimana Set<T>, HashSet<T>dan TreeSet<T>diberi nama.


5
Antarmuka lebih disukai dalam C # juga. Siapa yang memberi tahu Anda bahwa lebih disukai menggunakan jenis beton di dotnet?
RubberDuck

@RubberDuck Tersembunyi di beberapa asumsi bahasa memaksakan pada Anda. Misalnya, fakta bahwa anggota secara sealeddefault, dan Anda harus membuatnya secara eksplisit virtual. Menjadi virtual adalah kasus khusus dalam C #. Tentu saja, karena pendekatan yang direkomendasikan untuk menulis kode berubah selama bertahun-tahun, banyak peninggalan masa lalu yang diperlukan untuk tetap kompatibel :) Poin utamanya adalah jika Anda mendapatkan antarmuka dalam C # (yang dimulai dengan I), Anda tahu itu sepenuhnya tipe abstrak; jika Anda mendapatkan non-antarmuka, asumsi tipikal adalah tipe yang Anda inginkan, LSP terkutuk.
Luaan

1
Anggota disegel secara default sehingga kami secara eksplisit tentang apa yang pewaris dapat naiki @Luaan. Memang, kadang-kadang PITA, tetapi tidak ada hubungannya dengan preferensi untuk jenis beton. Virtual tentu bukan kasus khusus dalam C #. Sepertinya Anda mengalami kemalangan bekerja di basis kode C # yang ditulis oleh amatir. Maaf, itu pengalaman Anda dengan bahasa tersebut. Yang terbaik untuk diingat bahwa dev bukanlah bahasa dan sebaliknya.
RubberDuck

@RubberDuck Hah, saya tidak pernah mengatakan saya tidak menyukainya. Saya sangat menyukainya, karena kebanyakan orang tidak mengerti tipuan . Bahkan di antara programmer. Disegel secara default lebih baik menurut saya. Dan ketika saya mulai dengan C #, semua orang adalah seorang amatir, termasuk tim NET. :) Dalam "OOP nyata", semuanya seharusnya virtual - setiap jenis harus diganti dengan tipe turunan, yang harus dapat menimpa perilaku apa pun . Tapi "OOP nyata" dirancang untuk spesialis, bukan orang yang beralih dari mengganti bola lampu ke pemrograman karena lebih sedikit bekerja untuk lebih banyak uang :)
Luaan

Tidak ... Tidak. Itu sama sekali bukan "OOP asli". Di Jawa, Anda harus meluangkan waktu untuk menyegel metode yang tidak boleh diganti, tidak meninggalkannya seperti Wild West di mana siapa pun dapat menunggangi semuanya. LSP tidak berarti Anda dapat menimpa apa pun yang Anda inginkan. LSP berarti Anda dapat dengan aman mengganti satu kelas dengan kelas lainnya. Smh
RubberDuck

-8

Anda benar karena konvensi antarmuka I = antarmuka ini melanggar aturan (baru)

Di masa lalu Anda akan mengawali semuanya dengan jenisnya intCounter boolFlag dll.

Jika Anda ingin memberi nama sesuatu tanpa awalan, tetapi juga menghindari 'ConcreteParser' Anda bisa menggunakan ruang nama

namespace myapp.Interfaces
{
    public interface Parser {...
}


namespace myapp.Parsers
{
    public class Parser : myapp.Interfaces.Parser {...
}

11
baru? tua? Tunggu, saya pikir pemrograman lebih tentang rasionalitas daripada hype. Atau apakah ini di masa lalu?

3
tidak semua tentang membuat konvensi dan blog tentang bagaimana mereka 'meningkatkan keterbacaan'
Ewan

8
Saya percaya Anda berpikir tentang notasi Hongaria, di mana Anda memang awalan nama dengan tipe. Tetapi tidak ada waktu di mana Anda akan menulis sesuatu seperti intCounteratau boolFlag. Itu adalah "tipe" yang salah. Sebagai gantinya, Anda akan menulis pszName(penunjuk ke string yang diakhiri NUL yang berisi nama), cchName(jumlah karakter dalam string "nama"), xControl(koordinat x dari kontrol), fVisible(bendera yang menunjukkan sesuatu terlihat), pFile(penunjuk ke file), hWindow(pegangan ke jendela), dan sebagainya.
Cody Grey

2
Masih banyak nilai dalam hal ini. Sebuah kompiler tidak akan menangkap kesalahan ketika Anda menambahkan xControlke cchName. Mereka berdua tipe int, tetapi mereka memiliki semantik yang sangat berbeda. Awalan membuat semantik ini jelas bagi manusia. Pointer ke string yang diakhiri NUL terlihat persis seperti pointer ke string gaya Pascal ke kompiler. Demikian pula, Iawalan untuk antarmuka muncul dalam bahasa C ++ di mana antarmuka benar-benar hanya kelas (dan memang untuk C, di mana tidak ada yang namanya kelas atau antarmuka di tingkat bahasa, itu semua hanya sebuah konvensi).
Cody Gray

4
@CodyGray Joel Spolsky menulis artikel yang bagus, Membuat Kode yang Salah Terlihat Keliru tentang notasi Hongaria dan cara-cara memahami (salah) itu. Dia memiliki pendapat yang sama: awalan harus tipe tingkat yang lebih tinggi, bukan tipe penyimpanan data mentah. Dia menggunakan kata "jenis", menjelaskan, "Saya menggunakan kata jenis dengan sengaja, di sana, karena Simonyi keliru menggunakan jenis kata dalam makalahnya, dan generasi programmer salah memahami apa yang dia maksudkan."
Joshua Taylor
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.