สัญกรณ์ระบบฮังการียังคงเป็นประโยชน์หรือไม่? [ปิด]

ฉันค้นหาฟอรัม แต่ฉันไม่สามารถหาคำตอบได้ว่าทำไมจึงควรหลีกเลี่ยงเพียงเพราะเหตุใดมันจึงไม่ใช่กระสุนเงิน ดังนั้นฉันไม่คิดว่าคำถามนี้จะซ้ำกัน

มีความถูกต้องเหตุผลว่าทำไมฉันควรยกเลิกระบบฮังการีฉันใช้เพื่อ?

จนถึงตอนนี้ฉันเห็นประโยชน์ต่อไปนี้ในการใช้งาน:

• การตั้งชื่อตัวแปรที่สอดคล้องกัน
• คุณเห็นประเภทโดยไม่ต้องค้นหา (Intellisense ตาย / ทำดัชนีครึ่งเวลาดังนั้นจึงเป็นเหตุผลที่ถูกต้อง)
• ความหมายยังคงสามารถบรรจุลงในส่วนที่สองของชื่อ

และติดตามข้อเสีย:

• มันทำให้บางคนรำคาญ (ไม่รู้เลยว่าทำไม)
• หากประเภทมีการเปลี่ยนแปลงประเภทอาจไม่ตรงกับการตั้งชื่อของตัวแปร (ฉันไม่คิดว่ามันเป็นเหตุผลที่ถูกต้องประเภทมีการเปลี่ยนแปลงน้อยและคุณมี "เปลี่ยนชื่อทั้งหมด")

ดังนั้นทำไม:

vector<string> vecCityNames;
wstring strCity = L"abc";
//more code here
vecCityNames.push_back(strCity);

เลวร้ายยิ่งกว่า:

vector<string> cityNames;
wstring city = L"abc";
//more code here
cityNames.push_back(city);//Are we pushing back int on a queue? Float on a stack? Something else?

ฉันเคยใช้มัน (หลายปีที่ผ่านมา) และฉันไม่ได้อีกต่อไป เหตุผลหลักคือมันฟุ่มเฟือยในภาษา OO ด้วยการพิมพ์ที่แข็งแกร่ง (C ++, Java) ซึ่งฉันได้ใช้เวลาส่วนใหญ่ในอาชีพของฉัน ในภาษาเหล่านี้ถ้าฉันกำหนดประเภทของฉันได้ดีผู้รวบรวมสามารถและจะบังคับใช้ความปลอดภัยของประเภทสำหรับฉัน ดังนั้นคำนำหน้าการตั้งชื่อใด ๆ ก็เป็นเพียงความยุ่งเหยิงซึ่งทำให้ชื่อยาวขึ้นดังนั้นจึงยากต่อการอ่านและค้นหา

ในโปรแกรม OO ที่เขียนได้ดีตัวแปรส่วนใหญ่ของคุณคือ (อ้างอิงถึง) ประเภทที่ผู้ใช้กำหนด หากคุณนำหน้าสิ่งเหล่านี้ด้วยแท็กทั่วไปเดียวกัน (เช่นoสำหรับ "วัตถุ") คุณจะไม่ได้รับประโยชน์ใด ๆ จากมันเพียงแค่ข้อเสียเปรียบ หากคุณใช้คำนำหน้าแท็กที่มีประเภทเฉพาะคุณจะต้องพยายามค้นหาตัวย่อที่แตกต่างกันสำหรับประเภทต่าง ๆ นับพันที่มีชื่อคล้ายกัน * และอย่าลืมเปลี่ยนทุกอย่างเมื่อมีการเปลี่ยนชื่อ ไม่หายากเลยในโปรแกรมที่ได้รับการดูแลอย่างดี)

