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

ฉันกำลังดูแนวทางการเข้ารหัสของ AvSolสำหรับ C # และฉันเห็นด้วยกับเกือบทุกอย่าง แต่ฉันอยากรู้จริง ๆ ว่าคนอื่นคิดอย่างไรกับกฎข้อหนึ่ง AV1500 วิธีการไม่ควรเกิน 7 ข้อความวิธีที่ต้องใช้มากกว่า 7 ข้อความกำลังทำมากเกินไปหรือมีความรับผิดชอบมากเกินไป นอกจากนี้ยังต้องใช้ความคิดของมนุษย์ในการวิเคราะห์งบที่แน่นอนเพื่อให้เข้าใจว่ารหัสกำลังทำอะไรอยู่ ทำลายมันลงในวิธีการเล็ก ๆ และเน้นด้วยชื่ออธิบายตนเอง คุณส่วนใหญ่ปฏิบัติตามกฎนี้หรือไม่? แม้ว่าจะมีน้อยที่จะถูกบันทึกจากการสร้างวิธีการใหม่ (รหัสของคุณยังคงแห้ง ) นอกเหนือจากการอ่านที่เพิ่มขึ้นอย่างมาก? และหมายเลขของคุณยังต่ำอยู่ที่ 7 หรือไม่ ฉันจะมีแนวโน้มมากขึ้นต่อ 10 ฉันไม่ได้บอกว่าฉันละเมิดกฎนี้ทั่วทุกที่ - ในทางตรงกันข้ามวิธีการของฉันเล็ก 95% และเน้น แต่บอกว่าคุณไม่ควรละเมิดกฎนี้จริงๆพัดฉันออกไป ฉันแค่อยากจะรู้ว่าสิ่งที่ทุกคนคิดว่าไม่เคยละเมิดกฎนี้ (มัน '1' ในมาตรฐานการเข้ารหัส - ความหมายไม่เคยทำเช่นนี้) แต่ฉันคิดว่าคุณมีปัญหาในการค้นหา codebase ที่ไม่ได้

78 c#  coding-standards  maintainability 

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

77 coding-standards  coding-style 

ฉันรู้สึกว่าระบบควบคุมเวอร์ชันขจัดความจำเป็นที่จะต้อง "บันทึกการเปลี่ยนแปลง" ถูกฉาบทุกที่ในรหัส ฉันมักจะเห็นการใช้งานอย่างต่อเนื่องของบันทึกการเปลี่ยนแปลงรวมถึงบล็อกยาวขนาดใหญ่ที่จุดเริ่มต้นของขั้นตอนการจัดเก็บที่มีส่วนใหญ่ถูกบล็อกออกสำหรับการเปลี่ยนแปลงในไฟล์และทิ้งรหัสด้วยสิ่งต่าง ๆ เช่น: // 2011-06-14 (John Smith) Change XYZ to ABC to fix Bug #999 และ: // 2009-95-12 (Bob Jones) Extracted this code to Class Foo // <commented-out code here> เหตุผลสำหรับสิ่งนี้ตามที่อธิบายให้ฉันคือการใช้เวลานานเกินไปในการตรวจสอบบันทึก VCS ของเราพยายามค้นหาว่าใครเปลี่ยนอะไรและเพราะอะไรในขณะที่เก็บไว้ในไฟล์รหัสตัวเองไม่ว่าจะอยู่ด้านบนสุดหรือใกล้เคียง การเปลี่ยนแปลงทำให้ง่ายต่อการดูว่าใครเปลี่ยนอะไรและเมื่อไหร่ ในขณะที่ฉันเห็นประเด็นนั้นดูเหมือนว่าจะซ้ำซ้อนและเป็นเพียงแค่ของเล็ก ๆ น้อย ๆ "เอ๋เราไม่เข้าใจวิธีการใช้ VCS ของเราอย่างถูกต้องดังนั้นเราจะไม่สนใจสิ่งนั้นเลย" คุณคิดอย่างไร? คุณใช้ทั้งความคิดเห็นและบันทึกหรือไม่ แค่บันทึก คุณพบว่าการโค้ดง่ายขึ้นเมื่อคุณเห็นโค้ดบล็อกข้างต้นที่ John Smith …

