คำถามติดแท็ก coding-style

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

17 database  coding-style 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา ฉันกำลังอ่านรหัสเก่าที่ฉันเขียน (ปีแรกในมหาวิทยาลัย) และสังเกตว่าฉันเคยเขียนชื่อความคิดเห็นก่อนหน้าส่วนต่าง ๆ ของรหัส สิ่งที่ชอบ (นี่คือจากเกม Monopoly): /*Board initialization*/ ...code... /*Player initialization*/ ...code... /*Game logic starts here*/ /*Displaying current situation*/ ...code... /*Executing move*/ ...code... /*Handle special event*/ ...code... /*Commit changes, switch to next player*/ ...code... นี่อาจซ้ำซ้อนและไม่จำเป็นต้องใช้รหัสหากรหัสนั้นชัดเจนจริงๆ แต่เมื่อฉันสแกนผ่านไฟล์มันทำให้ฉันประหลาดใจอย่างมากฉันรู้สึกอย่างยิ่งว่าฉันรู้ว่าเกิดอะไรขึ้นแม้ว่าฉันจะดูรหัสจริงน้อยมาก ฉันสามารถเห็นสิ่งนี้ว่าเหมาะสมในบางสถานการณ์ดังนั้นฉันจึงสงสัยว่าคุณทำสิ่งนี้หรือไม่? คุณคิดว่าเป็นความคิดที่ดีหรือไม่? หรือมันมากเกินไป?

17 coding-style 

Reduce the number of #include files in header files. It will reduce build times. Instead, put include files in source code files and use forward declarations in header files. ฉันอ่านมันที่นี่ http://www.yolinux.com/TUTORIALS/LinuxTutorialC++CodingStyle.html ดังนั้นมันบอกว่าถ้าคลาส (คลาส A) ในไฟล์ส่วนหัวไม่จำเป็นต้องใช้คำจำกัดความที่แท้จริงของบางคลาส (คลาส B) ในเวลานั้นเราสามารถใช้การประกาศไปข้างหน้าแทนการรวมไฟล์ส่วนหัว (คลาส B) โดยเฉพาะ คำถาม: ถ้าคลาส (คลาส A) ในส่วนหัวถ้าไม่ได้ใช้คำจำกัดความที่แท้จริงของคลาสเฉพาะ (คลาส B) ดังนั้นการประกาศล่วงหน้าจะช่วยลดเวลาในการคอมไพล์ได้อย่างไร

17 c++  coding-style 

ในการถกเถียงเกี่ยวกับตัวแปรส่งคืนสมาชิกบางคนในทีมต้องการวิธีการส่งคืนผลลัพธ์โดยตรงไปยังผู้โทรในขณะที่คนอื่น ๆ ต้องการประกาศตัวแปรส่งคืนที่ส่งกลับไปยังผู้โทรแล้ว (ดูตัวอย่างโค้ดด้านล่าง) อาร์กิวเมนต์หลังคืออนุญาตให้นักพัฒนาที่ทำการดีบั๊กโค้ดเพื่อค้นหาค่าส่งคืนของเมธอดก่อนที่มันจะส่งกลับไปยังผู้เรียกดังนั้นจึงทำให้โค้ดเข้าใจง่ายขึ้น: นี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งที่การเรียกใช้เมธอดนั้น มีแนวทางใดบ้างที่มีประสิทธิภาพมากที่สุดและ / หรือมีเหตุผลอื่นใดที่ทำให้เราควรนำสไตล์หนึ่งมาใช้กับสไตล์อื่น? ขอบคุณ private bool Is2(int a) { return a == 2; } private bool Is3(int a) { var result = a == 3; return result; }

