การเลือกชื่อให้กับตัวแปร เมธอด และเอนทิตีอื่น ๆ ถือเป็นหนึ่งในแง่มุมที่ถูกมองข้ามมากที่สุดของการออกแบบซอฟต์แวร์ ชื่อที่ดีคือรูปแบบหนึ่งของ documentation: มันทำให้โค้ดเข้าใจง่ายขึ้น ลดความต้องการ documentation อื่น ๆ และช่วยให้ตรวจจับข้อผิดพลาดได้ง่ายขึ้น ในทางกลับกัน การเลือกชื่อที่ไม่ดีจะเพิ่มความซับซ้อนของโค้ด และสร้างความกำกวมและความเข้าใจผิดที่อาจนำไปสู่บั๊กได้ การเลือกชื่อเป็นตัวอย่างของหลักการที่ว่าความซับซ้อนนั้นเพิ่มขึ้นทีละน้อย การเลือกชื่อที่พอใช้ได้สำหรับตัวแปรตัวหนึ่ง แทนที่จะเลือกชื่อที่ดีที่สุดเท่าที่เป็นไปได้ อาจจะไม่ส่งผลกระทบมากนักต่อความซับซ้อนโดยรวมของระบบ แต่ระบบซอฟต์แวร์มีตัวแปรหลายพันตัว การเลือกชื่อที่ดีให้กับตัวแปรทั้งหมดนี้จะส่งผลกระทบอย่างมีนัยสำคัญต่อความซับซ้อนและความสามารถในการจัดการ
14.1 Example: bad names cause bugs (ตัวอย่าง: ชื่อที่ไม่ดีทำให้เกิดบั๊ก)
บางครั้งแม้แต่ตัวแปรตัวเดียวที่ตั้งชื่อไม่ดีก็สามารถส่งผลกระทบร้ายแรงได้ บั๊กที่ท้าทายที่สุดที่ฉันเคยแก้ เกิดขึ้นเพราะการเลือกชื่อที่ไม่ดี ในช่วงปลายทศวรรษ 1980 และต้นทศวรรษ 1990 นักเรียนปริญญาโทของฉันและฉันได้สร้าง ระบบปฏิบัติการแบบกระจายที่ชื่อว่า Sprite อยู่มาวันหนึ่งเราสังเกตเห็นว่าไฟล์บางครั้งสูญเสียข้อมูล: หนึ่งในบล็อกข้อมูลกลายเป็นศูนย์ทั้งหมด ทั้งที่ไฟล์นั้นไม่ได้ถูกแก้ไขโดยผู้ใช้ ปัญหานี้ ไม่ได้เกิดขึ้นบ่อยนัก จึงยากมากที่จะตามหาสาเหตุ นักเรียนปริญญาโทสองสามคนพยายาม หาบั๊ก แต่ก็ไม่คืบหน้าและสุดท้ายก็ยอมแพ้ อย่างไรก็ตาม ฉันถือว่าบั๊กที่ยังแก้ไม่ได้ ทุกตัวเป็นการดูถูกส่วนตัวที่ทนไม่ได้ ดังนั้นฉันจึงตัดสินใจตามหามันให้เจอ
ใช้เวลาหกเดือน แต่ในที่สุดฉันก็เจอและแก้บั๊กได้ ปัญหาจริง ๆ แล้วค่อนข้างง่าย (อย่างที่บั๊กส่วนใหญ่เป็น เมื่อคุณเข้าใจมันแล้ว) โค้ดของระบบไฟล์ ใช้ชื่อตัวแปร block สำหรับวัตถุประสงค์ที่แตกต่างกันสองอย่าง ในบางสถานการณ์ block หมายถึงหมายเลขบล็อกทางกายภาพบนดิสก์ ในขณะที่อีกสถานการณ์หนึ่ง block หมายถึงหมายเลขบล็อกเชิงตรรกะภายในไฟล์ โชคร้ายที่จุดหนึ่งในโค้ด มีตัวแปร block ที่เก็บหมายเลขบล็อกเชิงตรรกะ แต่ถูกใช้โดยไม่ได้ตั้งใจในบริบทที่ต้องใช้หมายเลขบล็อกทางกายภาพ ส่งผลให้บล็อกที่ไม่เกี่ยวข้องบนดิสก์ถูกเขียนทับด้วยศูนย์
ระหว่างที่ตามหาบั๊ก หลายคนรวมถึงตัวฉันเอง ได้อ่านโค้ดที่มีข้อผิดพลาดนั้น แต่เราไม่เคยสังเกตเห็นปัญหา เมื่อเราเห็นตัวแปร block ถูกใช้เป็นหมายเลขบล็อกทางกายภาพ เราก็สันนิษฐานโดยอัตโนมัติว่ามันเก็บหมายเลขบล็อกทางกายภาพจริง ๆ ต้องใช้กระบวนการวิเคราะห์ที่ยาวนาน ซึ่งในที่สุดแสดงให้เห็นว่าการเสียหาย ต้อง เกิดขึ้นในคำสั่งใดคำสั่งหนึ่ง ก่อนที่ฉันจะสามารถก้าวข้ามอุปสรรคทางความคิดที่เกิดจากชื่อนั้น และตรวจสอบให้แน่ชัดว่าค่าของมันมาจากไหน ถ้าใช้ชื่อตัวแปรที่แตกต่างกันสำหรับบล็อกประเภทต่าง ๆ เช่น fileBlock และ diskBlock ก็ไม่น่าเป็นไปได้ที่ข้อผิดพลาดจะเกิดขึ้น โปรแกรมเมอร์จะรู้ว่า fileBlock ไม่สามารถใช้ในสถานการณ์นั้นได้
โชคร้ายที่นักพัฒนาส่วนใหญ่ไม่ค่อยใช้เวลาคิดเกี่ยวกับชื่อ พวกเขามักจะใช้ชื่อแรก ที่นึกขึ้นได้ ตราบใดที่มันใกล้เคียงกับสิ่งที่มันใช้เรียก ตัวอย่างเช่น block ก็ใกล้เคียงพอสำหรับทั้งบล็อกทางกายภาพบนดิสก์และบล็อกเชิงตรรกะภายในไฟล์ มันไม่ใช่ชื่อที่แย่เลยด้วยซ้ำ ถึงอย่างนั้น มันก็ทำให้เสียเวลาอย่างมหาศาล ในการตามหาบั๊กที่ซ่อนเร้น ดังนั้น คุณไม่ควรพอใจกับชื่อที่ "ใกล้เคียงพอ" ใช้เวลาเพิ่มอีกเล็กน้อยเพื่อเลือกชื่อที่ยอดเยี่ยม ซึ่งแม่นยำ ไม่กำกวม และเข้าใจง่าย ความใส่ใจที่เพิ่มขึ้นนี้จะคุ้มค่าเองอย่างรวดเร็ว และเมื่อเวลาผ่านไปคุณจะเรียนรู้ ที่จะเลือกชื่อที่ดีได้อย่างรวดเร็ว
14.2 Create an image (สร้างภาพในใจ)
เมื่อเลือกชื่อ เป้าหมายคือการสร้างภาพในใจของผู้อ่านเกี่ยวกับธรรมชาติของสิ่งที่กำลังถูกตั้งชื่อ ชื่อที่ดีสื่อถึงข้อมูลมากมายเกี่ยวกับสิ่งที่เอนทิตี้นั้นเป็น และที่สำคัญไม่แพ้กันคือ สื่อถึงสิ่งที่ไม่ใช่ เมื่อกำลังพิจารณาชื่อใดชื่อหนึ่ง ให้ถามตัวเองว่า: "ถ้ามีคนเห็นชื่อนี้โดยลำพัง โดยไม่เห็นการประกาศตัวแปร documentation หรือโค้ดใด ๆ ที่ใช้ชื่อนี้ พวกเขาจะเดาได้ใกล้เคียงแค่ไหนว่าชื่อนี้หมายถึงอะไร? มีชื่ออื่นที่จะวาดภาพ ให้ชัดเจนกว่านี้ไหม?" แน่นอนว่ามีขีดจำกัดว่าคุณสามารถใส่ข้อมูลในชื่อเดียวได้มากแค่ไหน ชื่อจะเทอะทะถ้ามันมีมากกว่าสองหรือสามคำ ดังนั้นความท้าทายคือการหาคำเพียงไม่กี่คำ ที่สามารถจับประเด็นที่สำคัญที่สุดของเอนทิตีนั้นได้
ชื่อคือรูปแบบหนึ่งของ abstraction: มันเป็นวิธีที่เรียบง่ายในการคิดถึงเอนทิตีที่ซับซ้อนกว่าเบื้องหลัง เช่นเดียวกับ abstraction รูปแบบอื่น ๆ ชื่อที่ดีที่สุดคือชื่อที่เน้นความสนใจไปที่สิ่งที่สำคัญที่สุด เกี่ยวกับเอนทิตีนั้น ๆ โดยละทิ้งรายละเอียดที่ไม่สำคัญ
14.3 Names should be precise (ชื่อควรมีความแม่นยำ)
ชื่อที่ดีมีคุณสมบัติสองประการ: ความแม่นยำและความสม่ำเสมอ เริ่มต้นด้วยความแม่นยำ ปัญหาที่พบบ่อยที่สุดของชื่อคือมันกว้างหรือคลุมเครือเกินไป ส่งผลให้ผู้อ่าน บอกได้ยากว่าชื่อนั้นหมายถึงอะไร ผู้อ่านอาจเข้าใจว่าชื่อหมายถึงสิ่งที่แตกต่างจากความเป็นจริง ดังเช่นในบั๊กของ block ข้างต้น ลองพิจารณาการประกาศเมธอดต่อไปนี้:
/**
* Returns the total number of indexlets this object is managing.
*/
int IndexletManager::getCount() {...}
คำว่า "count" นั้นกว้างเกินไป: นับจำนวนอะไร? ถ้ามีคนเห็นการเรียกใช้เมธอดนี้ พวกเขาไม่น่าจะรู้ว่ามันทำอะไรถ้าไม่ได้อ่าน documentation ชื่อที่แม่นยำกว่าเช่น getActiveIndexlets หรือ numIndexlets จะดีกว่า: ด้วยชื่อเหล่านี้ ผู้อ่านอาจเดาได้ว่าเมธอดส่งค่าอะไรกลับมา โดยไม่ต้องดู documentation
ต่อไปนี้คือตัวอย่างชื่อที่ไม่แม่นยำพอ ซึ่งนำมาจากโปรเจกต์ของนักเรียนหลายโปรเจกต์:
-
โปรเจกต์ที่สร้าง GUI text editor ใช้ชื่อ x และ y เพื่ออ้างถึงตำแหน่งของตัวอักษรในไฟล์ ชื่อเหล่านี้กว้างเกินไป มันสามารถหมายถึงหลายสิ่ง ตัวอย่างเช่น มันอาจแทนพิกัด (เป็นพิกเซล) ของตัวอักษรบนหน้าจอ คนที่เห็นชื่อ x โดยลำพัง ไม่น่าจะคิดว่ามันหมายถึงตำแหน่งของตัวอักษรในบรรทัดของข้อความ โค้ดจะชัดเจนขึ้น ถ้าใช้ชื่อเช่น charIndex และ lineIndex ซึ่งสะท้อนถึง abstraction เฉพาะที่โค้ดนั้น implement
-
อีกโปรเจกต์หนึ่งมีโค้ดดังนี้:
// 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 ควรเป็น predicate เสมอ) คำว่า "blink" ไม่ได้อยู่ในชื่ออีกต่อไป ดังนั้นผู้อ่านจะต้องดู documentation ถ้าต้องการรู้ว่าเหตุใด cursor จึงไม่แสดงตลอดเวลา ข้อมูลนี้มีความสำคัญน้อยกว่า
-
โปรเจกต์ที่ implement consensus protocol มีโค้ดดังนี้:
// 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 ก็ถือว่าใช้ได้ ชื่อนี้ยังค่อนข้างกว้างอยู่ แต่ผู้อ่านสามารถดู documentation ของเมธอด เพื่อดูความหมายของมันได้ และมันก็มีประโยชน์ที่จะรู้ว่าค่านี้จะกลายเป็นค่าส่งกลับในที่สุด
Red Flag: Vague Name (ธงแดง: ชื่อที่คลุมเครือ)
ถ้าชื่อตัวแปรหรือเมธอดกว้างพอที่จะอ้างถึงสิ่งต่าง ๆ มากมาย มันก็ไม่ได้สื่อข้อมูลมากนักให้กับนักพัฒนา และเอนทิตี้นั้นก็มีแนวโน้มที่จะถูกใช้ผิดวัตถุประสงค์มากขึ้น
เช่นเดียวกับกฎทุกข้อ กฎเกี่ยวกับการเลือกชื่อที่แม่นยำก็มีข้อยกเว้นอยู่บ้าง ตัวอย่างเช่น การใช้ชื่อทั่วไปอย่าง i และ j เป็นตัวแปรในลูปก็ถือว่าใช้ได้ ตราบใด ที่ลูปนั้นมีโค้ดไม่กี่บรรทัด ถ้าคุณสามารถมองเห็นขอบเขตการใช้งานทั้งหมดของตัวแปร ความหมายของตัวแปรก็น่าจะชัดเจนจากโค้ด ดังนั้นคุณจึงไม่จำเป็นต้องใช้ชื่อยาว ตัวอย่างเช่น ลองพิจารณาโค้ดต่อไปนี้:
for (i = 0; i < numLines; i++) {
...
}
จากโค้ดนี้เห็นได้ชัดว่า i ถูกใช้เพื่อวนซ้ำทีละบรรทัดในเอนทิตีบางอย่าง ถ้าลูปยาวจนคุณมองไม่เห็นทั้งหมดในคราวเดียว หรือถ้าความหมายของตัวแปรวนซ้ำเดาได้ยากขึ้นจากโค้ด ก็ควรใช้ชื่อที่สื่อความหมายมากขึ้น
บางครั้งชื่อก็อาจเจาะจงเกินไป เช่นในการประกาศเมธอดที่ลบช่วงข้อความนี้:
void delete(Range selection) {...}
ชื่ออาร์กิวเมนต์ selection เจาะจงเกินไป เพราะมันสื่อว่าข้อความที่ถูกลบนั้นต้องถูกเลือกใน user interface เสมอ แต่เมธอดนี้สามารถถูกเรียกบนช่วงข้อความใด ๆ ก็ได้ ไม่ว่าจะถูกเลือกหรือไม่ ดังนั้นชื่ออาร์กิวเมนต์ควรกว้างกว่านี้ เช่น range
ถ้าคุณพบว่ามันยากที่จะตั้งชื่อที่แม่นยำ เข้าใจง่าย และไม่ยาวเกินไปสำหรับตัวแปรตัวใดตัวหนึ่ง นี่คือ red flag มันบ่งบอกว่าตัวแปรนั้นอาจไม่มีนิยามหรือวัตถุประสงค์ที่ชัดเจน เมื่อเกิดเหตุการณ์นี้ ให้ลองพิจารณาการจัดโครงสร้างใหม่ ตัวอย่างเช่น คุณอาจกำลังพยายามใช้ตัวแปรเดียวแทนหลายสิ่ง ถ้าเป็นเช่นนั้น การแยกการแทนค่าออกเป็นหลายตัวแปรอาจทำให้นิยามของแต่ละตัวแปรง่ายขึ้น กระบวนการเลือกชื่อที่ดีสามารถปรับปรุงการออกแบบของคุณได้โดยการชี้ให้เห็นจุดอ่อน
Red Flag: Hard to Pick Name (ธงแดง: เลือกชื่อได้ยาก)
ถ้ามันยากที่จะหาชื่อที่เรียบง่ายสำหรับตัวแปรหรือเมธอดที่สร้างภาพที่ชัดเจนของออบเจกต์นั้น นั่นเป็นสัญญาณว่าออบเจกต์นั้นอาจไม่ได้ออกแบบมาอย่าง clean
14.4 Use names consistently (ใช้ชื่ออย่างสม่ำเสมอ)
คุณสมบัติที่สำคัญประการที่สองของชื่อที่ดีคือความสม่ำเสมอ ในโปรแกรมใด ๆ ก็ตาม จะมีตัวแปรบางตัวที่ถูกใช้ซ้ำแล้วซ้ำเล่า ตัวอย่างเช่น ระบบไฟล์จะจัดการกับหมายเลขบล็อกซ้ำ ๆ สำหรับการใช้งานทั่วไปแต่ละอย่าง ให้เลือกชื่อสำหรับวัตถุประสงค์นั้น และใช้ชื่อเดียวกันทุกที่ ตัวอย่างเช่น ระบบไฟล์อาจใช้ fileBlock ตลอดเวลาเพื่อเก็บ index ของบล็อกภายในไฟล์ การตั้งชื่อที่สอดคล้องกันช่วยลดภาระทางความคิด ในลักษณะเดียวกับการใช้คลาสซ้ำ ๆ: เมื่อผู้อ่านเห็นชื่อในบริบทหนึ่งแล้ว พวกเขาสามารถนำความรู้ไปใช้และสันนิษฐานได้ทันทีเมื่อเห็นชื่อนั้นในบริบทที่แตกต่างกัน
ความสอดคล้องมีข้อกำหนดสามประการ: ประการแรก ใช้ชื่อทั่วไปตามวัตถุประสงค์ที่กำหนดเสมอ ประการที่สอง อย่าใช้ชื่อทั่วไปสำหรับสิ่งอื่นนอกเหนือจากวัตถุประสงค์ที่กำหนด และประการที่สาม ตรวจสอบให้แน่ใจว่าวัตถุประสงค์นั้นแคบพอที่ตัวแปรทั้งหมดที่มีชื่อนั้นจะมีพฤติกรรมเดียวกัน ข้อกำหนดประการที่สามถูกละเมิดในตัวอย่างระบบไฟล์ที่ตอนต้นของบท ระบบไฟล์ใช้ block สำหรับตัวแปรที่มีพฤติกรรมแตกต่างกันสองแบบ (บล็อกไฟล์และบล็อกดิสก์); สิ่งนี้นำไปสู่ความเข้าใจผิดเกี่ยวกับความหมายของตัวแปร ซึ่งในที่สุดก็ส่งผลให้เกิดบั๊ก
บางครั้งคุณจะต้องใช้ตัวแปรหลายตัวที่อ้างถึงสิ่งประเภทเดียวกันทั่วไป ตัวอย่างเช่น method ที่คัดลอกข้อมูลไฟล์จะต้องใช้หมายเลขบล็อกสองหมายเลข หนึ่งสำหรับแหล่งที่มาและหนึ่งสำหรับปลายทาง เมื่อเกิดเหตุการณ์นี้ ให้ใช้ชื่อทั่วไปสำหรับแต่ละตัวแปร แต่เพิ่มคำนำหน้าที่แตกต่างกัน เช่น srcFileBlock และ dstFileBlock .
ลูปเป็นอีกพื้นที่ที่การตั้งชื่อที่สอดคล้องกันสามารถช่วยได้ ถ้าคุณใช้ชื่อเช่น i และ j สำหรับตัวแปรลูป ให้ใช้ i ในลูปนอกสุดเสมอ และ j สำหรับลูปซ้อน ซึ่งช่วยให้ผู้อ่านสามารถตั้งสมมติฐานได้ทันที (อย่างปลอดภัย) เกี่ยวกับสิ่งที่เกิดขึ้นเมื่อพวกเขาเห็นชื่อนั้น
ไม่ใช่ทุกคนที่เห็นด้วยกับความคิดเห็นของฉันเกี่ยวกับการตั้งชื่อ นักพัฒนาบางคนของภาษา 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 สำหรับ character หรือ channel, d สำหรับ data, difference, หรือ distance และอื่น ๆ สำหรับฉันแล้ว ชื่อที่กำกวมแบบนี้มีแนวโน้มที่จะทำให้เกิดความสับสน และข้อผิดพลาด เช่นเดียวกับตัวอย่าง block
โดยรวมแล้ว ฉันอยากจะเถียงว่าความสามารถในการอ่านต้องถูกตัดสินโดยผู้อ่าน ไม่ใช่ผู้เขียน ถ้าคุณเขียนโค้ดด้วยชื่อตัวแปรสั้น ๆ และคนที่อ่านมันพบว่ามัน เข้าใจง่าย ก็ถือว่าใช้ได้ แต่ถ้าคุณเริ่มได้รับคำตำหนิว่าโค้ดของคุณอ่านยาก คุณควรพิจารณาใช้ชื่อที่ยาวขึ้น (การค้นหาใน Web ด้วยคำว่า "go language short names" จะพบคำตำหนิแบบนี้หลายรายการ) ในทำนองเดียวกัน ถ้าฉันเริ่มได้รับคำตำหนิว่าชื่อตัวแปรยาวทำให้โค้ดของฉันอ่านยากขึ้น ฉันก็จะพิจารณาใช้ชื่อที่สั้นลง
Gerrand กล่าวถึงประเด็นหนึ่งที่ฉันเห็นด้วย: "ยิ่งระยะห่างระหว่างการประกาศชื่อและการใช้งานมากเท่าไหร่ ชื่อก็ควรยาวขึ้นเท่านั้น" การอภิปรายก่อนหน้านี้เกี่ยวกับการใช้ตัวแปรลูปชื่อ i และ j ก็เป็นตัวอย่างของกฎนี้
14.6 Conclusion (บทสรุป)
การเลือกชื่อที่ดีช่วยให้โค้ดชัดเจนมากขึ้น เมื่อมีคนพบเห็นตัวแปรเป็นครั้งแรก การเดาครั้งแรกของเขาเกี่ยวกับพฤติกรรมของมัน ซึ่งทำได้โดยไม่ต้องคิดมาก จะถูกต้อง การเลือกชื่อที่ดีเป็นตัวอย่างของ investment mindset ที่กล่าวถึงใน Chapter 3 (บทที่ 3) : ถ้าคุณใช้เวลาเพิ่มเล็กน้อยในตอนเริ่มต้นเพื่อเลือกชื่อที่ดี มันจะทำให้คุณทำงานกับโค้ดในอนาคตได้ง่ายขึ้น นอกจากนี้ คุณยังมีแนวโน้มที่จะทำให้เกิดบั๊กน้อยลงด้วย การพัฒนาทักษะในการตั้งชื่อก็เป็นการลงทุนเช่นกัน เมื่อคุณตัดสินใจครั้งแรกที่จะหยุดพอใจกับชื่อที่พอใช้ได้ คุณอาจพบว่ามันน่าหงุดหงิดและใช้เวลานานในการคิดชื่อที่ดี แต่เมื่อคุณมีประสบการณ์มากขึ้น คุณจะพบว่ามันง่ายขึ้น ในที่สุด คุณจะมาถึงจุดที่แทบไม่ต้องใช้เวลาเพิ่มในการเลือกชื่อที่ดี และคุณจะได้รับประโยชน์เกือบโดยไม่ต้องเสียอะไร