การเลือกชื่อ (Choosing Names)
การเลือกชื่อสำหรับตัวแปร เมธอด และเอนทิตีอื่น ๆ เป็นหนึ่งในแง่มุมของการออกแบบซอฟต์แวร์ที่ถูกประเมินค่าต่ำที่สุด ชื่อที่ดีเป็นรูปแบบหนึ่งของเอกสาร: ชื่อเหล่านี้ทำให้โค้ดง่ายต่อการเข้าใจ ชื่อที่ดีลดความต้องการเอกสารอื่น ๆ และทำให้ง่ายต่อการตรวจจับข้อผิดพลาด ในทางตรงกันข้าม การเลือกชื่อที่ไม่ดีจะเพิ่มความซับซ้อนของโค้ดและสร้างความกำกวมและความเข้าใจผิดที่อาจนำไปสู่บัก การเลือกชื่อเป็นตัวอย่างของหลักการที่ว่าความซับซ้อนเพิ่มขึ้นอย่างค่อย ๆ การเลือกชื่อที่มัธยมสำหรับตัวแปรเฉพาะ เมื่อเทียบกับชื่อที่ดีที่สุด อาจไม่มีผลกระทบมากเกี่ยวกับความซับซ้อนโดยรวมของระบบ อย่างไรก็ตาม ระบบซอฟต์แวร์มีตัวแปรหลายพันตัว การเลือกชื่อที่ดีสำหรับทั้งหมดนี้จะมีผลกระทบที่สำคัญต่อความซับซ้อนและความสามารถในการจัดการ
14.1 ตัวอย่าง: ชื่อที่ไม่ดีอาจสาเหตุบัก (Example: bad names cause bugs)
บางครั้งแม้แต่ตัวแปรชื่อไม่ดีตัวเดียวก็อาจมีผลกระทบที่รุนแรง บักที่ยากที่สุดที่ผมเคยแก้ไขเกิดขึ้นเพราะการเลือกชื่อที่ไม่ดี ในช่วงปลายทศวรรษ 1980 และต้นทศวรรษ 1990 นักศึกษาระดับบัณฑิตศึกษาของผมและผมสร้างระบบปฏิบัติการแบบกระจายที่เรียกว่า Sprite ในบางจุด เราสังเกตว่าไฟล์บางครั้งจะสูญเสียข้อมูล: บล็อกข้อมูลหนึ่งบล็อกกลายเป็นศูนย์ทั้งหมด แม้ว่าไฟล์จะไม่ได้ถูกแก้ไขโดยผู้ใช้ปัญหานี้ไม่ได้เกิดขึ้นบ่อยมาก ดังนั้นจึงเป็นการยากที่จะติดตามข้อมูล นักศึกษาระดับบัณฑิตศึกษากลุ่มหนึ่งพยายามค้นหาบัก แต่พวกเขาไม่สามารถก้าวหน้าได้และในที่สุดก็ยอมแพ้ อย่างไรก็ตาม ผมถือว่าบักที่ไม่ได้แก้ไขเป็นการดูถูกส่วนตัวที่ไม่สามารถทนได้ ดังนั้นผมจึงตัดสินใจที่จะติดตามมัน
ใช้เวลาหกเดือน แต่ในที่สุดผมก็พบและแก้ไขบัก ปัญหาจริง ๆ นั้นค่อนข้างง่าย (เช่นเดียวกับบักส่วนใหญ่ เมื่อคุณเข้าใจแล้ว) โค้ดระบบไฟล์ ใช้ชื่อตัวแปร block สำหรับสองจุดประสงค์ที่แตกต่างกัน ในบางสถานการณ์ block หมายถึงหมายเลขบล็อกทางกายภาพบนดิสก์ ในสถานการณ์อื่น ๆ block หมายถึงหมายเลขบล็อกตรรมชาติภายในไฟล์ น่าเสียดายที่ ณ จุดหนึ่งในโค้ด มีตัวแปร block ที่มีหมายเลขบล็อกตรรมชาติ แต่ถูกใช้โดยไม่ได้ตั้งใจในบริบทที่ต้องการหมายเลขบล็อกทางกายภาพ ส่งผลให้บล็อกที่ไม่เกี่ยวข้องบนดิสก์ถูกเขียนทับด้วยศูนย์
ขณะติดตามบัก หลายคน รวมถึงผมเอง ได้อ่านโค้ดที่มีข้อบกพร่อง แต่เราไม่เคยสังเกตเห็นปัญหา เมื่อเราเห็นตัวแปร block ที่ใช้เป็นหมายเลขบล็อกทางกายภาพ เราสะท้อนให้ส่วนแบบว่าจะถือว่ามันเป็นหมายเลขบล็อกทางกายภาพ ใช้เวลานานในกระบวนการดำเนินการวัดสิ่งต่าง ๆ ซึ่งในที่สุดก็แสดงให้เห็นว่าการบิดเบือนจะต้องเกิดขึ้นในคำสั่งเฉพาะ ก่อนที่ผมจะสามารถข้ามผลกระทบทางจิตใจที่สร้างขึ้นจากชื่อและตรวจสอบว่าค่ามาจากที่ไหน หากชื่อตัวแปรที่แตกต่างกันถูกใช้สำหรับบล็อกประเภทต่าง ๆ เช่น fileBlock และ diskBlock ก็ไม่น่าจะเกิดข้อผิดพลาด โปรแกรมเมอร์จะรู้ว่า fileBlock ไม่สามารถใช้ได้ในสถานการณ์นั้น
น่าเสียดายที่นักพัฒนาส่วนใหญ่ไม่ได้ใช้เวลามากในการคิดเกี่ยวกับชื่อ พวกเขามีแนวโน้มที่จะใช้ชื่อแรกที่นึกขึ้นมา ตราบใดที่มันค่อนข้างใกล้เคียงกับสิ่งที่มันตั้งชื่อ ตัวอย่างเช่น block เป็นตัวจับคู่ที่ค่อนข้างใกล้เคียงสำหรับทั้งบล็อกทางกายภาพบนดิสก์และบล็อกตรรมชาติภายในไฟล์ อย่างชัดเจนมันไม่ใช่ชื่อที่แย่มากนัก แม้จะเป็นเช่นนั้น มันก็ส่งผลให้มีค่าใช้จ่ายจำนวนมากในการติดตามบักที่ละเอียด ดังนั้น คุณไม่ควรตัดสินใจยอมรับชื่อที่เพียงแค่ "ค่อนข้างใกล้เคียง" ใช้เวลาเพิ่มเติมเล็กน้อยในการเลือกชื่อที่ยอดเยี่ยม ซึ่งมีความแม่นยำ ไม่ซ้ำซ้อน และเข้าใจได้ง่าย ความสนใจพิเศษจะชำระเงินด้วยตัวเอง และเมื่อเวลาผ่านไป คุณจะได้เรียนรู้ที่จะเลือกชื่อที่ดีอย่างรวดเร็ว
14.2 สร้างภาพ (Create an image)
เมื่อเลือกชื่อ เป้าหมายคือการสร้างภาพในใจของผู้อ่านเกี่ยวกับธรรมชาติของสิ่งที่ตั้งชื่อ ชื่อที่ดีเผยชื่อ (convey) ข้อมูลจำนวนมากเกี่ยวกับว่าเอนทิตีพื้นฐานคืออะไร และสิ่งที่สำคัญเท่าเทียมกัน สิ่งที่มันไม่ใช่ เมื่อพิจารณาชื่อใดชื่อหนึ่ง ให้ถามตัวเองว่า: "ถ้าใครเห็นชื่อนี้โดดเดี่ยว โดยไม่เห็นการประกาศ เอกสาร หรือโค้ดใด ๆ ที่ใช้ชื่อนี้ พวกเขาจะสามารถเดาได้ใกล้ ๆ ว่าชื่อหมายถึงอะไร? มีชื่ออื่นหรือไม่ที่จะวาดภาพที่ชัดเจนยิ่งขึ้น" แน่นอน มีขีดจำกัดว่าคุณสามารถใส่ข้อมูลเท่าใดในชื่อเดียว ชื่อจะกลายเป็นปะปนหาก (unwieldy) ถ้ามันมีคำมากกว่าสอง หรือสามคำ ดังนั้น ความท้าทายคือการหาคำไม่กี่คำที่จะจับภาพด้านที่สำคัญที่สุดของเอนทิตี
ชื่อเป็นรูปแบบหนึ่งของ abstraction: พวกมันให้วิธีที่ง่ายในการคิดเกี่ยวกับเอนทิตีพื้นฐานที่มีความซับซ้อนมากขึ้น เช่นเดียวกับรูปแบบ abstraction อื่น ๆ ชื่อที่ดีที่สุดคือชื่อที่เน้นความสนใจในสิ่งที่สำคัญที่สุดเกี่ยวกับเอนทิตีพื้นฐาน ในขณะเดียวกันก็ละเว้นรายละเอียดที่มีความสำคัญน้อยกว่า
14.3 ชื่อควรแม่นยำ (Names should be precise)
ชื่อที่ดีมีสองคุณสมบัติ: ความแม่นยำและความสอดคล้อง มาเริ่มต้นด้วยความแม่นยำกันเถิด ปัญหาที่พบบ่อยที่สุดเกี่ยวกับชื่อคือว่าพวกเขามีลักษณะทั่วไปเกินไปหรือคลุมเครือ ส่งผลให้ผู้อ่านยากต่อการบอกว่าชื่อหมายถึงอะไร ผู้อ่านอาจสันนิษฐานว่าชื่อหมายถึงสิ่งที่แตกต่างจากความเป็นจริง เช่นเดียวกับบัก block ข้างต้น พิจารณาการประกาศ Method ต่อไปนี้:
/**
* Returns the total number of indexlets this object is managing.
*/
int IndexletManager::getCount() {...}คำว่า "count" มีลักษณะทั่วไปเกินไป: count ของอะไร? ถ้าใครเห็นการเรียก Method นี้ พวกเขาไม่น่าจะรู้ว่ามันทำอะไร เว้นแต่ว่าพวกเขาจะอ่านเอกสารของมัน ชื่อที่มีความแม่นยำมากขึ้นเช่น getActiveIndexlets หรือ numIndexlets จะดีกว่า: ด้วยชื่อใดชื่อหนึ่งเหล่านี้ ผู้อ่านคงจะสามารถเดาได้ว่า Method ส่งคืนค่าอะไรโดยไม่ต้องดูเอกสาร
นี่คือตัวอย่างอื่น ๆ ของชื่อที่ไม่มีความแม่นยำเพียงพอ มาจากโครงการนักเรียนต่าง ๆ:
-
โครงการสร้าง GUI text editor ใช้ชื่อ x และ y เพื่ออ้างถึงตำแหน่งของอักษรในไฟล์ ชื่อเหล่านี้มีลักษณะทั่วไปเกินไป พวกเขาอาจหมายถึงหลายสิ่ง; ตัวอย่างเช่น พวกเขาอาจแทนพิกัด (เป็นพิกเซล) ของอักษรบนหน้าจอ ใครสักคนเห็นชื่อ x โดดเดี่ยว ไม่น่าจะคิดว่ามันหมายถึงตำแหน่งของอักษรภายในบรรทัดของข้อความ โค้ดจะชัดเจนกว่าหากใช้ชื่อเช่น charIndex และ lineIndex ซึ่งสะท้อนให้เห็น abstraction เฉพาะที่โค้ดนำไปใช้
-
โครงการแก้ไขอื่นมีโค้ดดังต่อไปนี้:
// Blink state: true when cursor visible. private boolean blinkStatus = true;ชื่อ blinkStatus ไม่สื่อสารข้อมูลเพียงพอ คำว่า "status" มีความคลุมเครือเกินไปสำหรับค่า boolean: มันไม่ให้คำใบ้เลยว่าค่า true หรือ false หมายถึงอะไร คำว่า "blink" ก็คลุมเครือเช่นกัน เพราะมันไม่ได้ระบุว่าสิ่งใดกำลังกระพริบ ทางเลือกต่อไปนี้จะดีกว่า:
// Controls cursor blinking: true means the cursor is visible, // false means the cursor is not displayed. private boolean cursorVisible = true;ชื่อ cursorVisible สื่อสารข้อมูลมากขึ้น; ตัวอย่างเช่น มันช่วยให้ผู้อ่านสามารถเดาได้ว่าค่า true หมายถึงอะไร (ตามกฎทั่วไป ชื่อของตัวแปร boolean ควรเป็นกริยาวิเศษษณ์เสมอ) คำว่า "blink" ไม่อยู่ในชื่อแล้ว ดังนั้นผู้อ่านจะต้องปรึกษาเอกสารหากต้องการทราบว่าเหตุใดเคอร์เซอร์จึงไม่มองเห็นได้ตลอดเวลา ข้อมูลนี้มีความสำคัญน้อยกว่า
-
โครงการที่นำไปใช้โปรโตคอลฉันทามติมีโค้ดดังต่อไปนี้:
// Value representing that the server has not voted (yet) for // anyone for the current election term. private static final String VOTED_FOR_SENTINEL_VALUE = "null";ชื่อสำหรับค่านี้ระบุว่ามันพิเศษ แต่มันไม่ได้บอกว่าความหมายพิเศษคืออะไร ชื่อเฉพาะมากขึ้นเช่น NOT_YET_VOTED จะดีกว่า
-
ตัวแปรชื่อ result ถูกใช้ในเมธอดที่ไม่มีค่าส่งคืน ชื่อนี้มีปัญหาหลายประการ ประการแรก มันสร้างความประทับใจที่ทำให้เข้าใจผิดว่ามันจะเป็นค่าส่งคืนของเมธอด ประการที่สอง มันให้ข้อมูลเกือบจะไม่มีเลย ยกเว้นว่ามันเป็นค่าที่คำนวณบางอย่าง ชื่อควรให้ข้อมูลเกี่ยวกับว่า result จริง ๆ คืออะไร เช่น mergedLine หรือ totalChars ในเมธอดที่มีค่าส่งคืนจริง ๆ แล้ว การใช้ชื่อ result ก็สมควร ชื่อนี้ยังคงมีลักษณะทั่วไปไปบ้าง แต่ผู้อ่านสามารถดูเอกสาร Method เพื่อดูความหมาย และมันช่วยให้ทราบว่าค่านี้จะเป็นค่าส่งคืนในที่สุด
สัญญาณแดง: ชื่อคลุมเครือ (Red Flag: Vague Name)
ถ้าชื่อตัวแปรหรือเมธอดกว้างพอที่จะอ้างถึงหลายสิ่ง ก็ไม่สื่อสารข้อมูลมากนักให้กับนักพัฒนา และเอนทิตีพื้นฐานจึงมีแนวโน้มที่จะถูกใช้งานผิด
เช่นเดียวกับกฎทั้งหมด กฎเกี่ยวกับการเลือกชื่อที่มีความแม่นยำมีข้อยกเว้นบางประการ ตัวอย่างเช่น เป็นเรื่องปกติที่จะใช้ชื่อทั่วไปเช่น i และ j เป็นตัวแปรการทำซ้ำลูป ตราบใดที่ลูปมีเพียงไม่กี่บรรทัดของโค้ด หากคุณเห็นความขลัง (range) ทั้งหมดของการใช้งานตัวแปร ความหมายของตัวแปรอาจจะชัดเจนจากโค้ดดังนั้นคุณไม่จำเป็นต้องมีชื่อยาว ตัวอย่างเช่น พิจารณาโค้ดต่อไปนี้:
for (i = 0; i < numLines; i++) {
...
}เห็นได้ชัดจากโค้ดนี้ว่า i ถูกใช้เพื่อทำซ้ำแต่ละบรรทัดในเอนทิตีบางอย่าง หากลูปยาวขึ้นจนถึงจุดที่คุณไม่สามารถเห็นได้หมด หรือหากความหมายของตัวแปรการทำซ้ำนั้นยากต่อการหาจากโค้ด ชื่อที่อธิบายลักษณะเพิ่มเติมก็จำเป็น
นอกจากนี้ยังเป็นไปได้ที่ชื่อจะเฉพาะเกินไป เช่นในการประกาศสำหรับเมธอดที่ลบช่วงของข้อความ:
void delete(Range selection) {...}ชื่อพารามิเตอร์ selection เฉพาะเกินไป เพราะมันแนะนำว่าข้อความที่ถูกลบจะถูกเลือกเสมอในอินเทอร์เฟซผู้ใช้ อย่างไรก็ตาม เมธอดนี้สามารถเรียกใช้ได้บนช่วงข้อความใด ๆ ที่เลือก หรือไม่เลือก ดังนั้นชื่อพารามิเตอร์ควรเป็นลักษณะทั่วไปมากขึ้น เช่น range
หากคุณพบว่ายากต่อการหาชื่อตัวแปรเฉพาะที่มีความแม่นยำ เข้าใจได้ง่าย และไม่ยาวเกินไป นี่เป็นสัญญาณแดง มันแสดงให้เห็นว่าตัวแปรอาจไม่มีคำจำกัดความหรือวัตถุประสงค์ที่ชัดเจน เมื่อเรื่องนี้เกิดขึ้น ให้พิจารณา alternative factorings ตัวอย่างเช่น บางที คุณอาจพยายามใช้ตัวแปรตัวเดียวเพื่อแสดงหลายสิ่ง ถ้าเป็นเช่นนั้น การแยกการแสดงเป็นตัวแปรหลายตัวอาจส่งผลให้คำจำกัดความที่ง่ายกว่าสำหรับตัวแปรแต่ละตัว กระบวนการเลือกชื่อที่ดีสามารถปรับปรุงการออกแบบของคุณโดยการระบุจุดอ่อน
สัญญาณแดง: ยากต่อการเลือกชื่อ (Red Flag: Hard to Pick Name)
หากยากต่อการค้นหาชื่อง่าย ๆ สำหรับตัวแปรหรือเมธอดที่สร้างภาพที่ชัดเจนของออบเจกต์พื้นฐาน นั่นเป็นคำใบ้ว่าออบเจกต์พื้นฐานอาจไม่มีการออกแบบที่สะอาด
14.4 ใช้ชื่ออย่างสอดคล้อง (Use names consistently)
คุณสมบัติที่สำคัญที่สองของชื่อที่ดีคือความสอดคล้อง ในโปรแกรมใด ๆ มีตัวแปรบางตัวที่ใช้ซ้ำแล้วซ้ำอีก ตัวอย่างเช่น ระบบไฟล์จัดการหมายเลขบล็อกซ้ำแล้วซ้ำอีก สำหรับการใช้งานทั่วไปแต่ละครั้ง ให้เลือกชื่อเพื่อใช้สำหรับวัตถุประสงค์นั้น และใช้ชื่อเดียวกันทุกที่ ตัวอย่างเช่น ระบบไฟล์อาจใช้ fileBlock เสมอเพื่อเก็บดัชนีของบล็อกภายในไฟล์ ชื่อที่สอดคล้องลดภาระงานอ่านในลักษณะเดียวกับการนำเอา class ทั่วไปกลับมาใช้ใหม่: เมื่อผู้อ่านเห็นชื่อในบริบทหนึ่ง พวกเขาสามารถนำความรู้ของตนกลับมาใช้ใหม่และสร้างสมมติฐานทันทีเมื่อพวกเขาเห็นชื่อในบริบทอื่น
ความสอดคล้องมีสามข้อกำหนด: ประการแรก ใช้ชื่อทั่วไปเสมอสำหรับวัตถุประสงค์ที่กำหนด ประการที่สอง ไม่ใช้ชื่อทั่วไปเลยสำหรับสิ่งใดนอกเหนือจากวัตถุประสงค์ที่กำหนด ประการที่สาม ตรวจสอบให้แน่ใจว่าวัตถุประสงค์นั้นแคบพอที่ว่าตัวแปรทั้งหมดที่มีชื่อจะมีลักษณะการทำงานเหมือนกัน ข้อกำหนดที่สามนี้ถูกละเมิดในบัก ระบบไฟล์ตอนต้นบท ระบบไฟล์ใช้ block สำหรับตัวแปรที่มีลักษณะการทำงานสองแบบที่แตกต่างกัน (ไฟล์บล็อกและบล็อกดิสก์); สิ่งนี้นำไปสู่สมมติฐานเท็จเกี่ยวกับความหมายของตัวแปร ซึ่งในทางกลับกันก็ส่งผลให้เกิดบัก
บางครั้งคุณจะต้องมีตัวแปรหลายตัวที่อ้างถึงสิ่งที่อาจจะเหมือนกันโดยทั่วไป ตัวอย่างเช่น เมธอดที่คัดลอกข้อมูลไฟล์จะต้องการหมายเลขบล็อกสองตัว หนึ่งสำหรับแหล่งที่มาและอีกตัวหนึ่งสำหรับปลายทาง เมื่อเรื่องนี้เกิดขึ้น ให้ใช้ชื่อทั่วไปสำหรับตัวแปรแต่ละตัว แต่เพิ่มคำนำหน้าที่แยกแยะ เช่น srcFileBlock และ dstFileBlock
ลูปเป็นพื้นที่อื่นที่การตั้งชื่ออย่างสอดคล้องสามารถช่วยได้ ถ้าคุณใช้ชื่อเช่น i และ j สำหรับตัวแปรลูป ใช้ i ในลูปชั้นนอกสุดเสมอและ j สำหรับลูปแบบซ้อน สิ่งนี้ช่วยให้ผู้อ่านสามารถสร้างสมมติฐานทันทีที่ปลอดภัยเกี่ยวกับสิ่งที่เกิดขึ้นในโค้ดเมื่อพวกเขาเห็นชื่อที่กำหนด
14.5 ความคิดเห็นที่ต่างออกไป: คำแนะนำสไตล์ Go (A different opinion: Go style guide)
ไม่ใช่ทุกคนที่มีมุมมองตรงกับความเห็นของผม เกี่ยวกับชื่อ นักพัฒนาบางคนของภาษา Go แย้งว่าชื่อควรสั้นมาก บ่อยครั้งเพียงแค่อักษรเดียว ในการนำเสนอเกี่ยวกับการเลือกชื่อสำหรับ Go Andrew Gerrand ระบุว่า "ชื่อยาวจะบดบังสิ่งที่โค้ดทำ"1 เขานำเสนอตัวอย่างโค้ดนี้ ซึ่งใช้ชื่อตัวแปรตัวอักษรเดียว:
func RuneCount(b []byte) int {
i, n := 0, 0
for i < len(b) {
if b[i] < RuneSelf {
i++
} else {
_, size := DecodeRune(b[i:])
i += size
}
n++
}
return n
}และเขายืนยันว่ามันสามารถอ่านได้มากกว่าเวอร์ชันต่อไปนี้ ซึ่งใช้ชื่อที่ยาวขึ้น:
func RuneCount(buffer []byte) int {
index, count := 0, 0
for index < len(buffer) {
if buffer[index] < RuneSelf {
index++
} else {
_, size := DecodeRune(buffer[index:])
index += size
}
count++
}
return count
}โดยส่วนตัว ผมไม่พบว่าเวอร์ชันที่สองนั้นยากต่อการอ่านมากกว่าเวอร์ชันแรก ถ้าสิ่งใด ชื่อ count ให้คำใบ้ที่ดีกว่าเล็กน้อยเกี่ยวกับลักษณะการทำงานของตัวแปรมากกว่า n ด้วยเวอร์ชันแรก ผมจึงได้อ่านโค้ดดังนั้นฉันจึงต้องคิดว่า n หมายถึง ขณะที่ผมไม่รู้สึกว่าต้องการมากกับเวอร์ชันที่สอง อย่างไรก็ตาม หาก n ถูกใช้อย่างสอดคล้องทั่วทั้งระบบเพื่ออ้างถึงการนับ (และไม่อื่น) ชื่อสั้นนั้นก็น่าจะชัดเจนสำหรับนักพัฒนาอื่น ๆ
วัฒนาการ Go ส่งเสริมการใช้ชื่อสั้นเดียวกันสำหรับหลายสิ่ง: ch สำหรับอักษรหรือช่อง d สำหรับข้อมูล ความแตกต่าง หรือระยะ และอื่น ๆ สำหรับผม ชื่อคลุมเครือเช่นเหล่านี้มีแนวโน้มที่จะส่งผลให้เกิดความสับสนและข้อผิดพลาด เช่นเดียวกับตัวอย่าง block
โดยรวม ผมจะยืนยันว่าความสามารถในการอ่านจะต้องถูกกำหนดโดยผู้อ่าน ไม่ใช่ผู้เขียน หากคุณเขียนโค้ดด้วยชื่อตัวแปรสั้นและคนที่อ่านมันพบว่ามันง่ายต่อการเข้าใจ นั่นก็โอเค หากคุณเริ่มได้รับการจ่ายเงินที่โค้ดของคุณเป็นการเข้ารหัส คุณควรพิจารณาใช้ชื่อที่ยาวขึ้น (การค้นหาเว็บสำหรับ "go language short names" จะระบุข้อร้องเรียนดังกล่าวหลายประการ) ในทำนองเดียวกัน หากผมเริ่มได้รับการจ่ายเงินที่ชื่อตัวแปรยาวทำให้โค้ดของผมยากต่อการอ่าน ผมจะพิจารณาใช้ชื่อที่สั้นขึ้น
Gerrand ให้ความเห็นหนึ่งที่ผมเห็นด้วย: "ยิ่งมีระยะห่างมากขึ้นระหว่างการประกาศชื่อและการใช้งาน ชื่อก็ควรยาวขึ้น" การอภิปรายก่อนหน้านี้เกี่ยวกับการใช้ตัวแปรลูปชื่อ i และ j เป็นตัวอย่างของกฎนี้
14.6 บทสรุป (Conclusion)
ชื่อที่เลือกมาอย่างดีช่วยให้โค้ดโปร่งใสขึ้น เมื่อใครสักคนเผชิญหน้ากับตัวแปรเป็นครั้งแรก การเดาครั้งแรกของพวกเขาเกี่ยวกับลักษณะการทำงาน โดยไม่ต้องคิดมากนัก จะถูกต้อง การเลือกชื่อที่ดีเป็นตัวอย่างของ mindset ลงทุนที่กล่าวถึงใน บท 3: หากคุณใช้เวลาเพิ่มเติมเล็กน้อยตั้งแต่ต้นในการเลือกชื่อที่ดี มันจะง่ายขึ้นสำหรับคุณในการทำงานกับโค้ดในอนาคต นอกจากนี้ คุณจะมีแนวโน้มที่ต่ำกว่าในการแนะนำบัก การพัฒนาทักษะในการตั้งชื่อก็เป็นการลงทุนด้วย เมื่อคุณตัดสินใจอันดับแรกว่าจะหยุดการยอมรับชื่อที่มัธยม คุณอาจพบว่ามันน่ารำคาญและใช้เวลานานในการหาชื่อที่ดี อย่างไรก็ตาม เมื่อคุณได้รับประสบการณ์เพิ่มเติม คุณจะพบว่ามันกลายเป็นเรื่องง่าย ในที่สุด คุณจะได้ไปถึงจุดที่ใช้เวลาเกือบจะไม่มีเพิ่มเติมในการเลือกชื่อที่ดี ดังนั้นคุณจะได้รับประโยชน์เกือบฟรี