ฉันควรใช้ตัวแปรซ้ำหรือไม่

59

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

แต่ผมไม่ทราบว่าการปฏิบัติที่ดีที่สุดคือใช้เวลาส่วนใหญ่กับมัน ตัวอย่างเช่นพวกเขาบอกว่าไม่ได้ "แทนที่" พารามิเตอร์วิธีการ

แนวทางปฏิบัติที่ดีที่สุดคือแม้จะขัดกับโมฆะตัวแปรก่อนหน้านี้ (ใน Java มี Sonar ที่ให้คำเตือนเมื่อคุณกำหนดให้nullกับตัวแปรที่คุณไม่จำเป็นต้องเรียกมันไปที่ตัวรวบรวมขยะตั้งแต่ Java 6 คุณไม่สามารถควบคุมได้เสมอ คำเตือนใดปิดอยู่ส่วนใหญ่เป็นค่าเริ่มต้น)

code-quality coding-style variables

— IAdapter
แหล่งที่มา

11

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

— Kevin Panko

35

การใช้ตัวแปรอีกครั้งเป็นหนึ่งในสิ่งแรกที่ผู้ทำรหัสใช้ obfuscators

— Lelouch Lamperouge

7

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

— Joren

4

โปรดทราบด้วยว่าการใช้ซ้ำทั้งหมดไม่สามารถนำมาใช้ซ้ำได้ โปรแกรมเมอร์เก่าแก่ของ FORTRAN แม้กระทั่งผู้ที่ล่องลอยไปยังภาษาอื่น ๆ ใช้ I, J, K, L, M, N (หรือ i, j, k, l, m, n) สำหรับ DO-loop ทั้งหมดของเรา ห่วง) เคาน์เตอร์ เราเคยเห็นสิ่งต่าง ๆ เช่น SUM = SUM + A (I, K) * B (K, J) หรือผลรวม + = a [i] [k] * b [k] [j];

— John R. Strohm

1

ตัวแปรที่นำมาใช้ใหม่อาจเป็นธรรมเมื่อการเขียนโปรแกรมไมโครคอนโทรลเลอร์ด้วยทรัพยากรที่ จำกัด มาก (ไม่กี่ kBytes of RAM)

— m.Alin

130

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

แนวทางปฏิบัติที่ดีที่สุดของ IMO คือการใช้วิธีการสั้น ๆ ซึ่งทำสิ่งเดียวเท่านั้นขจัดปัญหาทั้งหมด

— PéterTörök
แหล่งที่มา

แล้วการทดสอบหน่วยล่ะ เช่นฉันต้องการทดสอบว่าหลังจากดำเนินการวิธีการเป็นครั้งที่สองก็ยังคงทำงานตามที่คาดไว้

— IAdapter

20

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

— PéterTörök

3

@IAdapter สำหรับสถานการณ์ที่คุณอธิบายฉันจะไม่ใช้ตัวแปรซ้ำ สิ่งที่เหมาะสมจะเป็นสิ่งที่result1 = foo(); result2 = foo(); Assert.AreEqual(result1, result2);ฉันไม่เห็นสถานที่มากมายที่คุณจะต้องนำตัวแปรมาใช้ซ้ำในกรณีนี้

— JSB ձոգչ

1

@IAdapter สำหรับ (int i = 0; i <2; i ++) {result = foo (); assertEquals (expectResult ผลลัพธ์);}

— Bill K

2

+1 - นี่คือกลิ่นรหัสที่ดีสำหรับเมื่อทำวิธีเล็ก

49

การใช้ซ้ำตัวแปรในวิธีการเป็นสัญญาณที่ดีที่คุณควรกำหนด / แยกใหม่

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

— Thanos Papathanasiou
แหล่งที่มา

19

มันขึ้นอยู่กับ.

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

void my_function() {
    HRESULT errorcode;
    errorcode = ::SomeWindowsApiFunction();
    if (FAILED(errorcode)) { /* handle error */ }
    errorcode = ::AnotherWindowsApiFunction();
    if (FAILED(errorcode)) { /* handle error */ }
}

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

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

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

