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

สมมติว่าอินเตอร์เฟสมีวิธีการเหล่านี้: Car find(long id); List<Car> find(String model); จะเป็นการดีกว่าถ้าจะเปลี่ยนชื่อพวกเขาเช่นนี้? Car findById(long id); List findByModel(String model); อันที่จริงนักพัฒนาซอฟต์แวร์ใด ๆ ที่ใช้ API นี้ไม่จำเป็นต้องดูที่อินเทอร์เฟซเพื่อรับทราบข้อโต้แย้งที่เป็นไปได้ของfind()วิธีการเริ่มต้น ดังนั้นคำถามของฉันจึงเป็นเรื่องทั่วไปมากขึ้น: อะไรคือประโยชน์ของการใช้วิธีโอเวอร์โหลดในโค้ดเนื่องจากลดความสามารถในการอ่าน

14 design  naming  readability  method-overloading 

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

14 architecture  coding-standards  readability  method-chaining 

ฉันมีวิชาเรียนมากมายที่จัดการกับการตรวจสอบความถูกต้องของค่า ตัวอย่างเช่นRangeValidatorคลาสจะตรวจสอบว่าค่าอยู่ในช่วงที่ระบุหรือไม่ คลาสตัวตรวจสอบความถูกต้องมีสองวิธี: is_valid(value)ซึ่งส่งคืนTrueหรือFalseขึ้นอยู่กับค่าและensure_valid(value)ตรวจสอบค่าที่ระบุและไม่ทำอะไรเลยถ้าค่านั้นถูกต้องหรือส่งข้อยกเว้นเฉพาะถ้าค่าไม่ตรงกับกฎที่กำหนดไว้ล่วงหน้า ขณะนี้มีการทดสอบสองหน่วยที่เกี่ยวข้องกับวิธีนี้: สิ่งที่ผ่านค่าที่ไม่ถูกต้องและทำให้แน่ใจว่ามีข้อผิดพลาดเกิดขึ้น def test_outside_range(self): with self.assertRaises(demo.ValidationException): demo.RangeValidator(0, 100).ensure_valid(-5) สิ่งที่ผ่านค่าที่ถูกต้อง def test_in_range(self): demo.RangeValidator(0, 100).ensure_valid(25) แม้ว่าการทดสอบครั้งที่สองจะทำงาน - ล้มเหลวหากมีการโยนข้อยกเว้นและประสบความสำเร็จหากensure_validไม่ได้โยนอะไรเลย - ความจริงที่ว่าไม่มีสิ่งใดassertอยู่ข้างในดูแปลก คนที่อ่านรหัสดังกล่าวจะถามตัวเองทันทีว่าทำไมมีการทดสอบซึ่งดูเหมือนว่าไม่ได้ทำอะไรเลย นี่เป็นแนวปฏิบัติในปัจจุบันเมื่อทดสอบวิธีที่ไม่ส่งคืนค่าและไม่มีผลข้างเคียงหรือไม่ หรือฉันควรจะเขียนการทดสอบในวิธีที่ต่างออกไป? หรือเพียงแค่ใส่ความคิดเห็นอธิบายสิ่งที่ฉันทำ

13 unit-testing  exceptions  readability 

