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

ฉันมักจะพูดคุยกับโปรแกรมเมอร์ที่พูดว่า " อย่าใส่ข้อความส่งคืนหลายรายการในวิธีเดียวกัน " เมื่อฉันขอให้พวกเขาบอกเหตุผลว่าทำไมสิ่งที่ฉันได้คือ " มาตรฐานการเข้ารหัสบอกเช่นนั้น " หรือ " มันสับสน " เมื่อพวกเขาแสดงวิธีการแก้ปัญหาให้ฉันด้วยคำสั่งการส่งคืนเดียวรหัสดูเหมือนจะไม่ดีสำหรับฉัน ตัวอย่างเช่น: if (condition) return 42; else return 97; " นี่น่าเกลียดคุณต้องใช้ตัวแปรเฉพาะที่! " int result; if (condition) result = 42; else result = 97; return result; การขยายโค้ด 50% นี้ทำให้โปรแกรมเข้าใจได้ง่ายขึ้นอย่างไร โดยส่วนตัวแล้วฉันพบว่ามันยากขึ้นเพราะพื้นที่ของรัฐเพิ่มขึ้นจากตัวแปรอื่นที่สามารถป้องกันได้ง่าย แน่นอนโดยปกติฉันจะเขียน: return (condition) ? 42 : 97; แต่โปรแกรมเมอร์จำนวนมากหลีกเลี่ยงผู้ปฏิบัติงานที่มีเงื่อนไขและชอบแบบยาว แนวคิดเรื่อง …

1055 coding-style  coding-standards  history  control-structures 