แน่นอนว่าสิ่งนี้ไม่ได้ใช้กับภาษาที่ไม่ใช่ OO และอาจไม่มีผลกับภาษาที่พิมพ์น้อยและ / หรือแบบไดนามิก (ฉันไม่มีประสบการณ์กับภาษาเหล่านี้นอกเหนือจาก C) ทั้งตัวแก้ไข / ไอดีที่ไม่มีประสิทธิภาพโดยไม่ต้องใช้ IntelliSense (หรือเทียบเท่าภายใน) และนี่เป็นเพียง 2 เซ็นต์ของฉัน ดังนั้นหากสัญกรณ์ฮังการีทำงานกับทีมของคุณและโครงการของคุณให้ทำตามนั้น สิ่งสำคัญคือการเห็นด้วยกับเรื่องนี้ (เช่นเดียวกับรูปแบบการเข้ารหัสที่สอดคล้องกันโดยทั่วไป) ก่อนที่โครงการจะเริ่มต้นและทำให้มันสอดคล้องกันตลอดเวลา

* _{เพียงรายการสั้น ๆ จากโครงการปัจจุบันของเรา: เรามีCharge, ChargeBreakdown, ChargeCalculator, ChargeDAO, ChargeDTO, ChargeLineHelper, ChargeMaps, ChargePairและChargeTypeอื่น ๆ ในกลุ่ม ยิ่งไปกว่านั้นเรายังมีContracts, Countries, Checkouts, Checkins ... และนี่เป็นเพียงตัวอักษร C ในโครงการที่อาจจะไม่เรียกว่า "ขนาดพอสมควร" โดย OP}

ข้อจำกัดความรับผิดชอบ: ฉันเป็นชาวฮังการีจริง ๆ ดังนั้นฉันจึงเชื่อว่าฉันสามารถพูดเกี่ยวกับปัญหานี้กับผู้มีอำนาจ ;-)

ทำไมถึงstd::vector<string> vecCityNames;ไม่ดี?

ปัญหาเกี่ยวกับสัญกรณ์ฮังการีตามปกติแล้วจะใช้ถ้าหากการทำโปรไฟล์แสดงว่าชื่อเมืองควรถูกเก็บไว้ในstd::dequeชื่อตัวแปรทั้งหมดที่อ้างถึงวัตถุประเภทนั้นจะมีชื่อที่ทำให้เข้าใจผิด

คุณจะเปลี่ยนชื่อตัวแปรทั้งหมดของคุณหรือไม่? คุณเคยลองทำในโครงการใหญ่หรือไม่? ด้วยความช่วยเหลือของเมอร์ฟี (และผู้ชายก็มีประโยชน์อย่างไม่น่าเชื่อ) ใครบางคนจะใช้ตัวแปรที่เรียกว่าสิ่งต่าง ๆ เช่นdeqCityNamesทำให้การเปลี่ยนแปลงของคุณพังทลายลงทำให้คุณนั่งเป็นชั่วโมงด้วยรหัสที่ครึ่งทศวรรษไม่มีใครกล้าแม้แต่จะมอง ที่เพราะกลัวถูกสัตว์มีพิษกัด

จากสิ่งที่ฉันรู้ แต่วิธีที่ชาร์ลส์ Simonyi ขึ้นมาด้วยฮังการีคำนำหน้าเป็น denoting ตัวแปรการใช้ความหมายมากกว่าจะเป็นประเภทประโยค นั่นคือคำนำหน้าที่เหมาะสมสำหรับรายชื่อเมืองของคุณไม่ว่าจะมีการใช้งานในประเภทใดก็อาจจะเป็นlistCityNames(หรือlstCityNamesหากlistไม่เป็นความลับสำหรับคุณ)

แต่ฉันคิดว่าคำนำหน้านั้นค่อนข้างไม่จำเป็นเพราะพหูพจน์ ("ชื่อ") บ่งบอกว่าเป็นเมืองใหญ่ บรรทัดล่างสุด: เมื่อคุณเลือกตัวระบุของคุณด้วยความระมัดระวังสัญลักษณ์ฮังการีไม่ค่อยจำเป็น OTOH เป็นวิธีที่ใช้กันโดยทั่วไปในระยะยาวทำให้รหัสเสียหาย

