คุณนำหน้าชื่อตัวแปรด้วยตัวย่อของชนิดตัวแปรหรือไม่? (สัญลักษณ์ของฮังการี) [ปิด]

ในงานปัจจุบันของฉันไม่มีแนวทางการเข้ารหัส ทุกคนสวยมากในแบบที่เขาต้องการ ซึ่งเป็นเรื่องดีเนื่องจาก บริษัท มีขนาดเล็ก

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

โดยส่วนตัวแล้วฉันรู้สึกว่าตัวย่อแบบเล็ก ๆ เหล่านี้ซ้ำซ้อน ชื่อที่คิดมาอย่างดีมักจะส่งข้อความเดียวกัน (ยิ่งไปกว่านั้นโค้ดส่วนใหญ่ของเราต้องทำงานกับ DSP ที่แปลกประหลาดบางอย่างซึ่งมีแนวคิดเหมือนboolหรือfloatไม่มีอยู่แล้ว)

ดังนั้นคุณรู้สึกอย่างไรเกี่ยวกับสัญลักษณ์ของฮังการี? คุณใช้หรือไม่ ทำไม?

เมื่อคนส่วนใหญ่พูดว่า "Hungarian Notation" พวกเขากำลังพูดถึง " Systems Hungarian "

ระบบฮังการีไม่มีประโยชน์อย่างสมบูรณ์และควรหลีกเลี่ยง ไม่จำเป็นต้องเข้ารหัสชนิดของตัวแปรในชื่อของมัน อย่างไรก็ตาม Systems Hungarian เป็นความเข้าใจผิดของต้นฉบับ "จริง" ของฮังการี: Apps Hungarian

ใน Apps Hungarian คุณไม่ได้เข้ารหัส "ประเภท" ในชื่อตัวแปรคุณเข้ารหัส "ชนิด" ของตัวแปร ดังนั้นไม่ใช่nWidthแต่pxWidthหรือemWidth(สำหรับ "ความกว้างเป็นพิกเซล" หรือ "ความกว้างเป็น ems" ตามลำดับ) ไม่strNameแต่sNameหรือusName(สำหรับ "ชื่อที่ปลอดภัย" หรือ "ชื่อที่ไม่ปลอดภัย" ตามลำดับ - มีประโยชน์การป้อนข้อมูลเมื่อรับจากผู้ใช้: สตริงที่ไม่ปลอดภัย)

โดยส่วนตัวแล้วฉันมักจะไม่รำคาญด้วยเช่นกัน นอกจากว่าฉันกำลังทำอะไรบางอย่างที่แปลงค่า "ชนิด" อย่างชัดเจน (ตัวอย่างเช่นฉันเคยใช้คำนำหน้า "px" และ "em" ในอดีตเพราะมันทำผิดพลาดอย่างpxArea = emWidth * emHeightชัดเจน)

ดูเพิ่มเติมที่บทความของ Joel "การสร้างรหัสผิดให้ดูผิด "

คำสรรพนามคุณต้องใช้คำกริยาคำวิเศษณ์ใช้คำนามคำนามคำพ้องความหมายคำกริยามันทำให้กลุ่มคำนามคำกริยาทำให้การรวบรวมคำสรรพนามคำวิเศษณ์คำทุกคำ

ประการแรก:

คุณรู้ไหมว่าเป็น บริษัท ด้านวิศวกรรมดังนั้นรูปแบบการเข้ารหัสจึงไม่สำคัญตราบใดที่อัลกอริทึมนั้นมีเสียง

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

ตอนนี้เข้าสู่สัญกรณ์ฮังการี:

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

อย่าใช้มัน มันซ้ำซ้อนและทำให้อ่านรหัสยากขึ้น

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

ระบบฮังการี

จากสิ่งที่ฉันสามารถบอกได้ระบบของฮังการีมีแนวโน้มที่จะใช้งานจำนวนมากในฟิลด์แบบฝังตัว ในพีซีแอพพลิเคชั่นคอมไพเลอร์จะจัดการกับปัญหามากมายที่เกี่ยวข้องกับความแตกต่างระหว่างสตริง (เช่น) จำนวนเต็มและค่าทศนิยม บนแพลตฟอร์มที่ฝังลึกคุณมักจะกังวลเกี่ยวกับความแตกต่างระหว่างจำนวนเต็ม 8 บิตที่ไม่ได้ลงนามจำนวนเต็ม 16 บิตที่ได้รับการรับรองเป็นต้นคอมไพเลอร์ (หรือแม้แต่การบังคับใช้กฎ MISRA) ไม่ได้รับสิ่งเหล่านี้เสมอไป ในกรณีนี้มีชื่อตัวแปรชอบu8ReadIndex, s16ADCValueจะมีประโยชน์

