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

ดูเหมือนว่าเมื่อเร็ว ๆ นี้จะนิยมตัดเครื่องหมายอัฒภาคออกจาก Javascript มีการโพสต์บล็อกเมื่อไม่กี่ปีที่ผ่านมาโดยเน้นว่าใน Javascript เซมิโคลอนจะเป็นตัวเลือกและส่วนสำคัญของโพสต์นั้นดูเหมือนว่าคุณไม่ควรกังวลเพราะมันไม่จำเป็น โพสต์อ้างอย่างกว้างขวางไม่ได้ให้เหตุผลที่น่าสนใจที่จะไม่ใช้พวกเขาเพียงแค่ที่ปล่อยให้พวกเขาออกมีผลข้างเคียงน้อย แม้แต่GitHub ก็กระโดดขึ้นไปบน bandwagon ที่ไม่มีเครื่องหมายอัฒภาคต้องการการละเว้นในโค้ดที่พัฒนาขึ้นภายในใด ๆ และความมุ่งมั่นล่าสุดในโครงการ zepto.js โดยผู้ดูแลมันได้ลบเครื่องหมายอัฒภาคทั้งหมดจาก codebase เหตุผลหลักของเขาคือ: มันเป็นเรื่องของการตั้งค่าสำหรับทีมของเขา; พิมพ์น้อย มีเหตุผลที่ดีอื่นที่จะปล่อยพวกเขาออกมา? ตรงไปตรงมาฉันไม่เห็นเหตุผลที่จะละเว้นพวกเขาและแน่นอนไม่มีเหตุผลที่จะกลับไปที่รหัสเพื่อลบพวกเขา มันยังขัดกับแนวทางปฏิบัติที่แนะนำ ( หลายปี ) ซึ่งฉันไม่ได้ซื้ออาร์กิวเมนต์ "ลัทธิการขนส่งสินค้า" สำหรับ ดังนั้นทำไมเซมิโคลอนที่เกลียดชังล่าสุดทั้งหมด มีปัญหาการขาดแคลนปรากฏหรือไม่ หรือนี่เป็นเพียง Javascript ล่าสุดเท่านั้น

79 javascript  coding-style 

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

77 coding-standards  coding-style 

เมื่อใดก็ตามที่ฉันต้องการการแบ่งตัวอย่างเช่นการตรวจสอบเงื่อนไขฉันต้องการ refactor การแสดงออกของการหารเป็นการคูณ: รุ่นเดิม: if(newValue / oldValue >= SOME_CONSTANT) เวอร์ชั่นใหม่: if(newValue >= oldValue * SOME_CONSTANT) เพราะฉันคิดว่ามันสามารถหลีกเลี่ยง: การหารด้วยศูนย์ ล้นเมื่อoldValueมีขนาดเล็กมาก นั่นถูกต้องใช่ไหม? มีปัญหาสำหรับนิสัยนี้หรือไม่?

73 coding-style  language-agnostic  math 

if i>0 : return sqrt(i) elif i==0: return 0 else : return 1j * sqrt(-i) VS if i>0: return sqrt(i) elif i==0: return 0 else: return 1j * sqrt(-i) จากตัวอย่างข้างต้นฉันไม่เข้าใจว่าทำไมฉันถึงไม่เคยเห็นสไตล์แรกในฐานรหัส สำหรับฉันคุณเปลี่ยนรหัสเป็นรูปแบบตารางที่แสดงสิ่งที่คุณต้องการอย่างชัดเจน คอลัมน์แรกสามารถถูกละเว้นได้อย่างแท้จริง คอลัมน์ที่สองระบุเงื่อนไขและคอลัมน์ที่สามให้ผลลัพธ์ที่คุณต้องการ อย่างน้อยก็ตรงไปตรงมาและอ่านง่าย แต่ฉันก็มักจะเห็นสถานการณ์กรณี / สวิตช์แบบง่าย ๆ นี้ออกมาในรูปแบบที่เพิ่มการเยื้องของแท็บ ทำไมถึงเป็นอย่างนั้น? ผู้คนพบรูปแบบที่สองที่สามารถอ่านได้มากขึ้นหรือไม่ กรณีเดียวที่ปัญหานี้อาจเกิดขึ้นได้ก็ต่อเมื่อรหัสเปลี่ยนไป ในกรณีนี้ฉันคิดว่ามันเหมาะสมอย่างยิ่งที่จะทำการปรับรหัสให้อยู่ในรูปแบบที่ยาวและเยื้อง ทุกคนทำวิธีที่สองเพียงเพราะวิธีที่เคยทำมาเสมอหรือไม่ การเป็นผู้สนับสนุนของปีศาจฉันคิดว่าอีกเหตุผลหนึ่งอาจเป็นเพราะผู้คนพบสองรูปแบบที่แตกต่างกันขึ้นอยู่กับความซับซ้อนของคำสั่ง if / else ที่ทำให้สับสน? ความเข้าใจใด …