— เฟลิกซ์ Dombek
แหล่งที่มา

15

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

— sbrenton
แหล่งที่มา

ดังนั้นฉันควรเขียนวิธีทดสอบเช่น -testSomething และ assert สำหรับการเรียกใช้เมธอดเดียว -testSomethingTwoInvocations และ asserts สำหรับการเรียกใช้ครั้งที่สองเท่านั้น?

— IAdapter

2

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

— ไบรอัน Boettcher

หากคุณใช้ "ตัวแปร" เมื่อคุณหมายถึง "ตัวแปรคลาส" หรือ "ตัวแปรอินสแตนซ์" จากนั้นคุณต้องแสดงตัวเองชัดเจนยิ่งขึ้น

— gnasher729

13

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

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

— SL บาร์ท
แหล่งที่มา

4

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

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

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

— Joris Timmermans
แหล่งที่มา

17

-1 เว้นแต่ว่าคุณสามารถชี้ไปที่สถานการณ์ในโลกแห่งความจริงที่สิ่งนี้เกิดขึ้นจริงและการใช้ตัวแปรซ้ำทำให้เกิดความแตกต่างที่เห็นได้ นี่เป็นวิธีแก้ปัญหาเชิงทฤษฎีสำหรับปัญหาเชิงทฤษฎีและไม่ใช่สิ่งที่ดีมากในตอนนั้น ในกรณีที่คอมไพเลอร์ตัดสินใจที่จะนำตัวแปรมาเป็นข้อกังวล หากคอมไพเลอร์ของคุณสร้างรหัสที่ไม่ดีและถ้ามันสร้างความแตกต่างจริงๆแล้วแก้ไขหรือแทนที่คอมไพเลอร์

— คาเลบ

3

@Caleb - คุณไม่สามารถเข้าถึงซอร์สโค้ดคอมไพเลอร์สำหรับแพลตฟอร์มที่คุณกำลังพัฒนาอยู่เสมอโดยเฉพาะอย่างยิ่งสำหรับแพลตฟอร์มแบบฝังที่เป็นกรรมสิทธิ์ ฉันยังDIDพูดในคำตอบของฉันที่ฉันไม่ทราบว่าของคอมไพเลอร์ที่สำคัญใด ๆ ในปัจจุบัน (หรือล่าม / VMs ในความเป็นจริง) ที่ไม่ถูกต้องดำเนินการวิเคราะห์นี้คงอยู่ในทุกกรณีที่ผมได้มองไปที่ อย่างไรก็ตามฉันได้ทำงานเกี่ยวกับระบบฝังตัวที่เป็นกรรมสิทธิ์พร้อมคอมไพเลอร์แบบกำหนดเองซึ่งเป็นกระดูกที่เปลือยเปล่ามากในอดีต (10 ปีก่อนหรือมากกว่านั้น) ระบบมีขีดความสามารถ จำกัด มากและคอมไพเลอร์ดังนั้นสถานการณ์นี้จึงเกิดขึ้นที่นั่น

— Joris Timmermans

2

+1 ฉันทำเช่นนั้นซ้ำนำมาใช้ในโครงการที่ผ่านมา (รหัสสื่อที่เพิ่มประสิทธิภาพสูงที่เขียนใน ANSI C) เท่าที่ฉันจำได้ความแตกต่างนั้นสามารถมองเห็นได้ง่ายในการชุมนุมและสามารถวัดได้ในมาตรฐาน ไม่เคยทำและหวังว่าจะไม่ต้องใช้ซ้ำใน Java

— ริ้น

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

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

— คาเลบ

2

ฉันจะบอกว่าไม่มี

คิดเกี่ยวกับสถานการณ์นี้: โปรแกรมของคุณล้มเหลวและคุณต้องจัดการสิ่งที่เกิดขึ้นโดยการตรวจสอบการถ่ายโอนข้อมูลหลัก ... คุณเห็นความแตกต่างหรือไม่ ;-)

