คำถามติดแท็ก code-smell

ฉันพบว่าตัวเองมักจะค้นหาคำถามออนไลน์และวิธีแก้ปัญหาหลายอย่างรวมถึงพจนานุกรม อย่างไรก็ตามเมื่อใดก็ตามที่ฉันพยายามที่จะใช้พวกเขาฉันได้กลิ่นที่น่ากลัวนี้ในรหัสของฉัน เช่นทุกครั้งที่ฉันต้องการใช้ค่า: int x; if (dict.TryGetValue("key", out x)) { DoSomethingWith(x); } นั่นคือโค้ด 4 บรรทัดที่จะทำสิ่งต่อไปนี้: DoSomethingWith(dict["key"]) ฉันได้ยินมาว่าการใช้คีย์เวิร์ด out เป็นรูปแบบการต่อต้านเพราะทำให้ฟังก์ชั่นกลายพันธุ์พารามิเตอร์ของพวกเขา นอกจากนี้ฉันพบว่าตัวเองมักต้องการพจนานุกรม "กลับด้าน" ที่ฉันพลิกคีย์และค่าต่างๆ ในทำนองเดียวกันฉันมักจะทำซ้ำผ่านรายการในพจนานุกรมและพบว่าตนเองกำลังแปลงคีย์หรือค่าไปยังรายการ ฯลฯ เพื่อทำสิ่งนี้ให้ดีขึ้น ฉันรู้สึกว่ามีวิธีการใช้พจนานุกรมที่ดีกว่าและสง่างามกว่าอยู่เกือบตลอดเวลา แต่ฉันรู้สึกแย่

19 c#  anti-patterns  code-smell  dictionary  out-parameters 

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

19 testing  code-quality  tdd  code-smell  assertions 

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

19 testing  code-quality  tdd  code-smell  dependency-injection 

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

18 data-structures  code-smell 

ฉันอ่านเกี่ยวกับรหัสที่พบบ่อยมีกลิ่นในหนังสือ Refactoring Martin Fowler ของ ในบริบทนั้นฉันสงสัยเกี่ยวกับรูปแบบที่ฉันเห็นในฐานรหัสและไม่มีใครสามารถคิดว่ามันเป็นรูปแบบการต่อต้าน รูปแบบเป็นสิ่งหนึ่งที่วัตถุถูกส่งผ่านเป็นอาร์กิวเมนต์หนึ่งหรือหลายวิธีซึ่งทั้งหมดนี้เปลี่ยนสถานะของวัตถุ แต่ไม่มีใครกลับวัตถุ ดังนั้นจึงขึ้นอยู่กับการส่งผ่านโดยอ้างอิงธรรมชาติของ (ในกรณีนี้) C # /. NET var something = new Thing(); // ... Foo(something); int result = Bar(something, 42); Baz(something); ฉันพบว่า (โดยเฉพาะอย่างยิ่งเมื่อวิธีการไม่ได้ตั้งชื่ออย่างเหมาะสม) ฉันต้องมองหาวิธีการดังกล่าวเพื่อทำความเข้าใจว่าสถานะของวัตถุมีการเปลี่ยนแปลง มันทำให้เข้าใจรหัสมากขึ้นเนื่องจากฉันต้องการติดตาม call-stack หลายระดับ ฉันต้องการเสนอให้ปรับปรุงโค้ดดังกล่าวเพื่อส่งคืนออบเจ็กต์อื่น (โคลน) ด้วยสถานะใหม่หรืออะไรก็ตามที่จำเป็นในการเปลี่ยนออบเจ็กต์ที่ไซต์การโทร var something1 = new Thing(); // ... // Let's return a new instance …

17 code-smell  anti-patterns  parameters 

เรามีชั้นข้อมูลที่ล้อมรอบ Linq กับ SQL ในชุดข้อมูลนี้เรามีวิธีนี้ (แบบง่าย) int InsertReport(Report report) { db.Reports.InsertOnSubmit(report); db.SubmitChanges(); return report.ID; } เมื่อส่งการเปลี่ยนแปลงรหัสรายงานจะได้รับการอัปเดตด้วยค่าในฐานข้อมูลที่เราส่งคืน จากด้านการโทรดูเหมือนว่านี้ (ย่อ) var report = new Report(); DataLayer.InsertReport(report); // Do something with report.ID เมื่อดูที่รหัส ID ได้รับการตั้งค่าภายในฟังก์ชั่น InsertReport ว่าเป็นผลข้างเคียงจากนั้นเราจะเพิกเฉยต่อค่าที่ส่งคืน คำถามของฉันคือฉันควรพึ่งพาผลข้างเคียงและทำสิ่งนี้แทน void InsertReport(Report report) { db.Reports.InsertOnSubmit(report); db.SubmitChanges(); } หรือเราควรป้องกันมัน int InsertReport(Report report) { var newReport = …

17 design  code-quality  code-smell 

ฉันคุ้นเคยกับคำว่า "เป็นอย่างยิ่งคู่" แต่ฉันอยากรู้ว่ามีสัญญาณ (รหัสกลิ่น) ที่สามารถระบุได้ว่าเป็นรหัสคู่ ปัจจุบันฉันทำงานกับ Java EE แต่สิ่งนี้สามารถใช้กับภาษาใดก็ได้ แก้ไข: ในกรณีที่ใครสนใจบทความนี้ฟังดูมีประโยชน์: ในการค้นหาคุณภาพของรหัส: ระวังคู่ที่แน่นหนา! (IBM)

16 architecture  code-smell 

