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

รูปแบบการเข้ารหัสเป็นชุดแนวทางที่ช่วยให้สามารถอ่านและเข้าใจซอร์สโค้ดได้

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

6
ความยาวไฟล์ 'แนะนำ' และความกว้างของบรรทัด [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว ฉันอยากรู้ว่าใครรู้คำแนะนำจากแหล่งที่เชื่อถือได้สำหรับจำนวนบรรทัดสูงสุดของรหัสสำหรับไฟล์ที่กำหนด ตัวอย่างเช่น Linter ของ Google แนะนำให้แต่ละบรรทัดไม่ควรเกิน 80 อักขระ

4
อะไรทำให้“ สไตล์ดี” ใน Java? [ปิด]
ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา ฉันได้ถามคำถามนี้เกี่ยวกับ Stackoverflow และก่อนที่จะถูกโห่ไล่ฉันได้รับคำแนะนำที่เป็นประโยชน์จากPéterTörökว่านี่อาจเป็นสถานที่ที่ดีกว่าในการโพสต์ ฉันเขียนโปรแกรมใน Java มาสองสามปีแล้ว ฉันมักจะพูดคุยเกี่ยวกับการตัดสินใจออกแบบกับเพื่อนร่วมงานบนพื้นฐานของสิ่งที่ถือว่าเป็น 'รูปแบบที่ดี' แท้จริงแล้วมีจำนวนคำถาม / คำตอบ StackOverflow ที่กล่าวถึงการออกแบบบนพื้นฐานของสิ่งที่เป็นสไตล์ที่ดี แต่อะไรที่ทำให้ 'สไตล์ดี'? เช่นเดียวกับหลาย ๆ สิ่งฉันรู้ว่าเมื่อฉันเห็นมัน ... แต่ฉันต้องการความคิดที่ดีกว่าแค่ความรู้สึกผิดชอบชั่วดีของฉันโดยบอกว่าการออกแบบนี้ไม่ถูกต้อง คุณคิดอย่างไรเกี่ยวกับการสร้างโค้ดที่ดีและออกแบบมาอย่างดี? (ฉันยอมรับว่านี่เป็นเรื่องส่วนตัวเนื่องจาก 'สไตล์ดี' จะขึ้นอยู่กับงานในมือ) (นอกจากนี้ฉันควรเพิ่มว่าฉันไม่สนใจสไตล์ทีม - เช่น "เราใช้การเยื้องของ 2 ช่องว่างแทนที่จะเป็น 4" ... และฉันไม่สนใจระเบียบของโค้ด Java) แก้ไข: ขอบคุณสำหรับคำตอบ / ความคิดเห็นที่ดีทั้งหมด ฉันกระตือรือร้นเป็นอย่างยิ่งสำหรับคำตอบที่จะช่วยจัดระเบียบสิ่งต่าง ๆ ที่ทำให้ประแจความรู้สึกผิดชอบของโปรแกรมเมอร์ (และอาจเป็นไปได้)

6
ให้การนำเสนอเกี่ยวกับ "รูปแบบโค้ดและรูปแบบการออกแบบ" [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา บริษัท ของฉัน (เล็กประมาณ 40 คนใน 3 สำนักงาน) เป็นครั้งคราว "นักพัฒนาเวิร์คช็อป" ออนไลน์โดยที่ devs คนหนึ่งเป็นเจ้าภาพการนำเสนอเกี่ยวกับหัวข้อเทคโนโลยีบางอย่าง มันไม่จำเป็นต้องเกี่ยวกับงานของเรา แต่เพียงเพื่อช่วยให้ทุกคนพัฒนาทักษะและความเข้าใจของพวกเขา ฉันถูกขอให้โฮสต์รายการถัดไปและหัวข้อ (เลือกจากรายการที่ฉันให้ไว้) คือรูปแบบโค้ดและรูปแบบการออกแบบ ฉันรู้ว่าสิ่งเหล่านั้นไม่ได้เกี่ยวข้องอย่างใกล้ชิด แต่อดทนกับฉัน ฉันเคยเห็นสถานที่ต่างๆในฐานรหัสของเราที่สามารถปรับปรุงได้ซึ่งบางแห่งอาจมีคุณสมบัติตรงกับ DailyWTF ดังนั้นฉันจึงต้องการให้งานนำเสนอนี้มีประสิทธิภาพมากที่สุด ปัญหาคือฉันไม่รู้ว่าจะครอบคลุมอะไรในหนึ่งชั่วโมง ความคิดแรกของฉันคือการใช้รหัสของเราเป็นตัวอย่างในการผลักดันจุดที่ "โปรดนำสิ่งนี้ไปใช้กับงานของคุณ" แต่หัวข้อนั้นกว้างมาก มีบางอย่างผิดปกติกับรหัสของเรา (PHP) รวมถึง: OO น้อยที่สุด มันได้รับการปรับปรุงเมื่อเร็ว ๆ นี้ แต่ยังมีฟังก์ชั่นระดับโลกมากมาย ฉันใช้เวลาสักครู่เพื่อค้นหาสิ่งต่าง ๆ กำหนดค่าทั่วโลก (ความคิดเห็นที่ฉันเดา) คุณสามารถค้นหา $ GLOBALS ['blah'] …

7
การแสดงความคิดเห็น / รูปแบบเอกสารในรหัส
นี่อาจเป็นคำถามที่โง่ แต่ก็อยู่ข้างหลังศีรษะของฉันซักพักแล้วและฉันไม่สามารถหาคำตอบที่เหมาะสมได้จากที่อื่น ฉันมีครูผู้หนึ่งที่บอกว่าเราควรระบุพารามิเตอร์แต่ละรายการด้วยคำอธิบายอย่างชัดเจนแม้ว่าจะมีเพียงพารามิเตอร์เดียวเท่านั้น สิ่งนี้นำไปสู่การซ้ำซ้อนมากมาย: double MyFunction(const int MyParam); // Function: MyFunction // Summary: Does stuff with MyParam. // Input: int MyParam - The number to do stuff with. // Output: MyParam with stuff done to it. เมื่อเขียนเอกสารในโค้ดคุณมีรายละเอียดมากน้อยเพียงใด?
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.