ไม่ว่าจะด้วยเหตุผลใดคำตอบที่มีอยู่ในที่นี้ดูเหมือนจะเต้นไปรอบ ๆ เหตุผลสำหรับสัญกรณ์ฮังการีโดยไม่ได้ระบุไว้เลย สัญกรณ์ฮังการีจะเป็นประโยชน์สำหรับการเพิ่มข้อมูลประเภท (ในความรู้สึกทางทฤษฎีประเภท ) เมื่อมันจะเป็นเรื่องยากที่จะทำเช่นนั้นในภาษาของตัวเอง เมื่อมันเกิดขึ้นมักจะไม่ยากที่จะใช้ระบบ C + + ของ Java ในลักษณะที่สัญกรณ์ฮังการี (ตามที่อธิบายไว้โดยทั่วไป) นั้นไม่จำเป็นอย่างสมบูรณ์และนี่อาจเป็นสิ่งที่นำไปสู่ ​​backlash กับมัน เพื่อรักษาคำอธิบายประกอบเหล่านั้นไว้ในตัวแปรของเราทั้งหมด แต่ให้ค่าเพิ่มเติมเล็กน้อยต่อไม่มี (และอาจทำให้เกิดความเสียหายเนื่องจากรหัสดูยุ่งเหยิงมากขึ้น)

ในทางกลับกันหากมีใคร จำกัด การใช้งานของสัญกรณ์ฮังการีเพื่อพิมพ์ข้อมูล (อีกครั้งในแง่ทฤษฎีประเภท ) ที่ไม่ได้ภาษาที่ห่อหุ้มตามธรรมชาติโดยภาษานั้นจะมีประโยชน์มาก ตัวอย่างเช่น C และ C ++ ส่งผ่านการอ้างอิงอาร์เรย์เป็นชนิดตัวชี้ แต่การอ้างอิงอาร์เรย์และพอยน์เตอร์มีการดำเนินการที่แตกต่างกันซึ่งควรดำเนินการกับพวกเขา: อาร์เรย์สามารถทำดัชนีได้นอกเหนือจากองค์ประกอบแรกในขณะที่พอยน์เตอร์ไม่ควร นี่เป็นข้อมูลที่มีประโยชน์ที่หายไปกับระบบชนิดทันทีที่อาร์เรย์ส่งผ่านไปยังฟังก์ชันเป็นอาร์กิวเมนต์ ในกลุ่มของเราเราได้ใช้คำอธิบายประกอบชื่อตัวแปรในรหัส C และ C ++ เพื่อแยกความแตกต่างว่าตัวแปรตัวชี้เป็นตัวชี้ไปยังองค์ประกอบเดียวหรือตัวชี้ไปยังอาร์เรย์ การนำอนุสัญญานี้ไปใช้มีส่วนรับผิดชอบในการลดปัญหาหน่วยความจำล่มในฐานรหัสของเรา

มันทำให้บางคนรำคาญ (ไม่รู้เลยว่าทำไม)

เหตุผลที่ทำให้ฉันรำคาญคือว่ามันเป็นความเร็วเล็กน้อยในทุกตัวระบุเดียวที่ช้าลงการสแกนภาพของฉันของรหัส เพราะถ้าคุณเป็น z ไปยัง qRead iEnglish cText l เช่น uThis

คำเกลียดความแรงเกินไป IMO คุณสามารถเขียนรหัสของคุณในแบบที่คุณต้องการ; ฉันชอบที่จะไม่ใช้สัญกรณ์ฮังการีในรหัสของตัวเองและเลือกตัวเลือกฉันก็ไม่ต้องการอ่านมันหรือทำงานกับมันในรหัสของคนอื่น

คุณถามว่าทำไมบางคนพบว่าสัญลักษณ์ของฮังการีน่ารำคาญ ฉันไม่สามารถพูดเพื่อผู้อื่นได้ แต่เหตุผลที่ทำให้ฉันรำคาญคือ:

1. มันน่าเกลียด. ชาวฮังการีใช้ชื่อที่เหมาะสมอย่างสมบูรณ์และเติมจำนวนรหัส เมื่อคุณทำให้รหัสนี้อยู่ภายในฉันแน่ใจว่าเหมาะสมแล้ว แต่สำหรับผู้ที่ไม่ได้ฝึกหัดมันก็ดูเหมือนว่ามีคนบางคนปล่อย mangler ชื่อ C ++ ในซอร์สโค้ดของฉัน

2. มันซ้ำซ้อน การประกาศของตัวแปรกำหนดประเภทของมัน ฉันไม่รู้สึกว่าจำเป็นต้องทำซ้ำข้อมูลนั้นในชื่อตัวแปร สิ่งนี้ไม่เป็นความจริงในทุกภาษา: ใน Perl ตัวอย่างเช่น sigils เช่น@หรือ$ ที่เติมไว้กับชื่อตัวแปรกำหนดประเภทของตัวแปรเป็นหลักดังนั้นคุณจึงไม่มีทางเลือกนอกจากใช้

3. มันแก้ปัญหาที่ฉันไม่มี วิธีการและฟังก์ชั่นไม่ควรยาวจนคุณต้องมองอย่างหนักเพื่อค้นหาการประกาศของตัวแปรท้องถิ่นหรือพารามิเตอร์และพวกเขาไม่ควรเกี่ยวข้องกับตัวแปรมากมายที่คุณมีปัญหาในการติดตามสิ่งที่เกิดขึ้น การประกาศตัวแปรท้องถิ่นใกล้กับรหัสที่ใช้พวกเขาช่วยในส่วนนี้เช่นกัน คอมไพเลอร์ C ในอดีตต้องการให้ประกาศตัวแปรท้องถิ่นทั้งหมดที่จุดเริ่มต้นของฟังก์ชั่น แต่ข้อ จำกัด นั้นถูกลบไปนานแล้ว

4. มันไม่สมบูรณ์ สัญกรณ์ฮังการีถูกประดิษฐ์ขึ้นสำหรับภาษา (BCPL) ที่ไม่มีระบบการพิมพ์และต่อมาถูกนำมาใช้อย่างกว้างขวางในภาษา (C) ที่มีประเภทภาษาพื้นเมืองจำนวนค่อนข้าง จำกัด IMO มันใช้งานไม่ได้กับภาษาอย่าง C ++ หรือ Java ที่มีระบบการพิมพ์ที่หลากหลาย เหตุใดฉันจึงต้องการใช้ส่วนนำหน้าเพื่อระบุประเภทของตัวแปรที่เป็นชนิดเนทีฟเช่น char [] แต่ไม่ใช่คลาสที่ใช่ อีกทางหนึ่งถ้าฉันเริ่มประดิษฐ์คำนำหน้าเช่นvecสำหรับชั้นเรียนฉันจะจบลงด้วยลำดับชั้นขนาดใหญ่ของคำนำหน้าขนานกับลำดับชั้นของฉัน หากสิ่งนั้นดึงดูดคุณคุณก็ยินดีต้อนรับ แค่คิดว่ามันทำให้ฉันปวดหัว

5. มันคลุมเครืออย่างน้อยเป็นอย่างที่ผมเข้าใจมัน ความแตกต่างระหว่างszFooและpszFooคืออะไร อันแรกคือสตริงที่สิ้นสุดด้วยศูนย์และที่สองคือตัวชี้ไปยังสตริงที่สิ้นสุดด้วยศูนย์ แต่ใน C หรือ C ++ เท่าที่ฉันรู้ตัวแปรสตริงใด ๆ เป็นตัวชี้อย่างมีประสิทธิภาพดังนั้นพวกเขาจะเหมือนกันหรือไม่? ฉันควรใช้แบบไหน คำตอบที่แท้จริงนั้นไม่สำคัญ - ประเด็นคือฉันไม่สามารถแยกแยะคำตอบได้โดยใช้สัญลักษณ์ที่ควรจะช่วยฉันหลีกเลี่ยงคำถามประเภทนี้ ในทางกลับกันการประกาศของตัวแปรนั้นจะต้องไม่คลุมเครือเพราะเป็นสิ่งที่คอมไพเลอร์ใช้