แอพ Hungarian

Apps Hungarian มีข้อได้เปรียบที่ชัดเจนเมื่อพูดถึงแอปพลิเคชัน PC / เว็บเช่นเสนอความแตกต่างที่มองเห็นได้ระหว่างสตริง 'unsafe' และ 'safe' strings (เช่นที่ป้อนโดยผู้ใช้และผู้ที่ถูกหลบหนีหรืออ่านจากทรัพยากรภายในหรืออะไรก็ตาม ) ผู้แปลไม่มีความรู้เรื่องความแตกต่างนี้

ประเด็นคืออะไร?

การใช้ (ระบบหรือ Apps) ฮังการีคือทั้งหมดที่เกี่ยวกับการทำรหัสผิดที่ผิดลักษณะ

หากคุณกำลังคัดลอกสตริงที่ไม่ปลอดภัยลงในสตริงที่ปลอดภัยโดยไม่ต้องหลบหนีบางอย่างมันจะผิดถ้าคุณใช้ Apps Hungarian

หากคุณคูณจำนวนเต็มที่ลงนามด้วยจำนวนเต็มที่ไม่ได้ลงชื่อคอมไพเลอร์จะ (มักจะเงียบ) ส่งเสริมการลงชื่อหนึ่ง (เป็นไปได้มหาศาล) ไม่ได้ลงนามอาจส่งผลให้เกิดข้อผิดพลาด: ระบบฮังการีทำให้ดูผิด

ในทั้งสองกรณีนี้ (แอพ / ระบบ) สัญกรณ์ฮังการีมีแนวโน้มที่จะทำการตรวจสอบโค้ดอย่างเป็นทางการได้เร็วขึ้นเนื่องจากมีการอ้างอิงน้อยลงกับประเภทของตัวแปร

Adj] ทั้งหมด, รวมทั้งหมด, รวมทั้งสิ้น

โดยรวมแล้วความคิดเห็นของฉันคือสิ่งที่สำคัญที่สุดคือคุณมีมาตรฐานการเข้ารหัส ไม่ว่าจะใช้ Systems Hungarian, Apps Hungarian หรือไม่ใช่เรื่องของการตั้งค่าส่วนตัวหรือกลุ่มเหมือนตัวเลือกประเภทการเยื้องเป็นต้นอย่างไรก็ตามมีข้อดีที่แน่นอนสำหรับทีมพัฒนาทั้งหมดที่ทำงานในลักษณะเดียวกัน

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

หรือเพื่อทำให้สำเร็จมากขึ้น: ข้อมูลประเภทเป็นของระบบประเภท (หมายเหตุ: มันไม่จำเป็นต้องเป็นระบบแบบสแตติกตราบใดที่มันจับข้อผิดพลาดประเภทฉันไม่สนใจว่าเมื่อมันจับพวกเขา)

สองสามคำตอบอื่น ๆ ที่กล่าวถึงหน่วยวัดเป็นการใช้ที่ยอมรับได้ของสัญลักษณ์ของฮังการี (ฉันรู้สึกประหลาดใจที่ไม่มีใครพูดถึง NASA Mars Climate Orbiter เนื่องจากมันดูเหมือนว่าจะเกิดขึ้นตลอดเวลาในการอภิปรายเกี่ยวกับสัญกรณ์ฮังการี)

นี่คือตัวอย่างง่ายๆใน F #:

[<Measure>] type m
[<Measure>] type ft

let someLength      = 48.15<m>
let someOtherLength = 16.2342<ft>

someLength + someOtherLength
// someLength + someOtherLength
// -------------^^^^^^^^^^^^^^^
// error FS0001: The unit of measure 'ft' does not match the unit of measure 'm'.

ดูสิไม่มีชาวฮังการี!

ถ้าฉันได้ใช้ฮังการีโน้ตแทนประเภทที่นี่ที่จะไม่ช่วยให้ฉันหนึ่งบิต:

let mSomeLength       = 48.15
let ftSomeOtherLength = 16.2342

mSomeLength + ftSomeOtherLength
// > val it : float = 64.3842

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

ยิ่งไปกว่านั้นการใช้ภาษาการเขียนโปรแกรม Frink :

someLength      = 48.15m
someOtherLength = 16.2342ft

someLength + someOtherLength
// 53.09818416 m (length)

