มีข้อแก้ตัวสำหรับชื่อตัวแปรสั้น ๆ หรือไม่?

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

ตัวอย่างเช่นฉันอ่านโค้ดบางตัวที่อัพเดตนิยามของผิวหน้าออปติคัล ตัวแปรที่ตั้งไว้ที่จุดเริ่มต้นมีดังนี้:

double dR, dCV, dK, dDin, dDout, dRin, dRout
dR = Convert.ToDouble(_tblAsphere.Rows[0].ItemArray.GetValue(1));
dCV = convert.ToDouble(_tblAsphere.Rows[1].ItemArray.GetValue(1));
... and so on

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

dR = radius
dCV = curvature
dK = conic constant
dDin = inner aperture
dDout = outer aperture
dRin = inner radius
dRout = outer radius

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

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

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

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

ตัวแปรที่มีช่วงอายุสั้น ๆ ควรตั้งชื่อในไม่ช้า for(int arrayCounter = 0; arrayCounter < 10; arrayCounter++) { ...ตัวอย่างเช่นคุณไม่ได้เขียน คุณใช้for(int i ...แทน

โดยทั่วไปแล้วกฎของหัวแม่มืออาจกล่าวได้ว่าขอบเขตตัวแปรที่สั้นลงควรมีชื่อที่สั้นกว่า เคาน์เตอร์ห่วงมักจะมีตัวอักษรเดียวเท่านั้นพูดi, และj kตัวแปรท้องถิ่นเป็นสิ่งที่ชอบbaseหรือและfrom ตัวแปรทั่วโลกแล้วค่อนข้างซับซ้อนมากขึ้นเช่นtoEntityTablePointer

บางทีกฎเช่นนี้ไม่ได้ถูกติดตามด้วย codebase ที่คุณทำงานด้วย มันเป็นเหตุผลที่ดีสำหรับการทำ refactoring บ้าง!

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

รหัสจะถือว่าความคุ้นเคยกับโดเมนปัญหา

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

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

สำหรับตัวแปรบางตัวที่เป็นที่รู้จักกันดีในโดเมนปัญหา - เช่นกรณีที่คุณมีที่นี่ - ชื่อตัวแปรตัวย่อนั้นสมเหตุสมผล ถ้าผมทำงานเกี่ยวกับเกมที่ผมต้องการหน่วยงานเกมของฉันจะมีตัวแปรตำแหน่งxและyไม่ได้และhorizontalPosition verticalPositionในทำนองเดียวกันเคาน์เตอร์วงที่ไม่ได้มีความหมายใด ๆ ที่นอกเหนือจากการจัดทำดัชนีผมคาดว่าจะเห็นi, ,jk

อ้างอิงถึง "Clean Code":

ชื่อตัวแปรควร:

• จงแสดงเจตนา
• หลีกเลี่ยงการบิดเบือนข้อมูล
• สร้างความแตกต่างที่มีความหมาย
• ออกเสียงได้
• ค้นหาได้

ข้อยกเว้นเป็นสุภาษิตที่i,j,k,m,nใช้ในการวนรอบ

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

นอกจากนี้เนื่องจากทุกวิธีต้องสั้นโดยใช้ส่วนนำหน้าเพื่อระบุว่าขอบเขตหรือประเภทไม่ได้ใช้งานอีกต่อไป

ชื่อนี้ดีกว่า:

radius
curvature
conicConstant
innerAperture
outerAperture
innerRadius
outerRadius

ผู้วิจารณ์กล่าวว่าสิ่งนี้ซับซ้อนเกินไปกับชื่อตัวแปรแบบยาว:

ชื่อตัวแปรสั้น ๆ ไม่ได้ทำให้ง่ายอย่างใดอย่างหนึ่ง:

fnZR = (r^2/fnR(1+Math.sqrt((1+k) * (r^2/R^2)))) + a[1]*r^2 + a[1]*r^4 + a[1]*r^6 ...;

คำตอบคือชื่อยาวและผลลัพธ์ระดับกลางจนกระทั่งคุณได้คำตอบในตอนท้าย:

thisNiceThing =  ( thisOKThing / thisGreatThing ) + thisAwsomeThing;

มีสองเหตุผลที่ดีที่จะไม่เปลี่ยนชื่อตัวแปรในรหัสดั้งเดิม

(1) ยกเว้นว่าคุณกำลังใช้เครื่องมือการเปลี่ยนโครงสร้างอัตโนมัติความเป็นไปได้ในการแนะนำบั๊กนั้นสูง ดังนั้น "ถ้ามันไม่พังไม่ต้องแก้ไข"

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

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

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

dDin better than dDinnerAperture
dDout better than dDouterAperture

... ถ้าฉันใช้มันในการคำนวณที่ซับซ้อนนาน ๆ การแสดงออกทางคณิตศาสตร์ที่เล็กลงมักจะง่ายกว่าที่จะเห็นทุกสิ่งในครั้งเดียว แม้ว่าจะเป็นอย่างนั้นก็ตามพวกเขาอาจจะดีกว่าในฐานะ dIn และ dOut ดังนั้นจึงไม่มีซ้ำ D ที่อาจนำไปสู่การพิมพ์ผิดที่ง่าย

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

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

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

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

เพื่อสร้างคลาส Sundialนี้ฉันอาจจะอ้างถึงทรัพยากรครึ่งโหล, Astronomy Almanac, และตัวอย่างจากภาษาอื่น ๆ (PHP, Java, C ฯลฯ )

ในเกือบทั้งหมดนี้พวกเขาใช้ตัวย่อเหมือนกันซึ่งบนใบหน้าของมันไม่มีความหมายอะไรเลย

K, T, EPS, deltaPsi, eot, LM,RA

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

julianTime, nutationOfEclipticalLongitudeExpressedInDegrees, equationOfTime, ,longitudeMeanrightAscension

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

มีอย่างแน่นอน; บ่อยครั้งที่ชื่อตัวแปรแบบสั้นเป็นสิ่งที่จำเป็น

ในกรณีของฉันฉันใช้การนำทางจุดอ้างอิงในคลาส Robotics อาวุโสของฉันและเราตั้งโปรแกรมหุ่นยนต์ของเราใน KISS-C เราต้องการตัวแปรสำหรับพิกัดปัจจุบันและปลายทาง (x, y), ระยะทาง (x, y), ส่วนหัวปัจจุบันและปลายทางรวมถึงมุมเลี้ยว

โดยเฉพาะอย่างยิ่งในกรณีของพิกัด x และ y ชื่อตัวแปรแบบยาวนั้นไม่จำเป็นอย่างสมบูรณ์และชื่อเช่น xC (ปัจจุบัน x), yD (ปลายทาง y) และ pD (ปลายทาง phi) พอเพียงและเข้าใจง่ายที่สุด ในกรณีนี้.

คุณอาจยืนยันว่าสิ่งเหล่านี้ไม่ใช่ 'ชื่อตัวแปรอธิบาย' เนื่องจากโปรโตคอลโปรแกรมเมอร์จะเป็นตัวกำหนด แต่เนื่องจากชื่อจะขึ้นอยู่กับรหัสง่าย ๆ (d = ปลายทาง, c = ปัจจุบัน) ความคิดเห็นง่ายๆที่เริ่มแรกคือคำอธิบายทั้งหมด พวกเขาต้องการ

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

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

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

คู่มือการเข้ารหัสปกติทั้งหมดบอกว่าอย่าตั้งชื่อตัวแปรด้วยตัวอักษรตัวแรกที่แทนประเภท (เช่นในกรณีของคุณ) เพราะมันง่ายในการเรียกดูรหัสใน IDE ที่ทันสมัยทั้งหมด

ฉันคิดว่าเหตุผลสำหรับชื่อตัวแปรนั้นสั้นพอสมควร

ชื่อสั้น ๆ ง่ายต่อการอ่านโดยใช้ช่วงเวลาที่สั้นลงทำให้ช่วงความสนใจสั้น

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

เมื่อทำการสแกนผ่านซอร์สโค้ดจำนวนมากสิ่งนี้สามารถให้ประสิทธิภาพที่ดีได้

นอกจากนี้มันยังช่วยโปรแกรมเมอร์ที่ขี้เกียจพิมพ์ชื่อสั้น ๆ เหล่านี้เมื่อเขียนโค้ด

แน่นอน "ชวเลข" เหล่านี้ทั้งหมดคาดว่าจะแสดงอยู่ในตำแหน่งมาตรฐานในซอร์สโค้ด

หากต้องการจัดวางสิ่งที่ @ zxcdw พูดด้วยวิธีที่แตกต่างกันเล็กน้อยและทำอย่างละเอียดในแง่ของวิธีการ:

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

นี่คือรหัสชนิดที่คุณต้องการเขียน: นี่คือรหัสที่มีจำนวน จำกัด และง่ายต่อการย้าย

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

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

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

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

แน่นอนนี่คือสิ่งที่ // ความคิดเห็นมีไว้เพื่ออะไร?

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

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

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

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

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

มีข้อแก้ตัวสำหรับชื่อตัวแปรสั้นเกินไปหรือไม่?

ข้อแรก: การตั้งชื่อตัวแปรสำหรับพลังงาน e ขณะคำนวณสูตรเช่น E = MC2 ไม่ใช่การตั้งชื่อแบบสั้นเกินไป การใช้สัญลักษณ์เป็นอาร์กิวเมนต์สำหรับชื่อย่อไม่ถูกต้อง

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

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

(เพียงเพื่อรักษาตัวอย่าง 'สมจริง' คุณไม่ได้รับอนุญาตให้ใช้เครื่องมือตัวย่อเพราะเหตุใดปัญหาด้านความปลอดภัยไม่อนุญาตให้ใช้เครื่องมือภายนอกเพื่อสัมผัสรหัสฐาน)

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

double dR, dCV, dK, dDin, dDout, dRin, dRout

"d" ที่จุดเริ่มต้นของตัวแปรเหล่านี้มีไว้เพื่อระบุว่าพวกเขาเป็นคู่; แต่ภาษาบังคับใช้สิ่งนี้อยู่ดี แม้ชื่อเหล่านี้จะมีความซ้ำซ้อนแต่ก็มีมากถึง 50% ซ้ำซ้อน !

หากเราจะใช้หลักการตั้งชื่อเพื่อลดข้อผิดพลาดเราจะดีกว่าการเข้ารหัสข้อมูลที่ไม่ได้ตรวจสอบด้วยภาษา ตัวอย่างเช่นไม่มีภาษาใดที่จะบ่นdK + dRในโค้ดด้านบนแม้ว่ามันจะไม่มีความหมายในการเพิ่มหมายเลขไร้มิติให้กับความยาว

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

// Dimensions:
// l  = length
// rl = reciprocal length
double lR, rlCV, K, lDin, lDout, lRin, lRout

ภาษาจะยังช่วยให้เราเขียนK + lRแต่ตอนนี้ชื่อให้คำแนะนำแก่เราว่านี่อาจไม่ถูกต้อง

นี่คือความแตกต่างระหว่างSystems Hungarian (โดยทั่วไปไม่ดี) และApps Hungarian (อาจดี)

http://en.wikipedia.org/wiki/Hungarian_notation

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