นี่คือสิ่งที่รบกวนฉันเกี่ยวกับสัญกรณ์ฮังการี แม้ว่าจะเป็นกลุ่ม แต่ฉันไม่คิดว่าพวกเขาจะอธิบายได้อย่างสมบูรณ์ว่าทำไมชาวฮังการีถึงถูกทอดทิ้งเป็นส่วนใหญ่ นี่คือสามเหตุผลใหญ่ที่สุดที่โปรแกรมเมอร์ส่วนใหญ่ไม่ใช้ภาษาฮังการี:

1. ไม่มีเหตุผลที่น่าสนใจที่จะใช้มัน ดูรายการ 3 และ 4 ด้านบน ฉันอาจจะมีชีวิตอยู่กับความรำคาญถ้าชาวฮังกาเรียนเสนอข้อได้เปรียบที่สำคัญมากกว่าการไม่ใช้ภาษาฮังการี แต่ฉันไม่เห็นใครเลยและคนอื่น ๆ ส่วนใหญ่ก็ไม่เห็นด้วยเหมือนกัน บางทีสิ่งที่ดีที่สุดเกี่ยวกับฮังการีก็คือมันเป็นแบบแผนที่ใช้กันอย่างแพร่หลายและถ้าคุณติดอยู่กับการใช้มาตรฐานคุณอาจคาดหวังว่าโปรแกรมเมอร์คนอื่น ๆ ที่มีทักษะคล้ายกันจะสามารถเข้าใจสัญกรณ์ได้

2. เพิ่มอิทธิพลของ บริษัท ที่ไม่ใช่ Microsoft มันอาจยุติธรรมที่จะบอกว่าโปรแกรมเมอร์ส่วนใหญ่ที่ใช้สัญลักษณ์ของฮังการีทำเช่นนั้นเพราะนั่นคือวิธีที่ Microsoft เขียนโค้ดและมักจะง่ายขึ้นในการดำเนินการ บริษัท ต่างๆเช่น Google และ Apple มีอิทธิพลเหนือกว่าที่เคยทำมาในอดีตและโปรแกรมเมอร์จำนวนมากที่ไม่เคยมีมาก่อนใช้รูปแบบของ บริษัท เหล่านั้นและ บริษัท อื่น ๆ ที่หลบเลี่ยงชาวฮังการี (เป็นธรรมเพียงชี้ให้เห็นว่าคุณยังคงเห็นเศษบางอย่างเช่น Google และ Apple มักจะใช้คำนำหน้า 'k' สำหรับชื่อคงที่)

3. Microsoft เองได้ละทิ้งฮังการี หากคุณตรวจสอบส่วนข้อตกลงการตั้งชื่อทั่วไปของ Microsoft ของแนวทางการเข้ารหัสคุณจะพบว่าเป็นตัวหนา: อย่าใช้สัญกรณ์ฮังการี

ดังนั้นเหตุผลหนึ่งที่ถูกต้องในการหยุดใช้สัญกรณ์ฮังการีคือ:

ความนิยมของเอกสารฮังการีลดลงจนถึงจุดที่การประชุมไม่เป็นประโยชน์อีกต่อไป โปรแกรมเมอร์น้อยลงใช้หรือเข้าใจวันนี้ฮังการีและการประชุมจึงมีประสิทธิภาพน้อยกว่ามากในการถ่ายทอดข้อมูลที่ควรจะเป็น หากคุณพบว่าเป็นวิธีที่มีประโยชน์ในการเขียนโค้ดในโปรเจ็กต์ส่วนตัวของคุณเองก็มีเหตุผลเล็กน้อยที่จะหยุด อย่างไรก็ตามหากคุณกำลังเขียนรหัสเป็นส่วนหนึ่งของทีมที่ไม่ได้ใช้ภาษาฮังการีอาจเป็นกำแพงระหว่างคุณกับคนอื่น ๆ ในทีมแทนที่จะเป็นกลยุทธ์การสื่อสารที่ประสบความสำเร็จ