// Wanna know the answer in a good old fashioned American unit?
someLength + someOtherLength -> yd
// 58.06888031496062992

// Are you an astrophysicist?
someLength + someOtherLength -> parsec
// 1.7207949554318336148e-15

// ... or a fundmentalist Christian who refuses to use units invented 
// less than 2000 years ago?
someLength + someOtherLength -> biblicalcubits
// 95.893563822870765006

ดังนั้นโดยสรุป: ฉันไม่ชอบสัญกรณ์ฮังการี คุณไม่ควรใช้มัน

ที่ถูกกล่าวว่าฉันคิดว่าการใช้สัญลักษณ์ฮังการีเป็นความคิดที่ดี รออะไร?

ใช่ ในกรณีพิเศษนี้คุณพูดถึง:

นอกจากนี้โค้ดส่วนใหญ่ของเราต้องทำงานกับ DSP ที่แปลกประหลาดบางอย่างซึ่งแนวคิดอย่างบูลหรือโฟลไม่มีอยู่จริง

แต่ที่เป็นได้อย่างแม่นยำเพียงกรณีการใช้งานที่เหมาะสมสำหรับฮังการีโน้ต!

PS: ฉันขอแนะนำให้ดู Frink ด้วยใจจริง คู่มือมีบางส่วนที่ตลกที่สุดผายลม มันยังเป็นภาษาที่ค่อนข้างเท่ห์ :-)

มันไม่สมเหตุสมผลในภาษาที่เน้นวัตถุ - ทุกอย่างเป็นประเภทที่เห็นได้ชัดเมื่อพยายามใช้

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

หากคุณมีหน่วยการวัดอาจช่วยในการเข้ารหัสในชื่อ - แต่ในที่สุดก็อาจเป็นเสียงรบกวนพิเศษ ตัวอย่างเช่นเราจะประกาศหน่วยวัดมาตรฐานสำหรับสิ่งต่าง ๆ ที่เรากำลังทำงานด้วยในรหัสของเรา ตัวอย่างเช่นเราใช้การไล่ระดับสีหรือองศาเมตรหรือฟุตเฟรมหรือมิลลิวินาทีหรือไม่ เมื่อมีการตั้งค่ามาตรฐานสำหรับรหัสเมื่อใดก็ตามที่เราอ่านในหน่วยวัดหนึ่งหน่วยเราจะแปลงหน่วยมาตรฐานเป็นหน่วยทันที

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

ตรวจสอบไม่!

อย่าใช้สัญกรณ์ฮังการีหรือสัญกรณ์อื่น ๆ ในฐานะโปรแกรมเมอร์เราไม่ควรใช้ "สัญกรณ์" สำหรับชื่อตัวแปรของเรา

สิ่งที่เราควรทำคือตั้งชื่อตัวแปรของเราให้ดี :

• หลีกเลี่ยงชื่อทั่วไปเกินไป อย่าตั้งชื่อzเมื่อตัวแปรคลาสแสดงถึงวัตถุที่มีชื่อพูดค่าโทรศัพท์ เรียกมันหรือphoneBillPhoneBill

• หลีกเลี่ยงชื่อเฉพาะเกินไป เมื่อสิ่งที่ชัดเจนโดยไม่มีข้อมูลเพิ่มเติมจะไม่รวม หากเป็นเพียงตัวแปรดัชนีสตริงสำหรับการวนซ้ำอักขระของสตริงและคุณใช้เพียงครั้งเดียวในฟังก์ชั่น MyFunc ทำไมคุณต้องเรียกมันว่าบนโลกMyFuncTempStringCharacterIndex? นั่นเป็นเรื่องตลกที่น่าเศร้า โทรPosหรือแม้ว่าiคุณต้องการ ในบริบทโปรแกรมเมอร์ถัดไปจะเข้าใจความหมายได้ง่าย

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

ในฐานะที่เป็น answerers อื่น ๆ ได้กล่าวว่ามันเป็นกรณีแคบ ๆ นี้ที่เริ่มต้น "แอปฮังการี" ความแตกต่างระหว่างการวัดเทียบกับหน้าต่างและเทียบกับเอกสารrwTabPosition rdTabPositionแต่ในแอปพลิเคชันที่ทำทุกอย่างที่เกี่ยวข้องกับเอกสารอย่าเพิ่ม cruft พิเศษใด ๆ ! ในความเป็นจริงทำไมไม่ลองใช้แนวคิดของJörg W Mittagในการสร้างรูปแบบใหม่ที่แท้จริง ถ้าอย่างนั้นคุณก็อาจจะไม่ได้ปะปนกัน

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

