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

มันเป็นสไตล์ที่ดีหรือไม่ที่จะใช้ตัวแปรท้องถิ่นที่เพิ่มเติมและไม่จำเป็นทางเทคนิคเพื่ออธิบายว่าเกิดอะไรขึ้น? ตัวอย่างเช่น: bool easyUnderstandableIsTrue = (/* rather cryptic boolean expessions */); if(easyUnderstandableIsTrue) { // ... } เมื่อพูดถึงค่าโสหุ้ยทางเทคนิคฉันคาดว่าคอมไพเลอร์จะปรับแต่งบรรทัดเพิ่มนอกจากนี้ แต่มันถือว่าเป็นรหัสที่ไม่จำเป็นออกบวม? ในสายตาของฉันมันช่วยลดความเสี่ยงของความคิดเห็นเก่า

12 coding-style  comments 

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

12 c++  coding-style  coding-standards  out-parameters 

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

12 object-oriented  code-smell  coding-style 

เมื่อเร็ว ๆ นี้ฉันชอบทำแผนที่ความสัมพันธ์ 1-1 โดยใช้คำสั่งDictionariesแทน Switchฉันคิดว่ามันจะเร็วขึ้นเล็กน้อยในการเขียนและง่ายต่อการประมวลผลทางจิตใจ น่าเสียดายที่เมื่อทำการแมปกับอินสแตนซ์ใหม่ของวัตถุฉันไม่ต้องการกำหนดเช่นนี้: var fooDict = new Dictionary<int, IBigObject>() { { 0, new Foo() }, // Creates an instance of Foo { 1, new Bar() }, // Creates an instance of Bar { 2, new Baz() } // Creates an instance of Baz } var quux …

12 c#  coding-style 

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

12 self-improvement  productivity  coding-style 

มันเป็นโดยทั่วไปถือว่าการปฏิบัติที่ดีที่จะใช้สัญกรณ์ฮังการีแต่เป็นเรื่องธรรมดาที่จะหาการควบคุม GUI ชื่อและuserNameTextBoxuserNameLabel คุณใส่ประเภทการควบคุมลงในชื่อหรือไม่ นี่เป็นสัญกรณ์ฮังการีไม่ใช่หรือ

12 language-agnostic  coding-style  gui  notation 

คุณจะจัดการกับวิวัฒนาการในคู่มือการเข้ารหัส / สไตล์ในโครงการสำหรับฐานรหัสที่มีอยู่ได้อย่างไร สมมติว่ามีบางคนในทีมของคุณค้นพบวิธีที่ดีกว่าในการสร้างอินสแตนซ์ของวัตถุในภาษาโปรแกรม ไม่ใช่ว่าวิธีการแบบเก่าจะไม่ดีหรือบั๊กกี้ แต่เป็นวิธีการใหม่ที่ให้ความรู้สึกที่น้อยกว่าและให้ความรู้สึกหรูหรามากกว่า และสมาชิกในทีมทุกคนชอบมันมาก คุณจะเปลี่ยนรหัสที่มีอยู่ทั้งหมดหรือไม่ สมมติว่า codebase ของคุณมีโค้ดประมาณ 500,000 บรรทัด คุณยังต้องการเปลี่ยนรหัสที่มีอยู่ทั้งหมดหรือไม่? หรือคุณจะให้รหัสใหม่เป็นไปตามมาตรฐานใหม่เท่านั้น? โดยทั่วไปสูญเสียความมั่นคง? คุณจะจัดการกับวิวัฒนาการในมาตรฐานการเข้ารหัสในโครงการของคุณได้อย่างไร

12 coding-standards  coding-style  maintenance 

ในอดีตฉันมักจะทำการจัดการวัตถุส่วนใหญ่ด้วยวิธีการหลักที่กำลังสร้าง / อัปเดต แต่ฉันพบว่าตัวเองกำลังใช้วิธีการที่แตกต่างกันเมื่อเร็ว ๆ นี้และฉันอยากรู้ว่ามันเป็นการปฏิบัติที่ไม่ดีหรือไม่ นี่คือตัวอย่าง สมมติว่าฉันมีพื้นที่เก็บข้อมูลที่ยอมรับUserเอนทิตี แต่ก่อนที่จะแทรกเอนทิตีเราเรียกวิธีการบางอย่างเพื่อให้แน่ใจว่าฟิลด์ทั้งหมดตั้งค่าเป็นสิ่งที่เราต้องการ ตอนนี้แทนที่จะเรียกวิธีการและตั้งค่าเขตข้อมูลจากภายในวิธีการแทรกฉันเรียกชุดวิธีการเตรียมที่รูปร่างวัตถุก่อนที่จะแทรก วิธีเก่า: public void InsertUser(User user) { user.Username = GenerateUsername(user); user.Password = GeneratePassword(user); context.Users.Add(user); } วิธีการใหม่: public void InsertUser(User user) { SetUsername(user); SetPassword(user); context.Users.Add(user); } private void SetUsername(User user) { var username = "random business logic"; user.Username = username; } private …

12 c#  design  coding-style 

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

12 coding-style  naming  golang 

ใน JavaScript, PL / SQL และภาษาอื่น ๆ บางฟังก์ชั่นสามารถซ้อนกันเช่นประกาศในฟังก์ชั่นอื่น สิ่งนี้สามารถใช้เพื่อแบ่งฟังก์ชั่นขนาดใหญ่ออกเป็นชิ้นเล็ก ๆ แต่เก็บชิ้นส่วนเหล่านั้นไว้ในบริบทของฟังก์ชั่นที่ใหญ่กว่า function doTooMuch() { function doSomething () { ... } function doSomethingElse() { ... } function doYetAnotherThing() { ... } // doTooMuch body doSomething(); doSomethingElse(); doYetAnotherThing(); } ในบางกรณีเมื่อฟังก์ชั่นขนาดเล็กเหล่านั้นไม่ได้ใช้ตัวแปรท้องถิ่นของฟังก์ชั่นขนาดใหญ่สิ่งนี้สามารถเปลี่ยนเป็นเวอร์ชั่นที่ฟังก์ชั่นทั้งหมดไม่ถูกรบกวนได้ง่าย function doSomething () { ... } function doSomethingElse() { ... } function …

12 javascript  coding-style 

ฉันเห็นรูปแบบรหัสต่อไปนี้ทั่วทุกแห่งใน codebase ของ บริษัท ของฉัน (แอปพลิเคชัน. NET 3.5): bool Foo(int barID, out Baz bazObject) { try { // do stuff bazObject = someResponseObject; return true; } catch (Exception ex) { // log error return false; } } // calling code BazObject baz = new BazObject(); fooObject.Foo(barID, out baz); if (baz …

12 c#  code-quality  coding-style 

โดยทั่วไปฉันต้องดำเนินการกระทำที่แตกต่างกันตามเงื่อนไขที่แน่นอน รหัสที่มีอยู่ถูกเขียนด้วยวิธีนี้ อินเตอร์เฟสพื้นฐาน // DoSomething.java interface DoSomething { void letDoIt(String info); } การใช้งานของพนักงานระดับแรก class DoItThisWay implements DoSomething { ... } การใช้งานของคลาสคนงานที่สอง class DoItThatWay implements DoSomething { ... } ชั้นหลัก class Main { public doingIt(String info) { DoSomething worker; if (info == 'this') { worker = new DoItThisWay(); } else { …

11 java  coding-style 

ตัวอย่างเช่นฟังก์ชั่นต่อไปนี้ลูปผ่านอาร์เรย์ซึ่งมีชื่อและข้อผิดพลาดของช่องใส่ มันเป็นเช่นนี้โดยการตรวจสอบชื่อของเขตข้อมูลที่ตรวจสอบแล้วผลักดันข้อมูลข้อผิดพลาดไปยังอาร์เรย์ฟิลด์ที่ไม่ถูกต้อง ดีกว่าที่จะเป็นบทสรุปและเขียนนี้: addInvalidField (field, message) { const foundField = this.invalidFields.find(value => { return value.name === field.name }) const errors = foundField.errors if (!errors.some(error => error.name === message)) { errors.push({ name: message, message }) } }, หรือเฉพาะเจาะจงมากขึ้นเช่นนี้? addInvalidField (validatingField, message) { const foundField = this.invalidFields.find(invalidField => { return validatingField.name === …

11 coding-style  naming 

ฉันใหม่กับทับทิมและฉันรู้สึกประหลาดใจเมื่อฉันพบว่าวัตถุทั้งหมดเป็นจริงนอกเหนือจากศูนย์และเท็จ แม้แต่ 0 ก็จริง สิ่งที่ดีเกี่ยวกับคุณสมบัติของภาษานั้นคือคุณสามารถเขียน: if !variable # do stuff when variable is nil end เพื่อนร่วมงานของฉันซึ่งเป็นนักพัฒนาทับทิมรุ่นเก๋ามากขึ้นยืนยันว่าฉันควรเลือกสิ่งนั้นแทนที่จะใช้. ชอบมาก: if variable.nil? # do stuff when variable is nil end อย่างไรก็ตามฉันเชื่อว่าอันหลังเป็นตัวเลือกที่ดีกว่าด้วยเหตุผลสองประการ: 1. ฉันคิดว่ามันเป็นเชิงวัตถุมากกว่าโดยเฉพาะในภาษาอย่าง Ruby ซึ่งทุกอย่างเป็นการแลกเปลี่ยนวัตถุและข้อความ 2. มันสามารถอ่านได้มากขึ้นในความเห็นของฉันแม้ว่าจะมีขนาดเล็กลงก็ตาม ฉันกำลังทำผิดพลาด "มือใหม่" ที่นี่?

11 coding-style  ruby  null 

วิธีการส่วนตัวควรใช้เส้นทางสาธารณะในการเข้าถึงข้อมูลส่วนตัวเมื่อใด ตัวอย่างเช่นถ้าฉันมีคลาส 'ตัวทวีคูณ' ที่ไม่เปลี่ยนรูปแบบ (มีการประดิษฐ์มาบ้างฉันรู้): class Multiplier { public: Multiplier(int a, int b) : a(a), b(b) { } int getA() const { return a; } int getB() const { return b; } int getProduct() const { /* ??? */ } private: int a, b; }; มีสองวิธีที่ฉันสามารถใช้getProduct: int getProduct() const { …

11 programming-practices  coding-style  access-control