75 version-control  coding-standards  maintenance 

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

73 naming  interfaces  coding-standards 

คนทั่วไปหมายถึงอะไรเมื่อใดก็ตามที่คุณเห็นXXXในความคิดเห็น บางครั้งฉันจะเห็นความคิดเห็นเช่นนี้: # XXX - This widget really should frobulate the whatsit แน่นอนฉันสามารถบอกได้ว่าความคิดเห็นนั้นหมายถึงอะไร แต่ XXX โดยทั่วไปหมายถึงอะไร มันพูดว่า "นี่คือแฮ็ค" หรืออาจ "เราควรกลับมาทบทวนอีกครั้งในภายหลัง"? หรือมันจะพูดอย่างอื่นอย่างสิ้นเชิง?

72 comments  coding-standards 

มาตรฐานการเข้ารหัสที่มีอยู่ในโครงการ C # ขนาดใหญ่มีกฎที่ชื่อประเภททั้งหมดมีคุณสมบัติครบถ้วนโดยห้ามใช้คำสั่ง 'การใช้' ดังนั้นแทนที่จะคุ้นเคย: using System.Collections.Generic; .... other stuff .... List<string> myList = new List<string>(); (อาจไม่แปลกใจที่varห้ามใช้เช่นกัน) ท้ายที่สุดฉัน: System.Collections.Generic.List<string> myList = new System.Collections.Generic.List<string>(); นั่นคือการเพิ่มขึ้นของการพิมพ์ 134% โดยไม่มีการเพิ่มที่ให้ข้อมูลที่เป็นประโยชน์ ในมุมมองของฉันการเพิ่มขึ้น 100% คือเสียง (ความยุ่งเหยิง) ที่ขัดขวางการทำความเข้าใจ ในการเขียนโปรแกรมกว่า 30 ปีฉันได้เห็นมาตรฐานที่เสนอหนึ่งครั้งหรือสองครั้ง แต่ไม่เคยนำมาใช้ เหตุผลเบื้องหลังมันหนีฉันไป คนที่กำหนดมาตรฐานไม่ใช่คนโง่และฉันไม่คิดว่าเขาเป็นอันตราย ซึ่งทำให้เข้าใจผิดว่าเป็นทางเลือกอื่นเท่านั้นเว้นแต่ฉันจะพลาดบางสิ่งบางอย่าง คุณเคยได้ยินเกี่ยวกับมาตรฐานดังกล่าวหรือไม่? ถ้าเป็นเช่นนั้นอะไรคือเหตุผลที่อยู่เบื้องหลัง คุณนึกถึงข้อโต้แย้งอื่น ๆ ที่ไม่ใช่ "มันโง่" หรือ "คนอื่นทุกคนusing" ซึ่งอาจโน้มน้าวให้บุคคลนี้ลบข้อห้ามนี้ได้หรือไม่? เหตุผล เหตุผลในการห้ามนี้คือ: …

71 c#  coding-standards 