— Fortran
แหล่งที่มา

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

— Winston Ewert

แน่นอนการสร้างที่ปรับให้เหมาะสมนั้นไม่มีประโยชน์สำหรับการดีบัก! แต่ในกรณีใด ๆ คุณยังคงมีตัวเลือกในการใช้ debug build ... และเมื่อคุณแนบ debugger แล้วคุณไม่จำเป็นต้องไปทีละขั้นตอนตั้งแต่ต้นฟังก์ชั่นเพื่อดูว่าตัวแปรเปลี่ยนแปลงไปอย่างไร ทำไม่ได้! :-D

— fortran

2

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

— Rawbert
แหล่งที่มา

0

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

scrote = int (scrote)

แต่ในที่สุดฉันก็ต้องการเปลี่ยนประเภทที่ส่งไปยังฟังก์ชันและบันทึกการเปลี่ยนแปลงในประเภทพารามิเตอร์

— Paddy3118
แหล่งที่มา

1

การวางบรรทัดอย่าง "scrote = int (scrote)" ไว้ตรงกลางของชุดรหัสยาวเป็นวิธีที่ยอดเยี่ยมในการผลักดันโปรแกรมเมอร์บำรุงรักษาอย่างบ้าคลั่ง

— jhocking

ปัญหาน่าจะเกิดจาก "รหัสชุดยาว" ที่คุณพูดถึง

— Paddy3118

เช่นเดียวกับบันทึกคำตอบที่ได้รับการยอมรับการใช้ตัวแปรซ้ำเป็นเพียงปัญหาที่เกิดขึ้นกับโค้ดแบบยาว โดยทั่วไปในสถานการณ์ใด ๆ ที่คุณจะเขียนอะไรบางอย่างเช่น "scrote = int (scrote)" ฉันต้องการที่จะใส่ int (scrote) ในตัวแปรใหม่หรือดีกว่ายังผ่าน int (scrote) ไปยังฟังก์ชันใหม่

— jhocking

0

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

ดีบักเกอร์ของคุณอาจทำให้เจ็บปวดในการดีบักฟังก์ชันที่มีตัวแปรมากมาย หากฟังก์ชั่นที่มี 20 ตัวแปรยากที่จะดีบั๊กมากกว่าหนึ่งด้วย 16 ตัวแปรคุณอาจพิจารณาแทนที่ 5 ตัวแปรด้วยหนึ่ง ("อาจพิจารณา" ไม่เหมือนกับ "ควรเสมอ")

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

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

— gnasher729
แหล่งที่มา

0

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

ดีบักเกอร์ของคุณอาจทำให้เจ็บปวดในการดีบักฟังก์ชันที่มีตัวแปรมากมาย หากฟังก์ชั่นที่มี 20 ตัวแปรยากที่จะดีบั๊กมากกว่าหนึ่งด้วย 16 ตัวแปรคุณอาจพิจารณาแทนที่ 5 ตัวแปรด้วยหนึ่ง ("อาจพิจารณา" ไม่เหมือนกับ "ควรเสมอ")

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

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

— gnasher729
แหล่งที่มา

-2

ใช้ตัวแปรโกลบอลเมื่อคุณต้องการรักษาสถานะหรือค่าคงที่ร้านค้า ด้วยการใช้ตัวแปรซ้ำคุณจะใช้ชื่อที่ชี้ไปยังตำแหน่งในหน่วยความจำใหม่เท่านั้น ชื่อเชิงอธิบายเกี่ยวกับการเริ่มต้นสามารถชนะคุณชัดเจนเท่านั้น (สมมติว่า Java และไม่มี OCD ดั้งเดิม)

นอกจากว่าคุณกำลังใช้โค้ดที่ทำให้งงงวยด้วยมือหรือทำให้นักพัฒนาคนอื่นรำคาญ

— JunoA
แหล่งที่มา