17 c#  coding-style  return-type 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา ดูเหมือนว่ามีข้อขัดแย้งกันว่าควรใช้ช่องว่างหรือโทเค็นเช่นวงเล็บเพื่อระบุขอบเขต ฉันได้เห็นวิธีแก้ปัญหาการสรรเสริญของงูใหญ่จำนวนมากเพื่อแก้ไขปัญหาการเยื้องที่ไม่สอดคล้องกันแต่หลายคนไม่เห็นด้วย: ภาษาใดก็ตามที่มีช่องว่างเป็นโทเค็นจะต้องตาย โพสต์ในภายหลังในคำตอบเดียวกัน: ฉันถูกจัดเรียงของต่อต้านช่องว่างเป็นโทเค็นจนกว่าฉันจะลองจริง มันอาจช่วยได้ว่าเลย์เอาต์ white-space ส่วนตัวของฉันนั้นตรงกับสิ่งที่ทุกคนใน python-land ใช้ อาจเป็นเพราะฉันเป็นคนที่เรียบง่าย แต่ถ้าคุณจะเยื้อง ๆ ทำไมต้องกังวลกับ {} s? ฉันเห็นข้อโต้แย้งที่ชัดเจนสำหรับแต่ละด้าน: ใช้ช่องว่าง: ช่วยลดการเยื้องที่ไม่สอดคล้องกันในโค้ด ล้างหน้าจอโดยแทนที่โทเค็นที่มองเห็นได้ด้วยช่องว่างเพื่อให้บริการในวัตถุประสงค์เดียวกัน ใช้โทเค็น: ง่ายกว่าในการตัดและวางรหัสในระดับที่แตกต่างกัน (คุณไม่ต้องแก้ไขการเยื้อง) สอดคล้องกันมากขึ้น เครื่องมือแก้ไขข้อความบางส่วนแสดงพื้นที่ว่างต่างกัน ที่นิยมมากขึ้นในปัจจุบัน มีจุดใดที่ฉันพลาดหรือไม่ คุณชอบอันไหน? คำพูดใด ๆ ของปัญญาหลังจากทำงานกับคนใดคนหนึ่งเป็นเวลานาน? PS ฉันเกลียดเมื่อภาษาไม่ใช้โทเค็นเดียวกันสำหรับแต่ละโครงสร้างการควบคุม VB นั้นน่ารำคาญมากกับข้อความEnd IfและEnd Whileข้อความภาษาอื่น ๆ ส่วนใหญ่ใช้ {} เพื่อทุกสิ่ง แต่อาจเป็นหัวข้อสำหรับคำถามอื่น ...

17 coding-style 