ในงานใหม่ฉันได้รับการตั้งค่าสถานะในการตรวจสอบรหัสสำหรับรหัสเช่นนี้: PowerManager::PowerManager(IMsgSender* msgSender) : msgSender_(msgSender) { } void PowerManager::SignalShutdown() { msgSender_->sendMsg("shutdown()"); } ฉันบอกว่าวิธีสุดท้ายควรอ่าน: void PowerManager::SignalShutdown() { if (msgSender_) { msgSender_->sendMsg("shutdown()"); } } นั่นคือฉันจะต้องใส่NULLยามรอบmsgSender_ตัวแปรแม้ว่ามันจะเป็นข้อมูลส่วนตัว มันยากสำหรับฉันที่จะควบคุมตัวเองจากการใช้คำไม่สุภาพเพื่ออธิบายว่าฉันรู้สึกอย่างไรกับ 'ปัญญา' ชิ้นนี้ เมื่อฉันขอคำอธิบายฉันได้รับเรื่องราวสยองขวัญเกี่ยวกับวิธีการเขียนโปรแกรมจูเนียร์บางปีสับสนว่าชั้นเรียนควรจะทำงานอย่างไรและลบสมาชิกที่เขาไม่ควรมี (โดยไม่ตั้งใจ) และNULLหลังจากนั้น เห็นได้ชัด) และสิ่งที่พัดขึ้นในด้านขวาหลังจากการเปิดตัวผลิตภัณฑ์และเราได้ "เรียนรู้วิธีที่ยากไว้วางใจเรา" ว่ามันจะดีกว่าที่จะเพียงแค่NULLตรวจสอบทุกอย่าง สำหรับฉันแล้วมันให้ความรู้สึกเหมือนการเขียนโปรแกรมลัทธิคาร์โก้ง่ายและเรียบง่าย เพื่อนร่วมงานที่มีความหมายดีบางคนพยายามอย่างจริงจังที่จะช่วยฉัน 'เข้าใจ' และดูว่าสิ่งนี้จะช่วยให้ฉันเขียนรหัสที่มีประสิทธิภาพมากขึ้นได้อย่างไร แต่ ... ฉันไม่สามารถรู้สึกเหมือนพวกเขาเป็นคนที่ไม่ได้รับมัน . มันสมเหตุสมผลสำหรับมาตรฐานการเข้ารหัสที่ต้องการให้ทุกตัวชี้เดียวที่ถูกอ้างถึงในฟังก์ชั่นถูกตรวจสอบNULLก่อน - แม้แต่สมาชิกข้อมูลส่วนตัว? (หมายเหตุ: เพื่อให้เป็นไปตามบริบทเราได้จัดทำอุปกรณ์อิเล็กทรอนิกส์สำหรับผู้บริโภคไม่ใช่ระบบควบคุมการจราจรทางอากาศหรือผลิตภัณฑ์ 'ความล้มเหลวเท่ากับคนตาย') แก้ไข : ในตัวอย่างข้างต้นผู้msgSender_ทำงานร่วมกันไม่จำเป็น …

65 c++  coding-standards 

เครื่องหมายบวก+จะใช้สำหรับการเพิ่มและสำหรับการต่อสายอักขระ แต่สหายของมัน: เครื่องหมายลบ-, โดยทั่วไปจะไม่เห็นการตัดแต่งสตริงหรือกรณีอื่นนอกเหนือจากการลบ อะไรคือเหตุผลหรือข้อ จำกัด สำหรับสิ่งนั้น พิจารณาตัวอย่างต่อไปนี้ใน JavaScript: var a = "abcdefg"; var b = "efg"; a-b == NaN // but a+b == "abcdefgefg"

64 coding-standards  history  operators  overload 

เคยมีเหตุผลที่ดีมากในการรักษาชื่อคำสั่ง / ทะเบียนย่อ เหตุผลเหล่านั้นใช้ไม่ได้อีกต่อไป แต่ชื่อรหัสลับสั้น ๆ ยังคงพบได้บ่อยในการเขียนโปรแกรมระดับต่ำ ทำไมนี้ มันเป็นเพราะนิสัยเก่านั้นยากที่จะทำลายหรือมีเหตุผลที่ดีกว่า? ตัวอย่างเช่น: Atmel ATMEGA32U2 (2010?): TIFR1(แทนTimerCounter1InterruptFlag), ICR1H(แทนInputCapture1High), DDRB(แทนDataDirectionPortB), ฯลฯ ชุดคำสั่ง. NET CLR (2002): bge.s(แทนbranch-if-greater-or-equal.short) ฯลฯ ชื่อที่ไม่ได้เป็นความลับใช้งานได้นานกว่าหรือไม่ เมื่อตอบและลงคะแนนโปรดพิจารณาสิ่งต่อไปนี้ คำอธิบายที่เป็นไปได้หลายข้อเสนอแนะที่นี่นำไปใช้อย่างเท่าเทียมกันกับการเขียนโปรแกรมระดับสูงและยังเป็นฉันทามติโดยและขนาดใหญ่คือการใช้ชื่อที่ไม่เป็นความลับประกอบด้วยคำหรือสอง (คำย่อเข้าใจกันโดยทั่วไป) นอกจากนี้หากข้อโต้แย้งหลักของคุณเกี่ยวกับพื้นที่ทางกายภาพในแผนภาพกระดาษโปรดพิจารณาว่าสิ่งนี้ไม่สามารถใช้ได้กับภาษาแอสเซมบลีหรือ CIL อย่างแน่นอนและฉันจะขอบคุณถ้าคุณแสดงแผนภาพที่ชื่อ terse พอดี แต่คนอ่านทำให้แผนภาพแย่ลง . จากประสบการณ์ส่วนตัวที่ บริษัท เซมิคอนดักเตอร์ fabless ชื่อที่อ่านได้พอดีใช้ได้ดีและทำให้ไดอะแกรมอ่านง่ายขึ้น อะไรคือสิ่งที่สำคัญที่แตกต่างเกี่ยวกับการเขียนโปรแกรมระดับต่ำเมื่อเทียบกับภาษาระดับสูงที่ทำให้ชื่อที่เป็นความลับสั้น ๆ เป็นที่ต้องการในการเขียนโปรแกรมระดับต่ำ แต่ไม่ใช่การเขียนโปรแกรมระดับสูง