vrb อย่าแนะนำ vrbuse nou คำนามภาษาฮังการี cnjor adjany adjother adounother nounotation prepAs nouprogrammers prowe vrbshould แนะนำ verbe nouusing "คำนาม" prpfor proour adounvariable คำนาม

ด้วยการเพิ่มข้อมูลทำให้ฉันรู้สึกเจ็บปวดอย่างมากที่จะอ่าน

ดังนั้นลืมสัญกรณ์ ลืมคำนำหน้าพิเศษที่คุณเพิ่มไว้เสมอ ในความคิดของฉันแนวทางที่แท้จริงเท่านั้นที่นี่ควรเป็น:

ให้ชื่อตัวแปรเป็นสั้นที่เป็นไปได้ในขณะที่มีความหมายตามความจำเป็นและมักจะโปร่งใส

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

เราใช้ภาษาฮังการีย้อนกลับมาตอนที่ฉันเป็นโปรแกรมเมอร์ C ++ และมันก็เยี่ยมมาก คุณสามารถดูประเภทของตัวแปร (fe BSTR, CString, LPCTSTR หรือ char *) โดยไม่ต้องค้นหาการประกาศ ในสมัยนั้นคุณจะต้องค้นหาคำประกาศโดยทำ:

1. Ctrl-บ้าน
2. Ctrl-F
3. ชื่อตัวแปร
4. เข้าสู่

ดังนั้นมันจึงค่อนข้างสำคัญ แต่มีประมาณปี 2000 มีบางอย่างเกิดขึ้น:

• บรรณาธิการกลายเป็นคนฉลาดพอที่จะแสดงประเภทตัวแปรเป็นคำแนะนำเครื่องมือ
• บรรณาธิการมีทางลัด "ไปยังการประกาศ" และวิธีที่รวดเร็วในการเรียกดูย้อนกลับ
• C ++ ใช้น้อยลงและภาษาอื่น ๆ ส่วนใหญ่มีประเภทตัวแปรน้อยลง ตัวอย่างเช่นใน C # คุณค่อนข้างมั่นใจว่าlastNameเป็นSystem.Stringเพราะมีคลาสสตริงเดียวเท่านั้น

ฉันเป็นคนสุดท้ายที่จะเปลี่ยนจากฮังการีและตอนนี้เมื่อฉันอ่านซอร์สโค้ดเก่ามันทำให้ฉันรำคาญจริง ๆ

ฉันแค่เกลียดสัญกรณ์ฮังการีฉันชอบใช้ขีดล่างเพื่อคั่นชื่อตัวแปร

ยิ่งไปกว่านั้นเมื่อคุณใส่ตัวอักษรเป็นตัวอักษรตัวแรกที่จุดเริ่มต้นของชื่อตัวแปรของคุณเช่นนี้: float fvelocity; vect vDirection; สตริง ** ppszWord;

การเติมข้อความอัตโนมัติคัดแยกพวกเขาทั้งหมดและคุณมีปัญหาในการค้นหาสิ่งที่คุณต้องการและผู้คนมักจะใช้สิ่งที่พวกเขาคิดว่าดีกว่าและไม่ใช่โน้ตอีกต่อไป

ฉันชอบเขียนสิ่งต่าง ๆ เช่นนั้นเมื่อฉันต้องการอธิบายเกี่ยวกับตัวแปรได้มากเพราะช่วยประหยัดพื้นที่และความจริงที่มีตัวพิมพ์ใหญ่ทำให้อ่านได้ง่ายขึ้น

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

ฉันต้องการให้ผู้คนสนใจกฎเหล่านั้นอย่างจริงจัง: ใช้เครื่องหมายจุลภาคคณิตศาสตร์และเครื่องหมายวงเล็บที่มีช่องว่างที่เกี่ยวข้อง:

void f(int a, char b);
int a = b + 4 / (3 + 4);

ไม่เกิน 80 อักขระต่อบรรทัดหรือ AT MOST 90 chars ใช้อาร์กิวเมนต์หลายบรรทัดสำหรับฟังก์ชั่นหรือยาวif:

if
(
    checkthat(a, b) == checkthis(b, d) &&
    checkthat(d, b) == checkthis(v, d)
)

เห็นด้วยกับส่วนใหญ่มันเป็นแบบเก่า

ด้วยความทันสมัยของ IDE การวางเมาส์ไว้เหนือตัวแปรจะแสดงประเภทให้คุณทราบ