เคยมีเหตุผลที่ดีมากในการรักษาชื่อคำสั่ง / ทะเบียนย่อ เหตุผลเหล่านั้นใช้ไม่ได้อีกต่อไป แต่ชื่อรหัสลับสั้น ๆ ยังคงพบได้บ่อยในการเขียนโปรแกรมระดับต่ำ

ทำไมนี้ มันเป็นเพราะนิสัยเก่านั้นยากที่จะทำลายหรือมีเหตุผลที่ดีกว่า?

ตัวอย่างเช่น:

• Atmel ATMEGA32U2 (2010?): TIFR1(แทนTimerCounter1InterruptFlag), ICR1H(แทนInputCapture1High), DDRB(แทนDataDirectionPortB), ฯลฯ
• ชุดคำสั่ง. NET CLR (2002): bge.s(แทนbranch-if-greater-or-equal.short) ฯลฯ

ชื่อที่ไม่ได้เป็นความลับใช้งานได้นานกว่าหรือไม่

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

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

อะไรคือสิ่งที่สำคัญที่แตกต่างเกี่ยวกับการเขียนโปรแกรมระดับต่ำเมื่อเทียบกับภาษาระดับสูงที่ทำให้ชื่อที่เป็นความลับสั้น ๆ เป็นที่ต้องการในการเขียนโปรแกรมระดับต่ำ แต่ไม่ใช่การเขียนโปรแกรมระดับสูง

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

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

นอกจากนี้สิ่งต่าง ๆ เช่นแผนผังแผนภาพเข็มหมุดและผ้าไหม PCB มักจะแคบมากสำหรับพื้นที่

กฎหมายของ Zipf

คุณเองสามารถสังเกตได้โดยดูที่ข้อความนี้ว่าโดยทั่วไปความยาวของคำและความถี่ในการใช้งานมีความสัมพันธ์กันโดยทั่วไป คำที่ใช้บ่อยมากเช่นit, a, but, youและandสั้นมากในขณะที่คำที่ถูกนำมาใช้น้อยมักจะชอบobserve, comprehensionและverbosityมีความยาว ความสัมพันธ์ระหว่างการสังเกตความถี่และระยะเวลาที่เรียกว่ากฎหมาย Zipf ของ

จำนวนคำสั่งในชุดคำสั่งสำหรับไมโครโปรเซสเซอร์ที่ให้นั้นมักจะเป็นตัวเลขเป็นสิบหรือหลายร้อย ตัวอย่างเช่นชุดคำสั่ง Atmel AVR มีชุดคำสั่งที่แตกต่างกันประมาณร้อยชุด (ฉันไม่ได้นับ) แต่หลายคำสั่งเป็นชุดรูปแบบในชุดรูปแบบทั่วไปและมีคำย่อที่คล้ายคลึงกันมาก ตัวอย่างเช่นคำแนะนำการคูณรวมถึง MUL, MULS, MULSU, FMUL, FMULS และ FMULSU คุณไม่จำเป็นต้องดูรายการคำแนะนำเป็นเวลานานก่อนที่คุณจะได้รับแนวคิดทั่วไปว่าคำสั่งที่ขึ้นต้นด้วย "BR" เป็นกิ่งก้านคำแนะนำที่ขึ้นต้นด้วย "LD" นั้นเป็นภาระ ฯลฯ เช่นเดียวกันกับตัวแปร: ตัวประมวลผลที่ซับซ้อนยังมีสถานที่จำนวน จำกัด ในการจัดเก็บค่า: การลงทะเบียนเงื่อนไขการลงทะเบียนวัตถุประสงค์ทั่วไป ฯลฯ

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

นอกจากนี้ชุดคำสั่งสำหรับโปรเซสเซอร์ที่แตกต่างกันมักจะใช้ชื่อที่คล้ายกันสำหรับการดำเนินการที่คล้ายกัน ชุดคำสั่งส่วนใหญ่รวมถึงการดำเนินการสำหรับ ADD, MUL, SUB, LD, ST, BR, NOP และหากพวกเขาไม่ใช้ชื่อที่แน่นอนพวกเขามักจะใช้ชื่อที่ใกล้เคียง เมื่อคุณเรียนรู้เกี่ยวกับความจำสำหรับชุดคำสั่งหนึ่งชุดแล้วก็ใช้เวลาไม่นานในการปรับให้เข้ากับชุดคำสั่งสำหรับอุปกรณ์อื่น ดังนั้นชื่อที่อาจดูเหมือน "ความลับ" เพื่อที่คุณกำลังเป็นที่คุ้นเคยเป็นคำเช่นand, orและnotโปรแกรมเมอร์ที่มีฝีมือในศิลปะของการเขียนโปรแกรมในระดับต่ำ ฉันคิดว่าคนส่วนใหญ่ที่ทำงานในระดับการชุมนุมจะบอกคุณว่าการเรียนรู้การอ่านรหัสไม่ใช่หนึ่งในความท้าทายที่ยิ่งใหญ่กว่าในการเขียนโปรแกรมระดับต่ำ