64 naming  coding-standards  low-level 

ฉันเพิ่งพบว่าตัวเองกำลังเขียนความคิดเห็นต่อไปนี้ในบางรหัส (archaic Visual Basic 6.0) รหัสที่ฉันเขียน: If WindowState <> 1 Then 'The form's not minimized, so we can resize it safely '... End if ฉันไม่แน่ใจว่าทำไมฉันจึงใช้ "เรา" โดยไม่รู้ตัวในความคิดเห็นของฉัน ฉันสงสัยว่าเป็นเพราะฉันจินตนาการว่ามีคนก้าวเข้ามาในรหัสราวกับว่าพวกเขากำลัง "ทำ" คำสั่งทั้งหมดในแต่ละบรรทัดมากกว่าที่จะเห็นพวกเขาเกิดขึ้น ด้วยความคิดนี้ฉันสามารถใช้I can resize itเพราะฉันเป็นคนหนึ่งที่ "กำลังทำ" อยู่ในขณะนี้หรือyou can resize itราวกับว่าฉันกำลังพูดกับใครก็ตามคือ "ทำ" มันในอนาคต แต่เนื่องจากทั้งสองกรณีนี้มีแนวโน้มมากที่สุด เกิดขึ้นฉันใช้ "เรา" ราวกับว่าฉันกำลังนำใครบางคนผ่านรหัสของฉัน ฉันสามารถเขียนใหม่เป็นit can be resizedและหลีกเลี่ยงปัญหา แต่มันจุดประกายความอยากรู้ของฉัน: …

63 comments  coding-standards 

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

60 architecture  coding-style  coding-standards  coding  maintenance 

เมื่อเร็ว ๆ นี้ฉันได้ทำงานกับ PHP มากและโดยเฉพาะภายในกรอบ WordPress ฉันสังเกตเห็นรหัสจำนวนมากในรูปแบบของ: if ( 1 == $options['postlink'] ) ที่ฉันคาดว่าจะเห็น: if ( $options['postlink'] == 1 ) นี่เป็นข้อตกลงที่พบในบางภาษา / กรอบงานหรือไม่? มีเหตุผลใดที่แนวทางก่อนหน้านี้เป็นที่นิยมกว่าในภายหลัง (จากมุมมองการประมวลผลหรือมุมมองการแยกวิเคราะห์หรือแม้แต่มุมมองของมนุษย์?) หรือมันเป็นเพียงเรื่องของการลิ้มรส? ฉันมักจะคิดว่ามันจะดีกว่าเมื่อทำการทดสอบว่ารายการตัวแปรที่ทดสอบกับค่าคงที่อยู่ทางซ้าย ดูเหมือนว่าแผนที่ดีกว่าวิธีที่เราจะถามคำถามในภาษาธรรมชาติ: "ถ้าเค้กช็อคโกแลต" มากกว่า "ถ้าช็อคโกแลตเป็นเค้ก"

48 coding-style  coding-standards  conditions  defensive-programming 