จนถึงตอนนี้ฉันเห็นประโยชน์ต่อไปนี้ในการใช้งาน:

• การตั้งชื่อตัวแปรที่สอดคล้องกัน

หากฉันตั้งชื่อตัวแปรทั้งหมดของฉันหลังจากตัวละครจาก The Simpsons นั่นก็คงเหมือนกัน แต่มันจะมีประโยชน์ไหม?

• คุณเห็นประเภทโดยไม่ต้องค้นหา (Intellisense ตาย / ทำดัชนีครึ่งเวลาดังนั้นจึงเป็นเหตุผลที่ถูกต้อง)

นี่คือเหตุผลที่ถูกต้องเพียงอย่างเดียวตามจุดอ่อนของเครื่องมือหนึ่ง ...

• ความหมายยังคงสามารถบรรจุลงในส่วนที่สองของชื่อ

นั่นไม่ใช่ผลประโยชน์ คุณแค่อ้างว่าไม่มีข้อเสีย( ใหญ่ )

IDE จะบอกฉันนิดหน่อยว่าประเภทของตัวแปรคืออะไรเมื่อฉันวางเมาส์เหนือมัน เหตุใดจึงต้องทำซ้ำข้อมูลนั้น โดยพื้นฐานแล้วสัญกรณ์ระบบของฮังการีเป็นการละเมิด DRY โดยมีข้อผิดพลาดทั้งหมดที่เกี่ยวข้อง เมื่อข้อมูลนั้นเข้าถึงได้ง่ายในสภาพแวดล้อมที่ทันสมัยไม่มีเหตุผลที่จะต้องจ่ายราคานั้น

ความมั่นคงไม่ได้เปรียบในตัวของมันเอง ไม่ตั้งชื่อพวกเขาด้วยประเภทยังสอดคล้อง คุณจะมีความไม่ลงรอยกันหากตัวแปรบางตัวเท่านั้นที่มีประเภทของพวกเขาในชื่อ และการบรรจุซีแมนทิกส์ลงในส่วนที่สองนั้นก็คือ "ก็ไม่ได้แย่ขนาดนั้น" คนอื่น ๆ ก็ใช้ชื่อทั้งหมดของซีแมนทิกส์ คุณไม่มีข้อได้เปรียบที่แท้จริงใด ๆ ในรายการ

อีกประเด็นที่มีรูปแบบดั้งเดิมของสัญกรณ์ฮังการีคือพวกเขามักจะนำหน้า มี 2 ​​ปัญหา imho ที่นี่:

1) ผู้อ่านโดยทั่วไปมนุษย์ต้องการข้อมูลที่สำคัญที่สุดก่อนในรูปแบบส่วนใหญ่ของฮังการีข้อมูลที่เข้ารหัสนั้นมีความสำคัญน้อยกว่าชื่อของตัวเอง

2) คำนำหน้าเอฟเฟกต์คำศัพท์การเรียงลำดับดังนั้นถ้าเช่นคุณจะใช้คำนำหน้าเพื่อแสดงอินเตอร์เฟสหรือคลาสและ IDE ของคุณมีรายการเรียงลำดับของคลาส / อินเตอร์เฟสที่เกี่ยวข้องเหล่านี้จะถูกแยกออกจากรายการนี้

เห็นได้ชัดว่านี่เป็นความคิดเห็นดังนั้นจึงเป็นเรื่องยากที่จะทำงานกับข้อเท็จจริงที่นี่ โดยส่วนตัวแล้วฉันพบว่าข้อโต้แย้งสำหรับสัญกรณ์ฮังการีมีความบางในภาษาเชิงวัตถุ จากประสบการณ์ของฉันแอปพลิเคชัน OO มักจะจัดการกับความซับซ้อนโดยทำให้คลาสมีความเชื่อมโยงกันและกระชับและสิ่งเดียวกันสามารถพูดได้เกี่ยวกับฟังก์ชั่น ซึ่งหมายความว่าทุกสิ่งเท่าเทียมกันคุณจะได้:

• เรียน / ประเภทเพิ่มเติม
• วิธีการที่สั้นกว่า