โดยทั่วไปแล้ว

คุณภาพของการตั้งชื่อไม่เพียง แต่เกี่ยวกับการมีชื่อที่สื่อความหมายเท่านั้น แต่ยังต้องคำนึงถึงแง่มุมอื่น ๆ และนำไปสู่ข้อเสนอแนะเช่น:

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

โปรดทราบว่าคำแนะนำเหล่านี้ขัดแย้งกัน

ช่วยในการจำ

ในฐานะที่เป็นโปรแกรมเมอร์ภาษาประกอบใช้short-branch-if-greater-or-equalสำหรับbge.sทำให้ผมประทับใจเดียวกันกว่าเมื่อฉันเห็นเป็นโปรแกรมเมอร์ Algol ทำเรขาคณิตการคำนวณแทนSUBSTRACT THE-HORIZONTAL-COORDINATE-OF-THE-FIRST-POINT TO THE-HORIZONTAL-COORDINATE-OF-THE-SECOND-POINT GIVING THE-DIFFERENCES-OF-THE-COORDINATE-OF-THE-TWO-POINTS dx := p2.x - p1.xฉันไม่สามารถตกลงได้ว่าสิ่งแรกสามารถอ่านได้มากขึ้นในบริบทที่ฉันสนใจ

ลงทะเบียนชื่อ

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

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

ระบบสมองกลฝังตัวที่อยู่ใกล้กับฮาร์ดแวร์ - และการเข้าถึงการลงทะเบียนมีแนวโน้มที่จะใช้ฉลากที่เหมือนกันหรือคล้ายกันกับที่ใช้ในแผ่นข้อมูลฮาร์ดแวร์ด้วยเหตุผลที่ดีมาก หากการลงทะเบียนเรียกว่า XYZZY1 ในแผ่นข้อมูลฮาร์ดแวร์รู้สึกว่าตัวแปรที่แสดงว่าน่าจะเป็น XYZZY1 หรือหากโปรแกรมเมอร์มีวันที่ดี RegXYZZY1

เท่าที่bge.sมันคล้ายกับแอสเซมเบลอร์ - กับคนไม่กี่คนที่จำเป็นต้องรู้ว่าชื่อที่ยาวขึ้นนั้นสามารถอ่านได้น้อยกว่า หากคุณไม่สามารถพาคุณไปรอบ ๆbge.sและคิดว่าbranch-if-greater-or-equal.shortจะสร้างความแตกต่าง - คุณแค่เล่นกับ CLR และไม่ทราบ

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

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

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

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

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

• เพราะหลายคนพบเห็นได้ทั่วไปในโดเมนนั้น ๆ เพื่อรับประกันชื่อที่สั้นมาก สิ่งนี้ทำให้ช่วงการเรียนรู้แย่ลง แต่เป็นการแลกเปลี่ยนที่คุ้มค่าหากพิจารณาจากความถี่ในการใช้งาน
• เพราะโดยทั่วไปมักจะมีความเป็นไปได้ที่จะถูกแก้ไขเล็กน้อย (โปรแกรมเมอร์ไม่สามารถเพิ่มลงไปในชุด)
• เพราะการอ่านเป็นเรื่องของนิสัยและการฝึกฝน branch-if-greater-than-or-equal.shortเป็นครั้งแรกที่อ่านได้มากขึ้นกว่าbge.sแต่มีการปฏิบัติบางสถานการณ์จะกลายเป็นตรงกันข้าม
• เพราะพวกเขามักจะต้องพิมพ์ออกมาอย่างเต็มที่ด้วยมือเพราะภาษาระดับต่ำมักจะไม่ได้มาพร้อมกับ IDE ที่ทรงพลังที่มีการเติมข้อความอัตโนมัติที่ดีหรือ a / c ไม่น่าเชื่อถือ
• เนื่องจากบางครั้งเป็นที่พึงปรารถนาที่จะรวบรวมข้อมูลจำนวนมากลงในตัวระบุและชื่อที่อ่านได้จะไม่สามารถยอมรับได้แม้จะเป็นมาตรฐานระดับสูง
• เพราะนั่นเป็นสิ่งที่สภาพแวดล้อมในระดับต่ำดูเหมือนประวัติศาสตร์ การทำลายนิสัยต้องใช้ความพยายามอย่างมีสติเสี่ยงต่อการสร้างความรำคาญให้กับคนที่ชอบวิธีการแบบเก่าและต้องได้รับการพิสูจน์ว่าคุ้มค่า การผสานกับวิธีที่กำหนดไว้คือ "ค่าเริ่มต้น"
• เพราะหลายคนมาจากที่อื่นเช่นแผนงานและแผ่นข้อมูล ในทางกลับกันเหล่านั้นได้รับผลกระทบจากข้อ จำกัด ของพื้นที่
• เพราะคนที่รับผิดชอบเรื่องการตั้งชื่อไม่เคยคิดเลยว่าจะอ่านง่ายหรือไม่รู้ว่าพวกเขากำลังสร้างปัญหาหรือขี้เกียจ
• เนื่องจากในบางกรณีชื่อได้กลายเป็นส่วนหนึ่งของโปรโตคอลสำหรับการแลกเปลี่ยนข้อมูลเช่นการใช้ภาษาแอสเซมบลีเป็นการแสดงสื่อกลางโดยคอมไพเลอร์บางตัว
• เพราะสไตล์นี้เป็นที่รู้จักในระดับต่ำทันทีและดูเท่มาก

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