ฉันกำลังอ่านหัวข้ออื่นที่ชายคนหนึ่งถามเกี่ยวกับหนังสือ C ++ สำหรับผู้เริ่มต้นและหนึ่งในโปรแกรมเมอร์ที่ตอบรับเขียนสิ่งนี้: คำเตือนบางอย่าง: หลีกเลี่ยงหนังสือทุกเล่มที่มีคำว่า "สวัสดีโลก" ที่ระบุ #include <iostream.h> ฉันเปิดหนังสือ C ++ ของฉันและได้รวมส่วนหัว iostream อย่างที่แสดงไว้ด้านบน เหตุใดจึงไม่ดี คำแนะนำอื่น ๆ ที่ฉันควรทราบเมื่อเรียนรู้ C ++ คืออะไร พื้นหลัง: ฉันมีความเชี่ยวชาญใน C และฉันจะเริ่มเรียนรู้ C ++ ภาคการศึกษาถัดไปนี้

47 c++  coding-style  code-quality  coding-standards  headers 

ฉันเห็นคำถามที่คล้ายกับเรื่องนี้เกี่ยวกับชื่อพารามิเตอร์ที่ตรงกับคุณสมบัติในคลาส แต่ฉันไม่พบสิ่งใดเกี่ยวกับการใช้ชื่อพารามิเตอร์ที่เหมือนกับชื่อประเภทพารามิเตอร์ยกเว้นการใส่ใน C # ดูเหมือนจะไม่เป็นการละเมิดที่ฉันสามารถหาได้ แต่มันถือว่าเป็นการปฏิบัติที่ไม่ดี ตัวอย่างเช่นฉันมีวิธีการดังต่อไปนี้ public Range PadRange(Range range) {} วิธีนี้ใช้ช่วงและส่งกลับช่วงใหม่ที่มีการเติมเต็มบางส่วน ดังนั้นด้วยบริบททั่วไปฉันไม่สามารถนึกถึงชื่อที่อธิบายเพิ่มเติมสำหรับพารามิเตอร์ได้ อย่างไรก็ตามฉันระลึกถึงปลายที่ฉันหยิบขึ้นมาเมื่ออ่านรหัสสมบูรณ์เกี่ยวกับ "ระยะทางทางจิตวิทยา" มันบอกว่า ระยะทางทางจิตวิทยาสามารถกำหนดได้ว่าเป็นความง่ายในการแยกความแตกต่างของสองรายการ ... เมื่อคุณดีบั๊กให้พร้อมสำหรับปัญหาที่เกิดจากระยะห่างทางจิตใจไม่เพียงพอระหว่างชื่อตัวแปรที่คล้ายกันและระหว่างชื่อรูทีนที่คล้ายกัน ในขณะที่คุณสร้างรหัสให้เลือกชื่อที่มีความแตกต่างมากเพื่อให้คุณสามารถหลีกเลี่ยงปัญหาได้ ลายเซ็นวิธีการของฉันมี "ช่วง" มากมายเกิดขึ้นดังนั้นจึงรู้สึกว่ามันอาจเป็นปัญหาเกี่ยวกับระยะห่างทางจิตวิทยานี้ ตอนนี้ฉันเห็นนักพัฒนาหลายคนทำต่อไปนี้ public Range PadRange(Range myRange) {} โดยส่วนตัวฉันมีความไม่พอใจที่แข็งแกร่งสำหรับการประชุมครั้งนี้ การเพิ่มคำนำหน้า "ของฉัน" ไปยังชื่อตัวแปรไม่มีบริบทเพิ่มเติม ฉันยังเห็นดังต่อไปนี้ public Range PadRange(Range rangeToPad) {} ฉันชอบสิ่งนี้ดีกว่าส่วนนำหน้า "ของฉัน" แต่ก็ยังไม่สนใจโดยรวม มันรู้สึก verbose มากเกินไปสำหรับฉันและอ่านอย่างเชื่องช้าเป็นชื่อตัวแปร สำหรับฉันมันเป็นที่เข้าใจกันดีว่าช่วงนั้นจะถูกเพิ่มเนื่องจากชื่อเมธอด ดังนั้นเมื่อทั้งหมดนี้ออกมาอุทรของฉันคือการได้ไปกับลายเซ็นแรก สำหรับฉันมันสะอาด ไม่จำเป็นต้องบังคับบริบทเมื่อไม่จำเป็น …

43 coding-standards  methods  parameters 

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

43 programming-practices  coding-standards