ตอนนี้ถ้าคุณต้องการใช้รูปแบบฮังการีคุณต้องตัดสินใจว่าจะใช้มันกับบอร์ดหรือจะใช้มันกับประเภทและคลาสที่ได้รับการยกเว้น (เช่นคลาสไลบรารีหลัก) หลังไม่มีเหตุผลสำหรับฉันและอดีตนำไปสู่ ​​"เขาวงกตของการพยายามที่จะหาตัวย่อที่แตกต่างกันเป็นพันประเภทที่แตกต่าง" ที่PéterTörökถูกอ้างถึง ซึ่งหมายความว่ามีค่าใช้จ่ายที่สำคัญในการรักษารายการตัวย่อและมักจะ "ตั้งชื่อตัวแปรที่สอดคล้องกัน" ออกไปนอกหน้าต่าง

จุดที่สองเกี่ยวกับวิธีการที่สั้นกว่าหมายความว่าในกรณีส่วนใหญ่คุณจะไม่ต้องผ่านโค้ดหลายร้อยบรรทัดเพื่อตรวจสอบว่าตัวแปรประเภทใด การตั้งชื่อตัวแปรเล็กน้อยมากขึ้นอย่างระมัดระวังจะกำจัดบางส่วนของคำถามอื่น ๆ ของคุณ - เช่นเทียบกับเพียงcityName cityฉันหวังว่าcityNameจะไม่ลอย :)

เกี่ยวกับสาเหตุที่ทำให้คนอื่นรู้สึกรำคาญ - อีกครั้งนี่อาจเป็นเรื่องที่คุ้นเคยกับมันหรือไม่ แต่ในฐานะที่เป็นคนที่ไม่คุ้นเคยกับมันฉันสามารถบอกคุณได้ว่าการใช้สัญกรณ์ฮังการีทำให้การอ่านรหัสผิดเพี้ยนไปทำให้การอ่านเร็วขึ้น เพื่อสรุปฉันไม่ได้บอกว่ามันไม่มีบุญ (แม้ว่าฉันยังไม่ได้พูดถึงข้อเสียบางประการในแง่ของการปรับโครงสร้าง ฯลฯ ) ฉันกำลังบอกว่าความพยายามไม่คุ้มค่าสำหรับภาษา OO ที่พิมพ์ออกมาอย่างรุนแรง

ฉันไม่ทราบในบริบทของ C ++ แต่ใน Java / C # world ฉันชอบที่จะมีชื่อที่สื่อความหมายซึ่งถ่ายทอดภาษาโดเมนหรือบริบทมากกว่าบอกฉันว่าstrFirstNameเป็นสตริง ควรชัดเจนว่าเป็นสตริงหรือชื่อต้องได้รับการปรับโครงสร้างใหม่เพื่อแสดงเจตนาที่ดีกว่า หากคุณต้องการคำนำหน้าเพื่อให้ทราบประเภทของสิ่งที่คุณกำลังทำงานด้วยฉันจะโต้แย้งว่าการตั้งชื่อของคุณไม่สอดคล้องกันไม่ได้อธิบายเพียงพอหรือผิดอย่างสิ้นเชิง ในภาษาสมัยใหม่ฉันมักต้องการชื่อที่ยาวกว่าซึ่งไม่ทำให้เกิดความกำกวมมากกว่าชื่อที่คลุมเครือหรือคลุมเครือ

ครั้งเดียวที่ฉันใช้ภาษาฮังการีสำหรับการควบคุม ASP.NET และนั่นก็คือ IA) ไม่จำเป็นต้องพิมพ์บางสิ่งที่ยาวเหมือนCustomerFirstNameTextBoxเมื่อเทียบกับtxtCustomerFirstNameและ B) Intellisense จะเรียงลำดับตัวควบคุมทั้งหมด ฉันรู้สึกว่า "สกปรก" ถึงแม้จะทำเช่นนั้นฉันก็ยังไม่ได้หาวิธีที่ดีกว่า