ฉันจะโยนหมวกของฉันเป็นระเบียบนี้

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

อย่างไรก็ตามบางคนมีจุดประสงค์ แน่นอนว่าBranchGreaterThanจะสามารถอ่านได้มากกว่าBGTมากขึ้นแต่ตอนนี้มีการประชุมแล้วมันเป็นคำสั่งและด้วยเหตุนี้จึงมีแรงฉุดเล็กน้อยในช่วง 30 ปีที่ผ่านมาซึ่งเป็นมาตรฐาน ทำไมพวกเขาเริ่มต้นด้วยมันอาจมีข้อจำกัดความกว้างของอักขระโดยพลการสำหรับคำแนะนำตัวแปรและเช่น; ทำไมพวกเขาถึงเก็บมันมันเป็นมาตรฐาน มาตรฐานนี้เหมือนกับการใช้intเป็นตัวระบุมันจะมีความชัดเจนมากขึ้นในการใช้Integerในทุกกรณี แต่จำเป็นสำหรับผู้ที่เขียนโปรแกรมเกินสองสามสัปดาห์ ... ไม่ ทำไม? เพราะมันเป็นมาตรฐานการปฏิบัติ

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

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

ฉันจะปล่อยให้คุณกับสิ่งนี้: การขอให้ชุมชนฝังตัวเพื่อใช้การปฏิบัติระดับสูง verbose ก็เหมือนการขอให้นักเคมีเขียนสารประกอบเคมี นักเคมีเขียนสั้น ๆ เพื่อตัวเองและคนอื่น ๆ ในสนามจะเข้าใจ แต่อาจต้องใช้เวลาเพิ่มขึ้นเล็กน้อยในการปรับตัว

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

หากนักพัฒนาใหม่เข้ามาในทีมเขาจะต้องอ่านเอกสารข้อมูลทางเทคนิค (ตามที่อธิบายโดย @KarlBielefeldt) เพื่อให้พวกเขารู้สึกสบายใจ

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

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

สรุป

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

สาเหตุของชื่อที่คลุมเครือ:

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

โซลูชั่นและข้อเสีย:

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

คำตอบแบบเต็ม

(A) ชื่อที่ยาวขึ้นเป็นไปได้ ตัวอย่างเช่นชื่อของ C ++ SSE2 intrinsics เฉลี่ย 12 ตัวอักษรเมื่อเทียบกับ 7 ตัวอักษรในการช่วยในการจำ http://msdn.microsoft.com/en-us/library/c8c5hx3b(v=vs.80).aspx

(B) คำถามต่อไป: นานแค่ไหน / ไม่ลับต้องได้รับจากคำแนะนำในระดับต่ำ?

(C) ตอนนี้เราวิเคราะห์องค์ประกอบของแผนการตั้งชื่อดังกล่าว ต่อไปนี้เป็นรูปแบบการตั้งชื่อสองแบบสำหรับคำสั่งระดับต่ำเดียวกัน :

• รูปแบบการตั้งชื่อ # 1: CVTSI2SD
• รูปแบบการตั้งชื่อ # 2: __m128d _mm_cvtsi32_sd (__m128d a, int b);

(C.1) คำแนะนำระดับต่ำมักจะพิมพ์อย่างรุนแรง ไม่สามารถมีความกำกวมการอนุมานประเภทการแปลงชนิดอัตโนมัติหรือการโหลดมากเกินไป (ใช้ชื่อคำสั่งซ้ำเพื่อใช้การดำเนินการที่คล้ายกัน แต่ไม่เทียบเท่า)