เมื่อคุณต้องย้ำผู้อ่านที่ไม่ทราบจำนวนรายการที่จะอ่านและวิธีเดียวที่จะทำคือการอ่านต่อไปจนกว่าจะถึงจุดสิ้นสุด นี่เป็นสถานที่ที่คุณต้องการวนซ้ำไม่รู้จบ มีเสมอtrueที่ระบุว่าจะต้องมีbreakหรือreturnคำสั่งบางแห่งในบล็อก int offset = 0; while(true) { Record r = Read(offset); if(r == null) { break; } // do work offset++; } มีวิธีอ่านลูปสองครั้ง Record r = Read(0); for(int offset = 0; r != null; offset++) { r = Read(offset); if(r != null) { // do work } } …

13 c#  code-quality  readability 

ในภาษาการเขียนโปรแกรมส่วนใหญ่ตัวแปรไม่มีการระบุอักขระเหมือนที่ทำใน PHP ใน PHP คุณต้องนำหน้าตัวแปรด้วย$อักขระ ตัวอย่าง; var $foo = "something"; echo $foo; ฉันกำลังพัฒนาภาษาสคริปต์ใหม่สำหรับแอปพลิเคชันธุรกิจและผู้ใช้เป้าหมายของฉันไม่มีพื้นหลังการเขียนโปรแกรม อักขระเหล่านี้ทำให้รหัสอ่านและใช้ง่ายขึ้นหรือไม่ เหตุผลหนึ่งที่ PHP ใช้$คือเพราะไม่มี PHP ไม่สามารถบอกได้ว่าชื่อคือการอ้างอิงฟังก์ชันหรือการอ้างอิงตัวแปร นี่เป็นเพราะภาษาอนุญาตการอ้างอิงที่แปลกไปยังฟังก์ชัน ดังนั้น$สัญลักษณ์จะช่วยให้ parser แยก namespace ฉันไม่มีปัญหานี้ในโปรแกรมแยกวิเคราะห์ ดังนั้นคำถามของฉันคือการอ่านง่ายและใช้งานง่าย ฉันเขียนโค้ดเป็นเวลาหลายปีใน PHP ว่าเมื่อฉันเห็น$fooมันเป็นเรื่องง่ายสำหรับฉันที่จะระบุว่านี่เป็นตัวแปร ฉันแค่ให้การตั้งค่าอคติกับตัวระบุนี้หรือไม่

13 programming-languages  readability 

ฉันใหม่กับ Clojure ฉันเข้าใจรหัสที่ฉันเขียนได้ แต่มันยากเกินไปที่จะเข้าใจในภายหลัง มันยากที่จะจับคู่วงเล็บ อะไรคือข้อตกลงทั่วไปที่ต้องติดตามเกี่ยวกับการตั้งชื่อและการเยื้องในสถานการณ์ต่าง ๆ ตัวอย่างเช่นฉันเขียนตัวอย่างการกำหนดโครงสร้างตัวอย่างเพื่อทำความเข้าใจ แต่มันดูไม่สามารถอ่านได้อย่างสมบูรณ์ในครั้งที่สอง (defn f [{x :x y :y z :z [a b c] :coll}] (print x " " y " " z " " a " " b " " c)) ในกรณีของการปรับโครงสร้างควรทำโดยตรงที่ระดับพารามิเตอร์หรือเริ่มฟอร์มให้แล้วดำเนินการต่อที่นั่น?

13 readability  clojure 

ฉันเพิ่งเขียนคำสั่ง if ที่มีชื่อคุณสมบัติยาวพอสมควรและเกิดปัญหานี้ขึ้น สมมติว่าเรามีคำสั่ง if เช่นนี้: if(_someViewModelNameThatIsLong.AnotherPropertyINeedToCheck == someValue && !_someViewModelNameThatIsLong.ThisIsABooleanPropertyThatIsImportant) { //Do something } คุณสมบัติที่สองเป็นประเภทบูลีนและไม่มีเหตุผลใดที่จะมี stetement เช่นนี้ if(boleanValue == true) มีวิธีที่ดีกว่าในการเน้นการปฏิเสธจากนั้นให้ใส่!ด้านหน้า สำหรับฉันดูเหมือนว่าเรื่องนี้สามารถดูแลได้ง่ายเมื่ออ่านรหัสและอาจทำให้เกิดปัญหากับการดีบัก

13 readability 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน2 ปีที่ผ่านมา ฉันอยากรู้เกี่ยวกับเรื่องนี้เพราะฉันจำก่อนที่จะเรียนรู้ภาษาที่ใช้งานได้ใด ๆ ฉันคิดว่าพวกเขาทั้งหมดอย่างน่ากลัว, สุดยอดและไม่สามารถอ่านได้ชะมัด ตอนนี้ฉันรู้ Haskell และ f # ฉันพบว่าใช้เวลานานกว่าในการอ่านรหัสน้อยลง แต่รหัสน้อยนั้นทำเกินกว่าจำนวนที่เท่ากันจะเป็นภาษาที่จำเป็นดังนั้นจึงรู้สึกว่าได้รับสุทธิและฉันก็ไม่ได้เป็นอย่างยิ่ง มีประสบการณ์ในการทำงาน นี่คือคำถามของฉันฉันมักจะได้ยินจากคน OOP ที่สไตล์การทำงานไม่สามารถอ่านได้มาก ฉันอยากรู้ว่าเป็นกรณีนี้หรือไม่และฉันหลอกตัวเองหรือถ้าพวกเขาใช้เวลาในการเรียนรู้ภาษาที่ใช้งานได้ทั้งสไตล์จะไม่สามารถอ่านได้มากกว่า OOP อีกต่อไป? มีใครเคยเห็นหลักฐานหรือมีเกร็ดเล็กเกร็ดน้อยใด ๆ ที่พวกเขาเห็นสิ่งนี้ไม่ทางใดก็ทางหนึ่งโดยมีความถี่เพียงพอที่จะพูดได้หรือไม่? ถ้าการเขียนฟังก์ชั่นมีความสามารถในการอ่านต่ำกว่าจริง ๆ แล้วฉันไม่ต้องการใช้มันต่อไป แต่ฉันไม่รู้ว่ามันเป็นจริงหรือไม่ ..

13 object-oriented  functional-programming  readability 

ความเข้าใจของฉันอยู่ที่[Flag]enums มักจะใช้สำหรับสิ่งที่สามารถนำมารวมกันที่แต่ละค่าไม่ได้พิเศษร่วมกัน ตัวอย่างเช่น: [Flags] public enum SomeAttributes { Foo = 1 << 0, Bar = 1 << 1, Baz = 1 << 2, } ใด ๆ ที่SomeAttributesคุ้มค่าจะเป็นการรวมกันของFoo, และBarBaz ในสถานการณ์จริงที่ซับซ้อนมากขึ้นฉันใช้ enum เพื่ออธิบายDeclarationType: [Flags] public enum DeclarationType { Project = 1 << 0, Module = 1 << 1, ProceduralModule = 1 << …

12 c#  .net  readability  enum 

ฉันพยายามปฏิบัติตาม Single Responsibility Principle (SRP) และไม่ใช้ Code ซ้ำ อย่างไรก็ตามมักจะมีสถานที่ที่มีการทำซ้ำรหัสที่ไม่มีอะไรมากไปกว่าบล็อคโค้ดของการเรียกใช้ที่สามารถต้านทานการแตกออกเป็นอย่างน้อยแปลความหมายเต็มวิธีการชื่อ: DoAction1(); DoAction2(); if (value) DoAction3(); DoAction4(); เป็นวิธีที่ดีที่สุดในการแยกรหัสดังกล่าวเป็นวิธีการและวิธีการตั้งชื่อมันได้อย่างไร

11 refactoring  readability  single-responsibility  code-reuse 

ฉันเพิ่งดำเนินการ refactoring ของโครงการขนาดกลางใน Java เพื่อกลับไปและเพิ่มการทดสอบหน่วย เมื่อฉันรู้ว่ามันเจ็บปวดแค่ไหนในการล้อเลียนและสถิตยศาสตร์ในที่สุดฉันก็ "ได้รับ" สิ่งที่ฉันได้อ่านเกี่ยวกับพวกเขาตลอดเวลานี้ (ฉันเป็นหนึ่งในคนเหล่านั้นที่ต้องเรียนรู้จากประสบการณ์โอ้สบายดี) ดังนั้นตอนนี้ที่ฉันใช้ Spring เพื่อสร้างวัตถุและโยงเข้าด้วยกันฉันจะกำจัดstaticคำหลักไปทางซ้ายและขวา (ถ้าฉันอาจต้องการเยาะเย้ยมันก็ไม่คงที่ในความหมายเดียวกับที่ Math.abs () ใช่ไหม?) สิ่งนี้คือฉันได้รับนิสัยการใช้staticเพื่อแสดงว่าวิธีการไม่ได้พึ่งพา ในสถานะวัตถุใด ๆ ตัวอย่างเช่น: //Before import com.thirdparty.ThirdPartyLibrary.Thingy; public class ThirdPartyLibraryWrapper { public static Thingy newThingy(InputType input) { new Thingy.Builder().withInput(input).alwaysFrobnicate().build(); } } //called as... ThirdPartyLibraryWrapper.newThingy(input); //After public class ThirdPartyFactory { public Thingy newThingy(InputType input) { …

11 coding-standards  readability  coding-style  static-methods 

สิ่งใดที่จะถือว่าได้รับการบำรุงรักษามากขึ้น if (a == b) c = true; else c = false; หรือ c = (a == b); ฉันลองดูใน Code Complete แต่ไม่พบคำตอบ ฉันคิดว่าอันแรกสามารถอ่านได้มากขึ้น (คุณสามารถอ่านออกเสียงออกมาได้ดัง ๆ ) ซึ่งฉันคิดว่าทำให้สามารถบำรุงรักษาได้มากขึ้น อันที่สองมีความเหมาะสมมากกว่าและลดรหัส แต่ฉันไม่แน่ใจว่ามันจะบำรุงรักษาได้สำหรับนักพัฒนา C # (ฉันคาดว่าจะเห็นสำนวนนี้มากขึ้นเช่น Python)

11 .net  code-quality  readability  maintainability  clean-code 

ฉันกำลังทำงานโครงการในเดลฟายและฉันกำลังสร้างตัวติดตั้งสำหรับแอปพลิเคชันมีสามส่วนหลัก การติดตั้ง / ถอนการติดตั้งPostgreSQL myapplication (การตั้งค่า myapplication ถูกสร้างขึ้นโดยใช้ nsi) การติดตั้ง / ถอนการติดตั้ง การสร้างตารางใน Postgres ผ่านสคริปต์ (แบตช์ไฟล์) ทุกสิ่งทำงานได้อย่างราบรื่นและราบรื่น แต่หากสิ่งที่ล้มเหลวฉันได้สร้าง LogToFileger ซึ่งจะ LogToFile ทุกขั้นตอนของกระบวนการ เช่นนี้ LogToFileToFile.LogToFile('[DatabaseInstallation] : [ACTION]:Postgres installation started'); ฟังก์ชั่นLogToFileToFile.LogToFile()นี้จะเขียนเนื้อหาไปยังไฟล์ มันใช้งานได้ดี แต่ปัญหาก็คือมันทำให้โค้ดยุ่งเหยิงเพราะมันยากที่จะอ่านโค้ดเพราะคนคนหนึ่งเห็นการLogToFileToFile.LogToFile()เรียกใช้ฟังก์ชั่นได้ทุกที่ในโค้ด ตัวอย่าง if Not FileExists(SystemDrive+'\FileName.txt') then begin if CopyFile(PChar(FilePathBase+'FileName.txt'), PChar(SystemDrive+'\FileName.txt'), False) then LogToFileToFile.LogToFile('[DatabaseInstallation] : copying FileName.txt to '+SystemDrive+'\ done') else …

11 code-quality  readability  logging 

ฉันคิดว่าคำถามนี้จะถูกตั้งค่าสถานะเป็นอัตนัยทันที แต่สิ่งใดที่คุณคิดว่าดีกว่า: double volume(double pressure, double n_moles, double temperature) { return n_moles * BOLTZMANN_CONSTANT * temperature / pressure; } หรือ double volume(double P, double n, double T) { return n*R*T/P; } กล่าวอีกนัยหนึ่งฟังก์ชั่นที่ใช้สมการจะต้องปฏิบัติตามสัญกรณ์ของสมการนั้นหรือควรใช้ชื่อที่ละเอียดยิ่งขึ้น?

11 math  coding-style  readability 

ข้อไหนดีกว่าในการบำรุงรักษา if (byteArrayVariable != null) if (byteArrayVariable .Length != 0) //Do something with byteArrayVariable หรือ if ((byteArrayVariable != null) && (byteArrayVariable.Length != 0)) //Do something with byteArrayVariable ฉันชอบการอ่านและการเขียนที่สอง แต่ฉันจำได้ว่าการอ่านในโค้ดเสร็จสมบูรณ์ซึ่งทำสิ่งต่าง ๆ เช่นนั้นไม่ดีสำหรับการบำรุงรักษา นี่เป็นเพราะคุณพึ่งพาภาษาที่จะไม่ประเมินส่วนที่สองของifถ้าส่วนแรกเป็นเท็จและไม่ใช่ทุกภาษาที่ทำเช่นนั้น (ส่วนที่สองจะโยนข้อยกเว้นถ้าประเมินด้วย null byteArrayVariable) ฉันไม่ทราบว่าเป็นสิ่งที่ต้องกังวลหรือไม่และฉันต้องการความคิดเห็นทั่วไปเกี่ยวกับคำถาม ขอบคุณ

11 programming-practices  coding-standards  maintenance  readability