สมมติว่ามีอินเทอร์เฟซ IReader การนำไปใช้ของตัวอ่าน IReader อินเตอร์เฟส ReaderImplementation และคลาส ReaderConsumer ที่ใช้และประมวลผลข้อมูลจากเครื่องอ่าน public interface IReader { object Read() } การดำเนินงาน public class ReaderImplementation { ... public object Read() { ... } } ผู้บริโภค: public class ReaderConsumer() { public string location // constructor public ReaderConsumer() { ... } // read some data public object …

15 mocking  code-smell 

ฉันใช้รหัส (รหัสใหม่) ที่ใช้สิ่งที่ฉันเรียกว่า 'อาร์เรย์แบบขนาน' หรือรายการ ความหมายมี 2 อาร์เรย์ที่มีข้อมูลที่เกี่ยวข้องและเชื่อมโยงโดยตำแหน่ง (ดัชนี) ในอาร์เรย์ ฉันพิจารณาถึงความสับสนและมีแนวโน้มที่จะเกิดข้อผิดพลาดทุกประเภท วิธีแก้ปัญหาที่ฉันเสนอตามปกติคือการสร้างวัตถุที่เรียกว่าCompanyมีฟิลด์ CompanyId และ CompanyName ตัวอย่างจริงมาก: List<string> companyNames; List<int> companyIds; //...They get populated somewhere and we then process for(var i=0; i<companyNames.Count; i++) { UpdateCompanyName(companyIds[i],companyNames[i]); } อาร์เรย์แบบขนานเหล่านี้มีการพิจารณาว่าไม่เหมาะสมหรือไม่

14 object-oriented  programming-practices  code-smell 

ฉันเขียนโปรแกรมมาสองสามปีและคุ้นเคยกับ C # และ JavaScript เมื่อเวลาผ่านไป ฉันมีโครงการ C # และ JavaScript ที่ใหญ่กว่าซึ่งฉันไม่มีปัญหาในการนำทาง ฉันเพิ่งเริ่มต้นโครงการ PHP & AngularJS สำหรับการทำงานที่ไม่มีประสบการณ์มาก่อนด้วย PHP กระแสของสิ่งต่าง ๆ ใน PHP กลายเป็นเรื่องยากที่จะติดตาม (ด้าน JavaScript มีขนาดใหญ่ขึ้น แต่ง่ายต่อการทำงาน) เมื่อฉันลองและคิดในเรื่องนั้นฉันคิดว่าลูกบอลที่พันกันยุ่งเหยิง ข้อผิดพลาดในการออกแบบที่สำคัญที่ฉันทำเมื่อฉันเริ่มจะเริ่มกองพะเนินเทินทึกและมีผลต่อการออกแบบของฉันไปข้างหน้า ใช้เวลานานขึ้นและนานขึ้นในการใช้งานสิ่งใหม่ ฉันอยู่ในกำหนดเส้นตายและพบว่ามันยากและยากที่จะเขียนดี DRY ของแข็งรหัส มันยิ่งดึงดูดให้คัดลอก / วางชิ้นส่วนของรหัสเพื่อสร้างพฤติกรรมที่เปลี่ยนแปลงเล็กน้อยเมื่อเวลาในการออกแบบเพิ่มขึ้น นอกจากนี้ยังใช้เวลานานในการกลับไปที่ฐานรหัสเมื่อใดก็ตามที่ฉันต้องทำการสลับบริบท (จากโครงการหนึ่งจากนั้นกลับสู่โครงการนี้) ฉันมีความรู้สึกกลัวเมื่อใดก็ตามที่ฉันกลับไปทำงานในโครงการนี้ ขั้นตอนใดที่ฉันสามารถแก้ไขได้ เวลาเพิ่มเติมอาจต้องมีความสมเหตุสมผลเช่นกันเจ้านายของฉันไม่ใช่นักพัฒนาและไม่คุ้นเคยกับการพัฒนาหรือวงจรชีวิตของซอฟต์แวร์ดังนั้นการอธิบายอาจยากกว่าปกติ

14 php  javascript  web-applications  code-smell  technical-debt 

ฉันได้รับรหัสฐานซึ่งมีรหัสจำนวนมากที่ไปในลักษณะนี้: SomeDataAdapter sda = new SomeDataAdapter(); sda.UpdateData(DataTable updateData); จากนั้น sda จะไม่ถูกใช้อีกครั้ง เป็นกลิ่นรหัสที่บ่งชี้ว่าวิธีการเหล่านั้นควรเป็นวิธีการเรียนแบบคงที่แทน?

14 code-smell  static-methods 

ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังว่าคำตอบจะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการอภิปรายโต้แย้งโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน7 ปีที่ผ่านมา บางครั้งฉันสร้างคลาส 'Util' ซึ่งส่วนใหญ่ใช้เพื่อเก็บวิธีการและค่านิยมที่ไม่ได้อยู่ในที่อื่น แต่ทุกครั้งที่ฉันสร้างหนึ่งในชั้นเรียนเหล่านี้ฉันคิดว่า "เอ่อ - โอ้ฉันจะเสียใจในภายหลัง ... " เพราะฉันอ่านที่ไหนสักแห่งที่มันไม่ดี แต่ในทางกลับกันดูเหมือนจะมีสองกรณี (อย่างน้อยสำหรับฉัน) ที่น่าสนใจสำหรับพวกเขา: ความลับการนำไปใช้งานที่ใช้ในหลายคลาสภายในแพ็กเกจ นำเสนอฟังก์ชั่นที่มีประโยชน์เพื่อเพิ่มคลาสโดยไม่ทำให้หน้าจอของคุณยุ่ง ฉันกำลังจะไปสู่ความพินาศหรือไม่? คุณพูดอะไร !! ฉันควร refactor หรือไม่

14 design  object-oriented  code-smell 

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

14 code-quality  bug  code-smell 

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

12 object-oriented  code-smell  coding-style 

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

12 performance  exceptions  code-smell  complexity  workaround