เมื่อไม่นานมานี้ฉันเริ่มใช้ Scala แทน Java ส่วนหนึ่งของกระบวนการ "แปลง" ระหว่างภาษาสำหรับฉันได้เรียนรู้การใช้งานEitherอัตโนมัติแทน (ตรวจสอบ) Exceptions ฉันได้รับการเข้ารหัสด้วยวิธีนี้มาระยะหนึ่งแล้ว แต่เมื่อไม่นานมานี้ฉันเริ่มสงสัยว่าเป็นวิธีที่ดีกว่าหรือไม่ ข้อEitherได้เปรียบที่สำคัญอย่างหนึ่งที่มากกว่าExceptionคือประสิทธิภาพที่ดีกว่า Exceptionความต้องการที่จะสร้างสแต็คร่องรอยและจะถูกโยน เท่าที่ฉันเข้าใจการขว้างปาExceptionไม่ใช่ส่วนที่เรียกร้อง แต่การสร้างสแต็กติดตามคือ แต่แล้วหนึ่งสามารถสร้าง / สืบทอดExceptions พร้อมด้วยscala.util.control.NoStackTraceและมากยิ่งขึ้นดังนั้นผมเห็นความอุดมสมบูรณ์ของกรณีที่ด้านซ้ายของEitherในความเป็นจริงException(ละทิ้งการเพิ่มประสิทธิภาพการทำงาน) ข้อดีอีกข้อหนึ่งEitherก็คือคอมไพเลอร์ - ความปลอดภัย คอมไพเลอร์ Scala จะไม่บ่นเกี่ยวกับExceptions ที่ไม่ได้จัดการ(ต่างจากคอมไพเลอร์ของ Java) แต่ถ้าฉันไม่เข้าใจผิดการตัดสินใจครั้งนี้มีเหตุผลด้วยเหตุผลเดียวกับที่กำลังคุยกันในหัวข้อนี้ดังนั้น ... ในแง่ของไวยากรณ์ฉันรู้สึกว่าExceptionสไตล์นั้นชัดเจนกว่า ตรวจสอบบล็อคโค้ดต่อไปนี้ (ทั้งการใช้ฟังก์ชันเดียวกัน): Either รูปแบบ: def compute(): Either[String, Int] = { val aEither: Either[String, String] = if (someCondition) Right("good") else Left("bad") …

17 coding-style  exceptions  scala  either 

ฉันสงสัยอยู่เสมอว่าโปรแกรมเมอร์คนอื่น ๆ คิดอย่างไรเกี่ยวกับความคิดในการสร้างฟังก์ชั่นความงามที่บริสุทธิ์ Function ProcessBigDataว่าฉันมีฟังก์ชั่นที่ประมวลผลชิ้นของข้อมูลที่: Step1บอกว่าผมต้องทำตามขั้นตอนกระบวนการหลายใช้ได้เฉพาะสำหรับข้อมูลที่: Step2, Step3, aproach ปกติฉันเห็นมากที่สุดในซอร์สโค้ดคือการเขียนความเห็นเช่น: Function ProcessBigData: # Does Step1 Step1.. Step1.. #Does Step2 Step2.. Step2.. สิ่งที่ฉันมักจะทำ แต่มักจะรู้สึกผิดเพราะขาดรูปแบบการเข้ารหัสโดยเพื่อนร่วมงานคือ: Function ProcessBigData: Function Step1: Step1.. Step1.. Function Step2: Step2.. Step2.. Step1() -> Step2() ฉันเป็นห่วงถ้ามีข้อเสียสำหรับสไตล์ดังกล่าวในJavascriptและPython มีทางเลือกอื่นที่ฉันไม่เห็นหรือไม่?

16 javascript  python  coding-style 

codebase ที่ฉันกำลังทำงานอยู่ในขณะนี้มีแบบแผนของการใช้เขตข้อมูลส่วนตัวและคุณสมบัติสาธารณะ ตัวอย่างเช่นคลาสส่วนใหญ่มีสมาชิกกำหนดไว้ดังนี้: // Fields private double _foo; private double _bar; private double _baz; // Properties public double Foo { get{ return _foo; } set{ _foo = value; } } public double Bar { get{ return _bar; } set{ _bar = value; } } public double Baz { get{ return …

16 c#  coding-style 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา ฉันแน่ใจว่าพวกเราหลายคนเคยเห็นชื่อวิธีการเช่นนี้ในจุดหนึ่งหรืออื่น ๆ : UploadTheFileToTheServerPlease CreateATemporaryFile WriteTheRecordToTheDatabase ResetTheSystemClock นั่นคือชื่อวิธีการที่ถูกต้องตามหลักไวยากรณ์ประโยคภาษาอังกฤษและรวมถึงคำพิเศษเพื่อให้พวกเขาอ่านเหมือนร้อยแก้ว โดยส่วนตัวฉันไม่ได้เป็นแฟนตัวยงของชื่อวิธีการ "ตามตัวอักษร" และชอบที่จะประสบความสำเร็จในขณะที่ยังคงชัดเจนที่สุด สำหรับฉันแล้วคำเช่น "a", "an" และ "the" แค่ดูธรรมดา ๆ ในชื่อเมธอดและทำให้ชื่อเมธอดยาวโดยไม่จำเป็นโดยไม่ต้องเพิ่มอะไรที่มีประโยชน์จริงๆ ฉันต้องการชื่อวิธีการต่อไปนี้สำหรับตัวอย่างก่อนหน้านี้: UploadFileToServer CreateTemporaryFile WriteOutRecord ResetSystemClock จากประสบการณ์ของฉันนี่เป็นเรื่องธรรมดามากกว่าวิธีอื่นในการเขียนชื่อที่ยาวกว่า แต่ฉันได้เห็นทั้งสไตล์และอยากรู้อยากเห็นว่าความคิดของคนอื่นเป็นอย่างไรในสองแนวทางนี้ ดังนั้นคุณอยู่ใน "ชื่อเมธอดที่อ่านเหมือนร้อยแก้ว" หรือ "เมธอดชื่อที่พูดในสิ่งที่ฉันหมายถึง แต่อ่านออกมาดัง ๆ เช่นการแปลภาษาต่างประเทศเป็นภาษาอังกฤษที่ไม่ดี" ค่าย?

16 coding-style  naming 

ฉันทำงานเป็นผู้พัฒนา iOS ใน บริษัท เอาท์ซอร์สขนาดเล็กในทีมขนาด 4 คน เราทำงานในโครงการที่เริ่มเมื่อสองสามปีก่อนที่ฉันและนักพัฒนาอีกสองคนจะเข้าร่วม บริษัท ก่อนหน้านี้โครงการส่วนใหญ่ดำเนินการโดยบุคคลเดียว เมื่อฉันเริ่มทำงานในโครงการมันเป็นความยุ่งเหยิงอย่างสมบูรณ์ มีการทำซ้ำรหัสจำนวนมาก ฉันเห็นโค้ด 500 ตัวเดียวกันกับไฟล์ที่แตกต่างกัน 20 ไฟล์โดยมีการเปลี่ยนแปลงเล็กน้อย นอกจากนี้มันไม่ได้ถูกจัดระเบียบอย่างถูกต้อง: รหัสการสร้าง UI ทั้งหมดถูกผสมในตัวควบคุมมุมมองพร้อมกับตรรกะ ฉันพยายามอย่างที่สุดในการทำสิ่งต่าง ๆ ที่นี่และที่นั่นกำจัดรหัสซ้ำซ้อนปรับปรุงโครงสร้างไฟล์ของโครงการและอื่น ๆ รู้สึกเหมือนผู้พัฒนาก่อนหน้าไม่สนใจสิ่งเหล่านี้ทั้งหมดหรือไม่มีประสบการณ์ มีเวลาที่ฉันทำงานคนเดียวกับคุณสมบัติที่ยิ่งใหญ่สักสองสามเดือน เนื่องจากลักษณะของคุณสมบัตินี้ฉันต้องสัมผัสโค้ดจำนวนมากในแอพทั้งหมดดังนั้นฉันจึงพยายามปรับปรุงบางอย่าง เมื่อนักพัฒนารายอื่นเข้าร่วมโครงการฉันสังเกตเห็นว่าพวกเขาใช้รูปแบบการเข้ารหัสที่แตกต่างกัน (บางครั้งก็เป็นสไตล์ที่แตกต่างอย่างสิ้นเชิง) และมักจะไม่ใช้คุณสมบัติภาษาสมัยใหม่เช่นตัวเข้าถึงคุณสมบัติ บางครั้งพวกเขาจะประดิษฐ์จักรยานของตัวเองแทนที่จะใช้คุณสมบัติที่คล้ายกันของกรอบงานหรือถ่ายโอนแนวคิดจากภาษาโปรแกรมหรือ patters อื่น ๆ ที่พวกเขาเรียนรู้ลงในฐานรหัสของเรา บ่อยครั้งที่พวกเขาไม่สามารถตั้งชื่อวิธีการหรือตัวแปรได้อย่างเหมาะสมเนื่องจากภาษาอังกฤษไม่ดี (Objective-C เป็นภาษาที่คุณใช้ชื่อยาว) บางครั้งฉันคิดว่าถ้าไม่ใช่สำหรับ IDE ฉันคิดว่าพวกเขาจะเขียนโค้ดทั้งหมดโดยไม่มีการเยื้องหรือการจัดรูปแบบเลย โดยทั่วไปฉันเกลียดโค้ดที่เขียน มันมีการจัดรูปแบบ / จัดระเบียบไม่ดีและบางครั้งก็แตกต่างอย่างสิ้นเชิงจากส่วนที่เหลือของโครงการ ฉันรู้สึกหงุดหงิดมากเมื่อพวกเขาเพิ่มสปาเก็ตตี้ในงานศิลปะของฉันและมันส่งผลต่ออารมณ์ในที่ทำงานและประสิทธิภาพการทำงานของฉัน มันให้ความรู้สึกมากขึ้นเรื่อย ๆ เช่นพวกเขาไม่สามารถใส่ใจเรียนรู้หรือไม่สนใจพวกเขาทำสิ่งที่พวกเขาต้องการและกลับบ้าน …

16 coding-style  teamwork 

ฉันเริ่มแอพกรีนฟิลด์และฉันต้องการใช้ ASP.NET (4.6) และ Angular 2 สำหรับแบ็กเอนด์ฉันได้สร้างโครงการใน Visual Studio และตอนนี้ฉันสงสัยว่าจะวางแอพ Angular ไว้ที่ไหน ฉันต้องการใช้ npm และ node-tools สำหรับ front-end แต่ท้ายที่สุดมันจะถูกโฮสต์ในอินสแตนซ์ Azure App Service เดียวกันกับแอป Angular ที่domain.com/และ api ภายใต้domain.com/api/หรือเช่นนั้น ฉันจะแยกแอพต่าง ๆ ใน Visual Studio ได้อย่างไร? แอพเชิงมุมควรอยู่ในโครงการของตัวเองหรือไม่ ฉันควรมีแอปพลิเคชัน Angular ในโครงการเดียวกันกับ API หรือไม่ แม้ว่าฉันไม่ต้องการใช้ nuget และเครื่องมือ VS อื่น ๆ (สำหรับส่วนหน้า VS จะเป็นตัวแก้ไขรหัสที่ได้รับเกียรติมากขึ้นหรือน้อยลง) ฉันไม่พบวิธีปฏิบัติที่ดีที่สุดสำหรับชุดค่าผสมนี้

16 coding-style  asp.net  visual-studio  angularjs 

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

16 c  coding-style 

ตัวดำเนินการเพิ่มของคลาส set ส่งคืนบูลีนซึ่งเป็นจริงหากองค์ประกอบ (ซึ่งจะถูกเพิ่ม) ยังไม่มีอยู่และเป็นเท็จ กำลังเขียน if (set.add(entry)) { //do some more stuff } ถือว่าเป็นสไตล์ที่ดีในแง่ของการเขียนโค้ดที่สะอาด? ฉันสงสัยว่าคุณทำสองสิ่งพร้อมกัน 1) การเพิ่มองค์ประกอบและ 2) การตรวจสอบว่ามีองค์ประกอบอยู่หรือไม่

15 java  coding-style  clean-code 

ดังนั้นอย่างที่คุณรู้ว่ามีวิธีปฏิบัติที่ดีที่สุดว่า จำกัด แถวของซอร์สโค้ดไม่เกิน 80 อักขระ นี่คือ 2 ลิงค์: เพราะเหตุใด 80 อักขระจึงถูกจำกัดความกว้างของมาตรฐานสำหรับความกว้างของรหัส ขีด จำกัด 80 อักขระยังคงมีความเกี่ยวข้องในช่วงเวลาของจอภาพแบบจอกว้างหรือไม่ และฉันมั่นใจว่าคุณสามารถทำได้ดีขึ้นหากคุณค้นหาแนวปฏิบัติที่ดีที่สุดนี้ แต่ฉันพบว่ามันยากมากนี่คือตัวอย่าง: public class MyClass { public void myMethod() { final Map<String, List<MyInterfaceHere>> myReference ดังนั้นคุณเยื้องแต่ละชั้นเรียนและแต่ละวิธีและแต่ละคำสั่ง และฉันอยู่ที่คอลัมน์ 60 ในตอนท้ายของ 'e' สุดท้ายที่ฉันมีใน 'myReference' ฉันมีช่องว่างเหลืออีก 20 ช่องเรียกว่าตัวสร้างและกำหนดวัตถุให้กับการอ้างอิงที่ฉันมี ฉันหมายความว่านี่ดูดีกว่าจริงๆ: public class MyClass { public void myMethod() { final Map<String, …

15 coding-style 

ฉันเจอคำถามนี้เมื่อสองวินาทีก่อนและฉันดึงเนื้อหาบางส่วนออกจากที่นั่น: มีชื่อของโครงสร้าง 'break n' หรือไม่? สิ่งนี้ดูเหมือนจะเป็นวิธีที่ซับซ้อนอย่างไม่จำเป็นสำหรับคนที่จะต้องสั่งให้โปรแกรมแยกย่อยซ้อนกันสำหรับลูป: for (i = 0; i < 10; i++) { bool broken = false; for (j = 10; j > 0; j--) { if (j == i) { broken = true; break; } } if (broken) break; } ฉันรู้ว่าหนังสือที่ชอบพูดประโยค goto เป็นมารและฉันไม่ชอบมันเลย แต่สิ่งนี้แสดงให้เห็นถึงข้อยกเว้นของกฎหรือไม่? ฉันกำลังมองหาคำตอบที่จัดการกับ n-ซ้อนสำหรับลูป หมายเหตุ:ไม่ว่าคุณจะตอบว่าใช่, …

15 coding-style  goto