ฉันมักจะเขียนฟังก์ชันประเภทนี้ทั้งสองรูปแบบและฉันสงสัยว่ารูปแบบใดรูปแบบหนึ่งที่ต้องการมากกว่าอีกรูปแบบหนึ่งและทำไม public void SomeFunction(bool someCondition) { if (someCondition) { // Do Something } } หรือ public void SomeFunction(bool someCondition) { if (!someCondition) return; // Do Something } ฉันมักจะเขียนโค๊ดกับอันแรกเพราะนั่นเป็นวิธีที่สมองของฉันทำงานขณะเขียนโค้ดถึงแม้ว่าฉันคิดว่าฉันชอบอันที่สองเพราะมันจะจัดการกับข้อผิดพลาดในการจัดการทันทีและฉันอ่านง่ายขึ้น

304 coding-style  conditions  control-structures 

การจัดฟันแบบหยิกควรอยู่ในแนวของตนเองหรือไม่? คุณคิดยังไงกับเรื่องนี้? if (you.hasAnswer()) { you.postAnswer(); } else { you.doSomething(); } หรือมันควรจะเป็น if (you.hasAnswer()) { you.postAnswer(); } else { you.doSomething(); } หรือแม้กระทั่ง if (you.hasAnswer()) you.postAnswer(); else you.doSomething(); โปรดสร้างสรรค์! อธิบายว่าทำไมแบ่งปันประสบการณ์สำรองข้อมูลด้วยข้อเท็จจริงและการอ้างอิง

273 coding-style  code-formatting 

เจ้านายของฉันพูดถึงอย่างเมินเฉยว่าโปรแกรมเมอร์ที่ไม่ดีใช้breakและcontinueวนซ้ำ ฉันใช้มันตลอดเวลาเพราะมันสมเหตุสมผล ให้ฉันแสดงแรงบันดาลใจ: function verify(object) { if (object->value < 0) return false; if (object->value > object->max_value) return false; if (object->name == "") return false; ... } จุดที่นี่คือก่อนอื่นฟังก์ชันตรวจสอบว่าเงื่อนไขถูกต้องจากนั้นดำเนินการฟังก์ชันการทำงานจริง IMO เช่นเดียวกับลูป: while (primary_condition) { if (loop_count > 1000) break; if (time_exect > 3600) break; if (this->data == "undefined") continue; if (this->skip == …

191 coding-style  language-agnostic  syntax  readability  control-structures 

ฉันไม่ได้เขียนโครงการขนาดใหญ่จริงๆ ฉันไม่ได้บำรุงรักษาฐานข้อมูลขนาดใหญ่หรือจัดการกับโค้ดหลายล้านบรรทัด รหัสของฉันคือ "สคริปต์" สิ่งที่พิมพ์ - สิ่งที่จะทดสอบฟังก์ชั่นทางคณิตศาสตร์หรือเพื่อจำลองบางอย่าง - "การเขียนโปรแกรมทางวิทยาศาสตร์" โปรแกรมที่ยาวที่สุดที่ฉันทำงานจนถึงจุดนี้คือโค้ดสองร้อยบรรทัดและโปรแกรมส่วนใหญ่ที่ฉันใช้อยู่นั้นมีประมาณ 150 รายการ รหัสของฉันยังอึ ฉันรู้เรื่องนี้เมื่อวันก่อนขณะที่ฉันพยายามค้นหาไฟล์ที่ฉันเขียนสักครู่แล้ว แต่ฉันอาจจะเขียนทับและฉันไม่ได้ใช้การควบคุมเวอร์ชันซึ่งอาจทำให้คุณรู้สึกปวดร้าวใจเป็นจำนวนมาก รูปแบบของรหัสของฉันมีความซับซ้อนและเต็มไปด้วยความคิดเห็นที่ล้าสมัยซึ่งระบุวิธีอื่นในการทำบางสิ่งหรือคัดลอกบรรทัดของรหัสไป ในขณะที่ชื่อตัวแปรเริ่มต้นที่ดีมากและเป็นคำอธิบายในขณะที่ฉันเพิ่มหรือเปลี่ยนแปลงสิ่งต่าง ๆ ตามเช่นสิ่งใหม่ที่ใครบางคนต้องการทดสอบรหัสได้รับการซ้อนทับด้านบนและเขียนทับและเพราะฉันรู้สึกว่าสิ่งนี้ควรทดสอบอย่างรวดเร็วตอนนี้ มีกรอบฉันเริ่มใช้ชื่อตัวแปรเส็งเคร็งและไฟล์ไปที่หม้อ ในโครงการที่ฉันกำลังทำอยู่ตอนนี้ฉันอยู่ในช่วงที่สิ่งเหล่านี้กลับมากัดฉันอย่างมาก แต่ปัญหาคือ (นอกเหนือจากการใช้การควบคุมเวอร์ชันและการสร้างไฟล์ใหม่สำหรับการทำซ้ำแต่ละครั้งและบันทึกทั้งหมดในไฟล์ข้อความที่ไหนสักแห่งซึ่งอาจจะช่วยสถานการณ์ได้อย่างมาก) ฉันไม่รู้จริง ๆ ว่าจะดำเนินการปรับปรุงอย่างไร สไตล์การเข้ารหัสที่แท้จริงของฉัน การทดสอบหน่วยจำเป็นสำหรับการเขียนโค้ดขนาดเล็กลงหรือไม่? แล้ว OOP ล่ะ วิธีใดบ้างที่ดีสำหรับการเขียนโค้ดที่ดีและสะอาดได้อย่างรวดเร็วเมื่อทำการ "การเขียนโปรแกรมเชิงวิทยาศาสตร์" ซึ่งต่างจากการทำงานในโครงการขนาดใหญ่ ฉันถามคำถามเหล่านี้เพราะบ่อยครั้งการเขียนโปรแกรมเองนั้นไม่ซับซ้อน มันเกี่ยวกับคณิตศาสตร์หรือวิทยาศาสตร์ที่ฉันกำลังทดสอบหรือค้นคว้าด้วยการเขียนโปรแกรม เช่นคลาสจำเป็นหรือไม่เมื่อมีตัวแปรสองตัวและฟังก์ชั่นอาจดูแลได้ (พิจารณาสิ่งเหล่านี้โดยทั่วไปเป็นสถานการณ์ที่ความเร็วของโปรแกรมเป็นที่ต้องการในตอนท้ายที่เร็วกว่า - เมื่อคุณรันขั้นตอนการจำลองมากกว่า 25,000,000+ ครั้งคุณต้องการให้มันเป็นแบบนั้น) บางทีนี่อาจจะกว้างเกินไปและถ้าเป็นเช่นนั้นฉันขอโทษ แต่เมื่อดูหนังสือโปรแกรมพวกเขามักจะพูดถึงโครงการขนาดใหญ่ รหัสของฉันไม่จำเป็นต้องมี OOP และมันก็ค่อนข้างสั้นอยู่แล้วดังนั้นจึงไม่เหมือน "โอ้ แต่ไฟล์จะลดลงหนึ่งพันบรรทัดถ้าเราทำอย่างนั้น!" ฉันต้องการทราบวิธี …

169 python  coding-style  clean-code  python-3.x 

ฉันมีความคุ้นเคยนักพัฒนาที่มีประสบการณ์มากกว่าฉัน เรากำลังพูดถึงวิธีปฏิบัติในการเขียนโปรแกรมและฉันถูกผงะโดยวิธีการของเขาในงบ 'ถ้า' เขายืนยันในการปฏิบัติบางอย่างเกี่ยวกับว่าข้อความที่ฉันพบค่อนข้างแปลก ประการแรกคำสั่ง if ควรจะตามด้วยคำสั่ง else ไม่ว่าจะมีบางสิ่งที่จะใส่เข้าไปหรือไม่ ซึ่งนำไปสู่รหัสที่มีลักษณะเช่นนี้: if(condition) { doStuff(); return whatever; } else { } ประการที่สองจะเป็นการดีกว่าที่จะทดสอบค่าจริงแทนที่จะเป็นเท็จ นั่นหมายความว่าเป็นการดีกว่าที่จะทดสอบตัวแปร 'doorClosed' แทนที่จะเป็นตัวแปร '! doorOpened' เหตุผลของเขาคือทำให้ชัดเจนว่ารหัสกำลังทำอะไร ซึ่งทำให้ฉันสับสนเล็กน้อยเนื่องจากการรวมกันของกฎทั้งสองสามารถนำเขาไปสู่การเขียนโค้ดชนิดนี้หากเขาต้องการทำอะไรบางอย่างเมื่อเงื่อนไขไม่ตรง if(condition) { } else { doStuff(); return whatever; } ความรู้สึกของฉันเกี่ยวกับเรื่องนี้ก็คือมันน่าเกลียดมากและ / หรือว่าการปรับปรุงคุณภาพถ้ามีมีเล็กน้อย แต่ในฐานะรุ่นน้องฉันมักจะสงสัยสัญชาตญาณของตัวเอง ดังนั้นคำถามของฉันคือ: มันเป็นการปฏิบัติที่ดี / ไม่ดี / "ไม่สำคัญ"? มันเป็นเรื่องธรรมดา

169 coding-style  conditions 

นี่เป็นอาการง่อยเล็กน้อย แต่ทุกครั้งที่ฉันต้องเขียนโค้ดแบบนี้การทำซ้ำจะทำให้ฉันรำคาญใจ แต่ฉันไม่แน่ใจว่าวิธีแก้ปัญหาใด ๆ จะไม่แย่ลง if(FileExists(file)) { contents = OpenFile(file); // <-- prevents inclusion in if if(SomeTest(contents)) { DoSomething(contents); } else { DefaultAction(); } } else { DefaultAction(); } มีชื่อสำหรับตรรกะชนิดนี้หรือไม่? ฉันเป็น OCD ด้วยหรือเปล่า ฉันเปิดให้คำแนะนำรหัสชั่วร้ายเพียงเพื่อความอยากรู้อยากเห็นของ ...

161 coding-style  conditions 

ฉันมีส่วนร่วมในการอภิปรายการเขียนโปรแกรมในวันนี้ที่ฉันทำงบบางอย่างที่โดยทั่วไปถือว่าจริงที่อ้างอิงวงกลม (ระหว่างโมดูลชั้นเรียนสิ่งที่) โดยทั่วไปจะไม่ดี เมื่อฉันผ่านเข้าไปในสนามของฉันเพื่อนร่วมงานของฉันถามว่า "มีอะไรผิดปกติกับการอ้างอิงแบบวงกลม" ฉันมีความรู้สึกที่แข็งแกร่งในเรื่องนี้ แต่มันยากสำหรับฉันที่จะพูดอย่างกระชับและเป็นรูปธรรม คำอธิบายใด ๆ ที่ฉันอาจเกิดขึ้นมีแนวโน้มที่จะพึ่งพารายการอื่น ๆ ที่ฉันพิจารณาความจริง ("ไม่สามารถใช้ในการแยกดังนั้นไม่สามารถทดสอบ", "พฤติกรรมที่ไม่รู้จัก / ไม่ได้กำหนดเป็นรัฐกลายพันธุ์ในวัตถุที่เข้าร่วม" ฯลฯ .) แต่ฉันชอบที่จะได้ยินเหตุผลที่ชัดเจนว่าเพราะเหตุใดการอ้างอิงแบบวงกลมจึงไม่ดีซึ่งไม่ได้ใช้ความเชื่ออย่างที่สมองของฉันทำเองใช้เวลาหลายชั่วโมงกว่าจะแก้ให้เข้าใจแก้ และขยายรหัสบิตต่าง ๆ แก้ไข:ฉันไม่ได้ถามเกี่ยวกับการอ้างอิงแบบวงกลมที่เป็นเนื้อเดียวกันเช่นที่อยู่ในรายการที่ลิงก์สองเท่าหรือตัวชี้ไปยังผู้ปกครอง คำถามนี้ถามเกี่ยวกับการอ้างอิงแบบวงกลม "ขอบเขตที่กว้างขึ้น" เช่น libA การโทร libB ซึ่งโทรกลับไปที่ libA แทน 'โมดูล' สำหรับ 'lib' หากคุณต้องการ ขอบคุณสำหรับคำตอบทั้งหมด!

160 code-quality  coding-style 

สิ่งนี้กลายเป็นความสับสนอย่างใหญ่หลวงกับโค้ดเบสที่ฉันกำลังทำงานอยู่ ชื่อตัวแปรหลายชื่อของเรานั้นสั้นและไม่มีคำอธิบาย ฉันเป็นนักพัฒนาเพียงคนเดียวที่เหลืออยู่ในโครงการและไม่มีเอกสารเกี่ยวกับสิ่งที่พวกเขาส่วนใหญ่ทำดังนั้นฉันต้องใช้เวลาเพิ่มเติมเพื่อติดตามสิ่งที่พวกเขาเป็นตัวแทน ตัวอย่างเช่นฉันอ่านโค้ดบางตัวที่อัพเดตนิยามของผิวหน้าออปติคัล ตัวแปรที่ตั้งไว้ที่จุดเริ่มต้นมีดังนี้: 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 …

140 coding-style  language-agnostic  naming 

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

139 coding-style  readability 

ฉันเคยเห็นส่วนนี้ของ PEP-8 https://www.python.org/dev/peps/pep-0008/#package-and-module-names ฉันยังไม่ชัดเจนว่านี่หมายถึงชื่อไฟล์ของโมดูล / คลาส / แพ็คเกจหรือไม่ หากฉันมีตัวอย่างหนึ่งของชื่อไฟล์ควรเป็นตัวพิมพ์เล็กทั้งหมดที่มีขีดล่างถ้าเหมาะสมหรือไม่ หรืออย่างอื่น?

137 python  coding-style  naming-standards 

ฉันเป็นนักพัฒนาซอฟต์แวร์ระดับสูงที่เข้ารหัสใน Babel ES6 ส่วนหนึ่งของแอปของเราทำการเรียก API และตามแบบจำลองข้อมูลที่เราได้รับกลับมาจากการเรียก API ต้องกรอกแบบฟอร์มบางอย่าง แบบฟอร์มเหล่านั้นจะถูกเก็บไว้ในรายการที่เชื่อมโยงเป็นสองเท่า (ถ้าส่วนหลังระบุว่าข้อมูลบางอย่างไม่ถูกต้องเราสามารถนำผู้ใช้กลับไปที่หน้าหนึ่งที่พวกเขาทำผิดพลาดได้อย่างรวดเร็วแล้วนำกลับมาที่เป้าหมาย รายการ.) อย่างไรก็ตามมีฟังก์ชั่นมากมายที่ใช้ในการเพิ่มหน้าและฉันสงสัยว่าตัวเองฉลาดเกินไปหรือเปล่า นี่เป็นเพียงภาพรวมพื้นฐาน - อัลกอริทึมที่เกิดขึ้นจริงมีความซับซ้อนมากขึ้นโดยมีหน้าและประเภทหน้าเว็บที่แตกต่างกันมากมาย แต่นี่จะเป็นตัวอย่างให้คุณ นี่คือวิธีที่ฉันคิดว่าโปรแกรมเมอร์มือใหม่จะจัดการกับมัน export const addPages = (apiData) => { let pagesList = new PagesList(); if(apiData.pages.foo){ pagesList.add('foo', apiData.pages.foo){ } if (apiData.pages.arrayOfBars){ let bars = apiData.pages.arrayOfBars; bars.forEach((bar) => { pagesList.add(bar.name, bar.data); }) } if (apiData.pages.customBazes) { let …

133 coding-style  functional-programming  teamwork  senior-developer  leadership 

นี่เป็นเรื่องอวดรู้เล็กน้อย แต่ฉันเคยเห็นบางคนใช้Idใน: private int userId; public int getUserId(); และอื่น ๆ ใช้: private int userID; public int getUserID(); หนึ่งในนั้นเป็นชื่อที่ดีกว่าชื่ออื่นหรือไม่? ทำไม? ฉันเคยเห็นสิ่งนี้ทำกันอย่างไม่สอดคล้องในโครงการขนาดใหญ่ ถ้าฉันจะตั้งมาตรฐานที่คนส่วนใหญ่จะคุ้นเคยกับ? มาตรฐานดั้งเดิมคืออะไร?

126 coding-style  naming  variables 

มีใครคิดบ้างไหมว่าทำไมเราหลายคนจึงทำซ้ำรูปแบบเดียวกันนี้โดยใช้ชื่อตัวแปรเดียวกัน for (int i = 0; i < foo; i++) { // ... } ดูเหมือนว่ารหัสที่สุดที่ผมเคยมองที่เคยใช้i, j, kและอื่น ๆ เป็นตัวแปรซ้ำ ฉันคิดว่าฉันเลือกมันมาจากที่ไหนสักแห่ง แต่ฉันสงสัยว่าทำไมสิ่งนี้ถึงแพร่หลายมากในการพัฒนาซอฟต์แวร์ มันเป็นสิ่งที่เราทุกคนหยิบขึ้นมาจาก C หรืออะไรทำนองนั้น? แค่คันที่ฉันมีอยู่พักหนึ่งที่หลังศีรษะ

126 programming-practices  coding-style  coding-standards 

ในการเขียนโปรแกรมเชิงวัตถุแน่นอนว่าไม่มีกฎที่แน่นอนเกี่ยวกับความยาวสูงสุดของวิธีการ แต่ฉันก็ยังพบว่าคำพูดสองคำนี้ขัดแย้งกันดังนั้นฉันอยากได้ยินสิ่งที่คุณคิด ในรหัสที่สะอาด: คู่มือของงานฝีมือซอฟต์แวร์เปรียว Robert Martin กล่าวว่า: กฎข้อแรกของฟังก์ชั่นคือมันควรมีขนาดเล็ก กฎข้อที่สองของฟังก์ชั่นคือควรมีขนาดเล็กกว่านั้น ฟังก์ชั่นไม่ควรยาว 100 บรรทัด ฟังก์ชั่นแทบจะไม่เคยมีความยาว 20 บรรทัด และเขายกตัวอย่างจากโค้ด Java ที่เขาเห็นจาก Kent Beck: ทุกฟังก์ชั่นในโปรแกรมของเขามีความยาวเพียงสองหรือสามหรือสี่บรรทัด แต่ละคนเห็นได้อย่างชัดเจน แต่ละคนเล่าเรื่อง และแต่ละคนก็นำคุณไปสู่ลำดับต่อไปที่น่าสนใจ นั่นเป็นสิ่งที่ฟังก์ชั่นของคุณควรสั้นลง! สิ่งนี้ฟังดูยอดเยี่ยม แต่ในทางกลับกันในCode Complete Steve McConnell พูดอะไรบางอย่างที่แตกต่างกันมาก: รูทีนควรได้รับอนุญาตให้เติบโตอย่างเป็นธรรมชาติถึง 100-200 บรรทัดหลักฐานหลายทศวรรษบอกว่ากิจวัตรที่มีความยาวดังกล่าวไม่มีข้อผิดพลาดเกิดขึ้นได้ง่าย และเขาให้การอ้างอิงถึงการศึกษาที่ระบุว่ากิจวัตร 65 บรรทัดหรือยาวกว่านั้นถูกกว่าเพื่อพัฒนา ดังนั้นในขณะที่มีการแยกความคิดเห็นเกี่ยวกับเรื่องนี้มีวิธีปฏิบัติที่ดีที่สุดสำหรับคุณหรือไม่?

123 design  object-oriented  coding-style