73 coding-style 

ฉันสะดุดกับรายการบล็อกทำให้ไม่สามารถใช้ Strings ใน Java เพราะทำให้โค้ดของคุณขาดความหมายโดยแนะนำว่าคุณควรใช้คลาส wrapper บาง ๆ แทน นี่คือตัวอย่างก่อนและหลังรายการดังกล่าวมีไว้เพื่อแสดงให้เห็นถึงเรื่อง: public void bookTicket( String name, String firstName, String film, int count, String cinema); public void bookTicket( Name name, FirstName firstName, Film film, Count count, Cinema cinema); จากประสบการณ์การอ่านบล็อกการเขียนโปรแกรมฉันได้ข้อสรุปว่า 90% ไร้สาระ แต่ฉันก็ยังสงสัยว่ามันเป็นประเด็นที่ถูกต้องหรือไม่ อย่างใดก็รู้สึกไม่ถูกต้องสำหรับฉัน แต่ฉันไม่สามารถระบุสิ่งที่ผิดปกติกับรูปแบบของการเขียนโปรแกรม

73 java  coding-style  semantics 

เพื่อประโยชน์ในการอ่านฉันมักจะพบว่าตัวเองกำหนดตัวแปรชั่วคราวในขณะที่เรียกฟังก์ชั่นเช่นรหัสต่อไปนี้ var preventUndo = true; doSomething(preventUndo); รุ่นที่สั้นกว่าของสิ่งนี้คือ doSomething(true); แต่เมื่อฉันกลับมาที่รหัสฉันมักจะสงสัยว่าtrueหมายถึงอะไร มีแบบแผนสำหรับปริศนาประเภทนี้หรือไม่?

73 coding-style 

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

68 coding-style  automation 

บ่อยครั้งที่ฉันเห็นคำถามในรายการคำถามเครือข่ายที่น่าสนใจเช่นนี้ซึ่งโดยทั่วไปแล้วถามว่า "ฉันจะวาดรูปทรงโดยพลการใน CSS ได้อย่างไร" คำตอบก็คือบล็อกข้อมูล CSS หรือ SVG สองกลุ่มที่มีค่าฮาร์ดโค้ดแบบสุ่มจำนวนมากซึ่งสร้างรูปร่างตามที่ร้องขอ เมื่อฉันดูที่นี้ฉันคิดว่า 'Yuck! สิ่งที่น่าเกลียดของรหัส ฉันหวังว่าฉันจะไม่เห็นสิ่งประเภทนี้ในโครงการของฉัน ' อย่างไรก็ตามฉันเห็นประเภทของคำถาม & บ่อยครั้งมากและมีผู้ติดตามจำนวนมากดังนั้นชุมชนจึงไม่คิดว่าพวกเขาจะไม่ดี แต่ทำไมถึงเป็นที่ยอมรับ? มาจากประสบการณ์การใช้งานส่วนหลังของฉันสิ่งนี้ไม่สมเหตุสมผลสำหรับฉัน เหตุใดจึงเป็นเช่นนั้นสำหรับ CSS / SVG

63 coding-style  code-quality  css  clean-code  svg 