(C.2) คำสั่งระดับต่ำแต่ละรายการต้องเข้ารหัสข้อมูลจำนวนมากไว้ในชื่อ ตัวอย่างของข้อมูล:

• สถาปัตยกรรมครอบครัว
• การทำงาน
• อาร์กิวเมนต์ (อินพุต) และเอาต์พุต
• ประเภท (จำนวนเต็มที่ลงนาม, จำนวนเต็มที่ไม่ได้ลงนาม, ลอย)
• ความแม่นยำ (ความกว้างบิต)

(C.3) ถ้าสะกดข้อมูลแต่ละชิ้นโปรแกรมจะละเอียดมากขึ้น

(C.4) รูปแบบการเข้ารหัสประเภทที่ผู้ขายต่างๆใช้นั้นมีรากฐานทางประวัติศาสตร์ที่ยาวนาน ตัวอย่างเช่นในชุดคำสั่ง x86:

• B หมายถึงไบต์ (8 บิต)
• W หมายถึงคำ (16 บิต)
• D หมายถึง dword "คำสองคำ" (32- บิต)
• Q หมายถึง qword "quad-word" (64-bit)
• DQ หมายถึง dqword "double-quad-word" (128-bit)

การอ้างอิงทางประวัติศาสตร์เหล่านี้ไม่มีความหมายที่ทันสมัย ​​แต่อย่างใด รูปแบบที่สอดคล้องกันมากขึ้นจะทำให้ค่าความกว้างบิต (8, 16, 32, 64, 128) เป็นชื่อ

ตรงกันข้าม LLVM เป็นขั้นตอนที่ถูกต้องในทิศทางของความมั่นคงในคำแนะนำระดับต่ำ: http://llvm.org/docs/LangRef.html#functions

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

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

ในกรณีของ opcodes และ register register ชื่อยาว ๆ จะเป็นอันตรายต่อความสามารถในการอ่าน ช่วยในการจำสั้น ๆ จะดีกว่าสำหรับโปรโตคอลการสื่อสาร (ระหว่างคอมไพเลอร์และส่วนเสริม) และภาษาแอสเซมบลีเป็นโปรโตคอลการสื่อสารเกือบตลอดเวลา คำย่อช่วยจำที่ดีสำหรับโปรแกรมเมอร์เนื่องจากคอมไพเลอร์โค้ดอ่านง่ายกว่า

ส่วนใหญ่มันเป็นสำนวน ตามที่ @ TMN พูดที่อื่นเช่นเดียวกับที่คุณไม่ได้เขียนimport JavaScriptObjectNotationหรือimport HypertextTransferProtocolLibraryใน Python คุณไม่ได้เขียนTimer1LowerHalf = 0xFFFFใน C. มันดูไร้สาระเท่า ๆ กันในบริบท ทุกคนที่ต้องรู้ก็รู้

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

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

volatile char MAGIC_REGISTER @ 0x7FFFABCD;

ตอนนี้ IDE เดียวที่มีอยู่ที่จะแยกวิเคราะห์นี้คือ IDE ของ HiTech ( HiTide ) ของตัวเอง ในเครื่องมือแก้ไขอื่น ๆ คุณจะต้องพิมพ์ด้วยตนเองจากหน่วยความจำทุกครั้ง สิ่งนี้จะเก่าไปอย่างรวดเร็ว

นอกจากนี้ยังมีข้อเท็จจริงที่ว่าเมื่อคุณใช้เครื่องมือพัฒนาเพื่อตรวจสอบการลงทะเบียนคุณมักจะมีตารางแสดงหลายคอลัมน์ (ชื่อลงทะเบียนค่าในฐานสิบหกค่าในฐานสองค่าสุดท้ายในฐานสิบหก ฯลฯ ) ชื่อแบบยาวหมายความว่าคุณต้องขยายคอลัมน์ชื่อเป็น 13 ตัวอักษรเพื่อดูความแตกต่างระหว่างการลงทะเบียนสองครั้งและเล่น "ค้นหาความแตกต่าง" ในคำที่ซ้ำหลาย ๆ บรรทัด

สิ่งเหล่านี้อาจฟังดูแปลก ๆ เล็กน้อย แต่ไม่ใช่แบบแผนการเข้ารหัสทุกรูปแบบที่ออกแบบมาเพื่อลดอาการปวดตาลดการพิมพ์ฟุ่มเฟือยหรือตอบข้อร้องเรียนเล็กน้อยอื่น ๆ อีกล้านข้อ?

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

1. พื้นหลังทางวิทยาศาสตร์ของโปรแกรมเมอร์
2. ทักษะการเขียนโปรแกรมของโปรแกรมเมอร์
3. สภาพแวดล้อมของโปรแกรมเมอร์

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

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

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

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