Meh - มันคือทั้งหมดที่เกี่ยวกับการตั้งค่าส่วนตัวไม่ว่าใครจะพยายามอย่างหนักเพื่อหาเหตุผลเลือกของพวกเขา ฉันติดอยู่กับกฎ "เมื่ออยู่ในโรม ... " และใช้ภาษาฮังการีในรหัสที่เรียก Windows API เป็นอย่างมาก สำหรับโค้ดที่ไม่ขึ้นกับแพลตฟอร์มฉันมักจะทำตามสไตล์ C ++ Standard Library

คำตอบอยู่ในคำถามนี้: โปรดบอกวิธีตั้งชื่อตัวแปรต่อไปนี้:

ถ่าน * nullTerminatedString;
wchar * nullTerminatedWideString;
สตริง stlString;
wstring stlWideString;
CString mfcString;
BSTR comString;
_bstr_t atlString;

เพิ่มไปยังสตริงคงที่เหล่านี้ตัวชี้ไปยังตัวชี้เหล่านี้และพอยน์เตอร์คงที่เหล่านี้

ฉันไม่ชอบรูปแบบของสัญกรณ์ฮังการีที่คุณอธิบาย เหตุผล? ไม่มีจุด 90% ของเวลา

ตัวอย่างเช่นรหัสบิต (เทียบเท่า C ++. จริงเขียนใน Delphi) จากโครงการดั้งเดิมที่ฉันถูกบังคับให้ต้องทน:

pRecords[0]->FooMember=10;

... pRecord เป็นตัวแปรมันเป็นประเภท TRecordList TRecordList *pRecords[10];

เป็นคลาสที่ประกอบด้วย orioerty ชื่อว่า FooMember ซึ่งชี้ไปที่ fFooMember ... หรือ mFooMember ขึ้นอยู่กับว่าเป็น "ฟิลด์" หรือ "สมาชิก" (คำใบ้: มันเหมือนกัน)

ปัญหา? fFooMemberอาจเป็นอะไรที่เหมือนกับ FooMember_ เพราะเราจะเข้าถึงมันผ่านทางทรัพย์สินสาธารณะ FooMember pRecords? เห็นได้ชัดว่ามันเป็นตัวชี้จากข้อเท็จจริงที่ว่าคุณอ้างถึงทุกที่ TRecordList? เมื่อใดที่คุณสามารถสร้างความสับสนให้กับชื่อประเภทและวัตถุประเภทนั้น? คอมไพเลอร์จะตะโกนใส่คุณและประเภทจะใช้ในสถานที่เกือบจะไม่มีวัตถุ (ยกเว้นคุณสมบัติ / วิธีการคงที่)

ตอนนี้มีที่เดียวที่ฉันใช้สัญกรณ์ฮังการี นี่คือเมื่อจัดการกับตัวแปร UI จำนวนมากที่จะมีชื่อเดียวกันกับตัวแปร UI อื่น ๆ หรือตัวแปรปกติ

ตัวอย่างเช่นถ้าฉันมีแบบฟอร์มสำหรับชื่อของคุณ

ฉันมีคลาสชื่อ FirstNameForm ภายในนั้น lblFirstName และ txtFirstName สำหรับป้ายกำกับและกล่องข้อความตามลำดับ และคุณสมบัติ FirstName สาธารณะสำหรับการรับและการตั้งชื่อในกล่องข้อความ

สิ่งนี้สามารถแก้ไขได้โดยใช้ FirstNameLabel และ FirstNameTextBox แต่ฉันพบว่ามันใช้เวลานานในการพิมพ์ โดยเฉพาะอย่างยิ่งกับสิ่งที่ชอบออฟเพศชายและรายการอื่น ๆ

ดังนั้นโดยทั่วไปสัญกรณ์ฮังการีคือที่ดีที่สุดน่ารำคาญในระดับระบบและเป็นกรณีที่เลวร้ายที่สุดที่เป็นอันตราย (ตามคำตอบอื่น ๆ ให้เกี่ยวกับปัญหาเกี่ยวกับการปรับโครงสร้างและความมั่นคง)