ฉันมีสามมุมมองในโปรแกรมของฉัน (แอพ iOS) มีเพียงหนึ่งรายการเท่านั้นที่ใช้งานในเวลาเดียวกันดังนั้นฉันจึงปิดการมองเห็นสำหรับพวกเขาสองคนและสลับการมองเห็นเมื่อผู้ใช้กดปุ่ม มุมมองจะเริ่มต้นเป็นมองเห็นได้ดังนั้นฉันตั้งค่าการมองเห็นออกในรหัสก่อนที่จะแสดงมุมมองหลัก ที่ฉันสามารถทำได้ [view1 setAlpha:0.0f]; [view2 setAlpha:0.0f]; สำหรับมุมมองสองมุมมอง แต่ตอนนี้มุมมองที่สาม (มุมมองที่ควรมองเห็นเมื่อเริ่มต้นแอพ) ไม่ได้ถูกระบุ ฉันใส่ [view3 setAlpha:1.0f]; หลังจากสองคนแรกเพราะฉันคิดว่ามันชัดเจนว่ามีสามมุมมองจริงไม่ใช่สองอย่างที่คิดเมื่อเห็นรหัส โปรแกรมเมอร์คนอื่นทำอย่างไร มันเป็นการตั้งค่าอย่างหมดจดหรือมีการประชุมบ้างไหม? หากการโทรนั้นหนักมากมันจะดีกว่าที่จะไม่โทรเมื่อมันไม่จำเป็น แต่ฉันสงสัยเกี่ยวกับสิ่งเล็ก ๆ น้อย ๆ เช่นแบบของฉัน

60 coding-style  clean-code 

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

60 architecture  coding-style  coding-standards  coding  maintenance 

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

59 language-agnostic  coding-style  boolean 

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

59 code-quality  coding-style  variables 

ข้อไหนดีกว่า / ยอมรับโดยทั่วไปมากกว่า นี้: if(condition) { statement; } หรือ: if(condition) statement; ฉันมักจะชอบคนแรกเพราะฉันคิดว่ามันง่ายกว่าที่จะบอกสิ่งที่เป็นจริงในบล็อกถ้ามันช่วยให้ผู้อื่นจากการเพิ่มการจัดฟันในภายหลัง (หรือสร้างข้อผิดพลาดโดยลืม) และทำให้งบของคุณทั้งหมด เครื่องแบบแทนบางคนที่มีวงเล็บปีกกาและบางคนไม่มี อย่างไรก็ตามอันที่สองยังคงถูกต้องตามหลักไวยากรณ์และมีขนาดกะทัดรัดกว่าแน่นอน ฉันอยากรู้ว่าคนอื่นชอบแบบไหนมากกว่ากัน

59 coding-style 

รูปแบบการเข้ารหัสของฉันสำหรับการเรียกใช้ฟังก์ชันที่ซ้อนกันมีดังต่อไปนี้: var result_h1 = H1(b1); var result_h2 = H2(b2); var result_g1 = G1(result_h1, result_h2); var result_g2 = G2(c1); var a = F(result_g1, result_g2); ฉันเพิ่งเปลี่ยนเป็นแผนกที่ใช้รูปแบบการเข้ารหัสต่อไปนี้เป็นอย่างมาก: var a = F(G1(H1(b1), H2(b2)), G2(c1)); ผลของวิธีการเข้ารหัสของฉันคือในกรณีที่ฟังก์ชั่นการขัดข้อง Visual Studio สามารถเปิดการถ่ายโอนข้อมูลที่สอดคล้องกันและระบุบรรทัดที่ปัญหาเกิดขึ้น (ฉันกังวลเป็นพิเศษเกี่ยวกับการละเมิดการเข้าถึง) ฉันกลัวว่าในกรณีที่เกิดความผิดพลาดเนื่องจากปัญหาเดียวกันที่ตั้งโปรแกรมไว้ในวิธีแรกฉันจะไม่สามารถรู้ได้ว่าฟังก์ชันใดที่ทำให้เกิดความผิดพลาด ในทางกลับกันยิ่งการประมวลผลที่คุณใส่ในบรรทัดมากขึ้นเท่าไรคุณก็ยิ่งได้รับตรรกะมากขึ้นในหน้าเดียวซึ่งจะช่วยเพิ่มความสามารถในการอ่าน ความกลัวของฉันถูกต้องหรือฉันขาดอะไรไปและโดยทั่วไปแล้วสิ่งใดที่เป็นที่นิยมในสภาพแวดล้อมเชิงพาณิชย์ อ่านหรือบำรุงรักษา? ฉันไม่รู้ว่ามันเกี่ยวข้องหรือไม่ แต่เรากำลังทำงานใน C ++ (STL) / C #

57 c#  c++  coding-style  readability  maintainability 

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

56 coding-style