คำถามติดแท็ก readability

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

34 code-quality  performance  readability  maintainability 

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

33 java  readability  loops 

พิจารณารหัสต่อไปนี้: public void doSomething(int input) { while(true) { TransformInSomeWay(input); if(ProcessingComplete(input)) break; DoSomethingElseTo(input); } } สมมติว่ากระบวนการนี้เกี่ยวข้องกับขั้นตอนที่ จำกัด แต่ขึ้นอยู่กับอินพุต ลูปได้รับการออกแบบมาเพื่อยุติด้วยตัวเองอันเป็นผลมาจากอัลกอริธึมและไม่ได้ออกแบบให้รันแบบไม่สิ้นสุด (จนกว่าจะถูกยกเลิกโดยเหตุการณ์ภายนอก) เนื่องจากการทดสอบเพื่อดูว่าการวนซ้ำควรจบอยู่กลางชุดตรรกะของขั้นตอนหรือไม่ขณะที่ลูปตัวเองในขณะนี้ไม่ได้ตรวจสอบสิ่งใดที่มีความหมาย การตรวจสอบจะดำเนินการแทนในตำแหน่ง "เหมาะสม" ภายในอัลกอริทึมเชิงแนวคิด ฉันได้รับการบอกว่านี่เป็นโค้ดที่ไม่ดีเพราะมันมีข้อผิดพลาดมากกว่าเนื่องจากสภาพตอนจบไม่ได้ถูกตรวจสอบโดยโครงสร้างลูป เป็นการยากกว่าที่จะทราบว่าคุณจะออกจากลูปอย่างไรและสามารถเชิญบั๊กเนื่องจากสภาพการแตกหักอาจถูกข้ามหรือข้ามไปโดยไม่ตั้งใจเนื่องจากการเปลี่ยนแปลงในอนาคต ตอนนี้รหัสสามารถโครงสร้างดังนี้ public void doSomething(int input) { TransformInSomeWay(input); while(!ProcessingComplete(input)) { DoSomethingElseTo(input); TransformInSomeWay(input); } } อย่างไรก็ตามการทำซ้ำการเรียกไปยังวิธีการในรหัสละเมิด DRY; หากTransformInSomeWayถูกแทนที่ด้วยวิธีอื่นในภายหลังการโทรทั้งสองจะต้องพบและเปลี่ยนแปลง (และความจริงที่ว่ามีสองอาจไม่ชัดเจนในรหัสที่ซับซ้อนมากขึ้น) คุณสามารถเขียนเช่น: public void doSomething(int input) { var complete …

32 programming-practices  language-agnostic  readability 

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

32 code-quality  readability 

นี่เป็นหัวข้อที่ถกเถียงกันอยู่และฉันคิดว่ามีความคิดเห็นมากเท่ากับที่มีโปรแกรมเมอร์ แต่เพื่อประโยชน์ของมันฉันต้องการทราบว่าการปฏิบัติทั่วไปในธุรกิจคืออะไร (หรือในที่ทำงานของคุณ) ในที่ทำงานของฉันเรามีแนวทางการเข้ารหัสที่เข้มงวด ส่วนหนึ่งของนั้นจะทุ่มเทให้กับสายอักขระ / หมายเลข มันระบุ (สำหรับ C #): อย่าใช้ค่าตัวอักษรตัวเลขหรือสตริงในรหัสของคุณนอกเหนือจากการกำหนดค่าคงที่เชิงสัญลักษณ์ ใช้รูปแบบต่อไปนี้เพื่อกำหนดค่าคงที่: public class Whatever { public static readonly Color PapayaWhip = new Color(0xFFEFD5); public const int MaxNumberOfWheels = 18; } มีข้อยกเว้นคือค่า 0, 1 และ null สามารถใช้ได้อย่างปลอดภัยเกือบตลอดเวลา บ่อยครั้งที่ค่า 2 และ -1 ก็โอเคเช่นกัน สตริงที่มีไว้สำหรับการบันทึกหรือการติดตามได้รับการยกเว้นจากกฎนี้ อนุญาตให้ใช้ตัวอักษรเมื่อความหมายชัดเจนจากบริบทและไม่ขึ้นอยู่กับการเปลี่ยนแปลงในอนาคต mean = (a + b) …

31 coding-style  refactoring  coding-standards  readability  maintainability 

ในฐานะส่วนหนึ่งของการเขียน Iterator ฉันพบว่าตัวเองเขียนโค้ดต่อไปนี้ (การจัดการข้อผิดพลาดในการลอก) public T next() { try { return next; } finally { next = fetcher.fetchNext(next); } } พบว่าอ่านง่ายกว่าเล็กน้อย public T next() { T tmp = next; next = fetcher.fetchNext(next); return tmp; } ฉันรู้ว่ามันเป็นตัวอย่างง่ายๆที่ความแตกต่างของความสามารถในการอ่านอาจจะไม่มากนัก แต่ฉันสนใจในความคิดเห็นทั่วไปว่าไม่ดีที่จะลองใช้ในที่สุดในกรณีเช่นนี้ที่ไม่มีข้อยกเว้นที่เกี่ยวข้องหรือ ถ้ามันเป็นที่ต้องการจริง ๆ เมื่อมันลดความซับซ้อนของรหัส ถ้ามันไม่ดี: ทำไม สไตล์ประสิทธิภาพข้อผิดพลาด ... ? บทสรุป ขอบคุณคำตอบทั้งหมดของคุณ! ฉันเดาข้อสรุป (อย่างน้อยสำหรับฉัน) คือตัวอย่างแรกอาจอ่านง่ายกว่าถ้ามันเป็นรูปแบบทั่วไป …

30 java  code-quality  exceptions  readability 

การอ่านซอร์สโค้ดของSQLiteนั้นเป็นไปไม่ได้สำหรับภารกิจ IMO แต่เป็นซอฟต์แวร์ที่มีความซับซ้อนซึ่งสามารถใช้งานได้ (เป็นฐานข้อมูลแบบฝังตัวเต็มรูปแบบ) ซึ่งสามารถดาวน์โหลดรวบรวมและใช้งานจากรหัสอื่น ๆ และมีการปรับปรุงอยู่ตลอดเวลา ผู้คนสามารถเขียนและบำรุงรักษาโค้ดที่ซับซ้อนและอ่านยากได้อย่างไร

27 source-code  maintenance  readability 

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

26 readability  paradigms  data-warehouse  modeling  dependency-analysis 

ฉันได้อ่านแล้วว่าควรหลีกเลี่ยงตัวดำเนินการเพิ่ม postfixเนื่องจากเหตุผลด้านประสิทธิภาพ (ในบางกรณี) แต่สิ่งนี้จะไม่ส่งผลกระทบต่อการอ่านรหัสหรือไม่ ในความเห็นของฉัน: for(int i = 0; i < 42; i++); /* i will never equal 42! */ ดูดีกว่า: for(int i = 0; i < 42; ++i); /* i will never equal 42! */ แต่นี่อาจเป็นเพียงนิสัย เป็นที่ยอมรับฉันไม่ได้เห็นการใช้งาน++iมากมาย ในกรณีนี้ประสิทธิภาพที่ไม่ดีพอหรือไม่ หรือฉันเพียงคนตาบอดและ++iสามารถอ่านได้มากกว่าi++?

25 c++  readability  postfix 

พิจารณาวิธีการต่อไปนี้: public List<Guid> ReturnEmployeeIds(bool includeManagement = false) { } และสายต่อไปนี้: var ids = ReturnEmployeeIds(true); สำหรับนักพัฒนาใหม่สำหรับระบบมันค่อนข้างยากที่จะคาดเดาสิ่งที่trueทำ สิ่งแรกที่คุณต้องทำคือวางเม้าส์เหนือชื่อเมธอดหรือไปที่คำจำกัดความ (ซึ่งไม่ได้เป็นงานใหญ่เลยแม้แต่น้อย) แต่เพื่อประโยชน์ในการอ่านมันทำให้รู้สึกถึงการเขียน: var ids = ReturnEmployeeIds(includeManagement: true); มีที่ไหนที่อย่างเป็นทางการกล่าวถึงว่าจะระบุพารามิเตอร์ทางเลือกอย่างชัดเจนหรือไม่เมื่อคอมไพเลอร์ไม่ต้องการให้คุณ? บทความต่อไปนี้กล่าวถึงข้อตกลงการเข้ารหัสบางอย่าง: https://msdn.microsoft.com/en-gb/library/ff926074.aspx สิ่งที่คล้ายกับบทความข้างต้นจะดีมาก

25 c#  coding-style  readability  parameters 

ฉันเห็นโปรแกรมเมอร์บางคนใช้สิ่งนี้: foreach (var item in items) { if (item.Field != null) continue; if (item.State != ItemStates.Deleted) continue; // code } แทนที่จะใช้ที่ฉันปกติ: foreach (var item in items.Where(i => i.Field != null && i.State != ItemStates.Deleted)) { // code } ฉันเคยเห็นการรวมกันของทั้งสอง ฉันชอบการอ่านด้วยคำว่า 'ดำเนินการต่อ' โดยเฉพาะอย่างยิ่งกับเงื่อนไขที่ซับซ้อน มีความแตกต่างในประสิทธิภาพหรือไม่ ด้วยแบบสอบถามฐานข้อมูลฉันสมมติว่าจะมี สิ่งที่เกี่ยวกับรายการปกติ?

24 c#  readability  loops  filtering 

พิจารณาแอพที่อนุญาตให้ปลั๊กอินตอบสนองต่อโฟลว์ของโปรแกรม ฉันรู้ 2 วิธีในการบรรลุเป้าหมายนี้: hooksและevents 1. ตะขอ ใช้การเรียกฟังก์ชั่นที่ว่างเปล่าภายในผังโปรแกรมหลัก ฟังก์ชั่นเหล่านี้สามารถแทนที่ได้ด้วยปลั๊กอิน ตัวอย่างเช่น Drupal CMS ใช้ฮุคที่พร้อมใช้งานกับโมดูลและธีม นี่คือตัวอย่างของวิธีการใช้เบ็ดในฟังก์ชั่นfile_copy function file_copy(stdClass $source, $destination = NULL, $replace = FILE_EXISTS_RENAME) { // ... [File copying routine] // Inform modules that the file has been copied. module_invoke_all('file_copy', $file, $source); return $file; // ... } โมดูลสามารถใช้modulename_file_copy($file, $source)ฟังก์ชั่นซึ่งจะถูกเรียกโดยในmodule_invoke_all file_copyหลังจากฟังก์ชั่นนี้เสร็จสิ้นการfile_copyดำเนินการจะดำเนินการต่อ 2. …

24 readability  maintainability  event-programming  plugins  hooks 

นี่คือคลาส C ++ ที่สร้างขึ้นด้วยค่าสามค่า class Foo{ //Constructor Foo(std::string, int, char); private: std::string foo; char bar; int baz; }; ชนิดพารามิเตอร์ทั้งหมดแตกต่างกัน ฉันสามารถสร้างคอนสตรัคเตอร์มากเกินไปเพื่อให้ลำดับนั้นไม่สำคัญ class Foo{ //Constructors Foo(std::string, char, int); Foo(std::string, int, char); Foo(char, int, std::string); Foo(char, std::string, int); Foo(int, std::string, char); Foo(int, char, std::string); private: std::string foo; char bar; int baz; }; แต่นั่นเป็นความคิดที่ดี? …

23 c++  coding-style  class-design  readability  functions 

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

23 c#  coding-style  readability 

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

23 coding-style  coding-standards  readability  cowboy-coding