เมื่อเร็ว ๆ นี้ฉันได้สลับไปมาระหว่างหลายโครงการและสภาพแวดล้อมการพัฒนา ความคาดหวังของรูปแบบการเข้ารหัสในแต่ละแบบนั้นแตกต่างกัน
ตอนนี้คำถามของฉันคือสามส่วนแรกของความอยากรู้:
คำตอบ:
№1 # คุณกำหนดและค้นหารูปแบบการเข้ารหัสของคุณได้อย่างไร
ผ่านตัวอย่างรหัสแรกในหนังสือจากนั้นในข้อความและบทความ MSDN จากนั้นบล็อกและเว็บไซต์อื่น ๆ
№2 คุณจะเพิ่มพูนและปรับปรุงมันอย่างไร?
ฉันเปิดตาต่อทุกคำแนะนำที่ผู้คนทำ ฉันลองพวกเขาถ้าพวกเขาทำงานให้ฉันพวกเขาติด ฉันยังทำการทดลองเป็นระยะ ๆ สิ่งที่ดูเหมือนว่าจะปรับปรุงสิ่งต่าง ๆ อยู่กับฉัน
№3 คุณรักษามันอย่างไร? (จากบันทึกย่อทางจิตการเก็บรักษาเอกสารการใช้เครื่องมือเช่น StyleCop เป็นต้น)
ฉันจำสไตล์ของฉันและนำไปใช้ได้ทุกที่โดยอัตโนมัติ
หมายเหตุ 1. การรักษาตาเปิดและหูแหลมเป็นสิ่งสำคัญอย่างยิ่งที่จะอยู่ในปัจจุบัน หลายปีที่ผ่านมาฉันได้เรียนรู้จากผู้อื่นว่าเอกสารฮังการีเป็นสิ่งที่ฉันต้องทำตาม เมื่อชุมชนตระหนักว่ามันไม่ได้ยอดเยี่ยมฉันเปลี่ยนไปกับทุกคน
หมายเหตุ 2 บ่อยครั้งที่มันไม่สำคัญว่าองค์ประกอบสไตล์ใดที่คุณนำมาใช้ แต่ต้องการให้สไตล์ของคุณสอดคล้องกันตลอดทั้งรหัส เช่นเดียวกับทีม เลือกสไตล์ แต่ก็ติดมัน
หมายเหตุ 3. รูปแบบการเข้ารหัสสำหรับภาษาที่แตกต่างกันอาจแตกต่างกันไป C ++ ควรได้รับหนึ่งสไตล์ Java อีกอัน HTML และ CSS มีคุณสมบัติที่ต้องการสไตล์ที่แตกต่างอีกครั้ง
หมายเหตุ 4. สไตล์ใดก็ตามที่คุณเลือกเข้าใจและยอมรับว่ามันจะไม่ทำงาน 100% บางครั้งคุณมีรหัสบางอย่างที่ต้องการสไตล์ที่แตกต่างกันในสถานที่ไม่ว่าจะเป็นการแยกหลายบรรทัดการจัดแนวที่ต่างกันหรืออะไรก็ตามที่ทำให้ชิ้นส่วนรหัสนั้นอ่านง่ายขึ้น อย่าผลักสไตล์ของคุณไปทุกที่เน้นที่การอ่านโค้ด หากเห็นได้ชัดว่าสไตล์ไม่สามารถใช้งานได้ในสถานที่นี้ให้ทำการยกเว้น
หมายเหตุ 5. อย่าทำตามสไตล์รหัสให้กับศาสนา เครื่องมือในการบังคับใช้สไตล์โค้ดนั้นดี แต่บางครั้งอาจทำให้คุณโมโหได้ ฉันเช่นปิดการใช้งานการจัดรูปแบบรหัสอัตโนมัติของ Visual Studio เพราะมันทำให้ฉันบ้า หากเครื่องมือกลายเป็นอุปสรรคเพียงเพิ่มข้อยกเว้นและไม่ต้องกังวลว่ารหัสของคุณไม่สอดคล้องกับ 100% มันไม่สำคัญจริง ๆ และความสมบูรณ์แบบที่ไม่สามารถทำได้คืออย่างไรก็ตาม
ฉันไม่คิดว่าจะมีเวลาที่ฉันพูดว่า: "ตกลงนี้จะเป็นสไตล์ของฉัน" สนใจที่สภาพแวดล้อมหรือภาษาเฉพาะ สไตล์ของคุณควรสะท้อนให้เห็นถึงวิธีที่คุณเผชิญกับปัญหาบางอย่าง
ฉันทำงานในทีมที่มีเกมโอเพนซอร์ซที่ฉันรักและนักพัฒนานำคอยให้คำปรึกษาฉันและช่วยฉันพัฒนาทักษะของฉันหลังจากที่ฉันถามเขาเช่นกัน
เขาแนะนำและฉันได้นำรูปแบบการเข้ารหัสของ Zend Framework มาใช้ (http://framework.zend.com/manual/en/coding-standard.html)
ฉันลงเอยด้วยการนำลักษณะต่าง ๆ มาใช้รวมถึงลักษณะที่ปรากฏบน MSDN จากนั้นฉันตั้งค่าเทมเพลตใน VS ที่ให้#region/#endregionบล็อกของฉันและสิ่งอื่น ๆ ที่เป็นที่ต้องการ
ฉันยังคงศึกษารูปแบบอื่น ๆ ที่ฉันพบผ่านการวิจัยและการอ่าน ถ้าฉันคิดว่ามีบางอย่างที่โดดเด่นและสามารถปรับปรุงสไตล์ของฉันในการอ่านการบำรุงรักษาหรือองค์กรฉันลองทำดู หากการปรับเปลี่ยนสไตล์ใหม่เป็นไปตามลำดับฉันจะอัปเดตเทมเพลตใน VS หรือสร้างบันทึกย่อทางจิต
เมื่อเขียนโค้ดเพียงอย่างเดียวฉันมุ่งมั่นที่จะกระชับ การเขียนโปรแกรมสปาร์ตันอาจจะเสร็จสมบูรณ์บ้าเป็นบ้า ... แต่มันอาจเป็นสิ่งที่คุ้นเคยที่สุดสำหรับลัทธิของฉัน
เมื่อการเข้ารหัสกับผู้อื่นโดยเฉพาะการบำรุงรักษารหัสฉันมุ่งหวังที่จะเป็นกิ้งก่า - การเปลี่ยนแปลงของฉันควรปรับปรุงสิ่งที่พวกเขาแก้ไขโดยไม่ต้องมองออกนอกสถานที่
คุณกำหนดและค้นหารูปแบบการเข้ารหัสของคุณได้อย่างไร
โดยเน้นที่ความเรียบง่ายและความสามารถในการอ่าน (readability! == ความเข้าใจได้ดูการเขียนโปรแกรม Spartan )
คุณจะเพิ่มพูนและปรับปรุงมันอย่างไร?
โดยการตรวจสอบผู้อื่นและรหัสของฉันเอง (และแม้แต่มาตรฐานการเข้ารหัสด้วยตนเอง)
คุณรักษามันอย่างไร? (จากบันทึกย่อทางจิตการเก็บรักษาเอกสารการใช้เครื่องมือเช่น StyleCop เป็นต้น)
ฉันใช้dokuwiki , สายลมในการเซ็ตอัพ (ไม่มีฐานข้อมูล), โครงสร้างแบบลำดับชั้น, การควบคุมแบบละเอียด (ACL ออกจากกล่อง), รูปลักษณ์ที่ดีจริงๆและเป็นวิกิเพื่อให้ทุกคนสามารถมีส่วนร่วมได้ นอกจากนี้การมีส่วนร่วม / การเปลี่ยนแปลงจะอยู่ภายใต้ฉันทามติและความเป็นธรรมเสมอบนพื้นฐานของความเรียบง่ายและความสามารถในการอ่าน
นี่เป็นคำตอบแปลก ๆ แต่ฉันใช้เวลานานมากในการรับโปรแกรม ฉันใช้เวลาส่วนใหญ่ทำงานใน 'ศิลปะ' ก่อนที่จะพิจารณาตัวเองเป็นโปรแกรมเมอร์
เมื่อเขียนโค้ดฉันมักจะคิดในหน่วยงานเช่นการเขียน - ย่อหน้าวลี ฯลฯ ด้วยเหตุนี้ฉันจะกระจายโค้ดออกไปหลายบรรทัดเพื่อให้สามารถอ่านได้เหมือนเรื่อง / เรียงความ / ฯลฯ ฉันรู้สึกรำคาญจริงๆเมื่อนักพัฒนาพยายามยัดเยียดให้มากที่สุดเท่าที่เป็นไปได้ในหนึ่งบรรทัดหรือเข้าไปในพื้นที่เล็ก ๆ เพราะมันไม่ประสบความสำเร็จเลยนอกจากการทำให้นักเขียนรู้สึกฉลาดและน่าอ่านในอนาคต
ถ้าฉันต้องทำอะไรแปลก ๆ เพื่อประสิทธิภาพฉันจะวิจารณ์มันเพื่ออธิบายว่าทำไมมันถึงเป็นอย่างนั้น
ฉันอาจจะไม่ได้รับ upvotes ใด ๆ สำหรับเรื่องนี้ แต่บางทีนี่อาจจะจุดประกายการสนทนาบางอย่างอยู่แล้ว
สำหรับด้านเทคนิคเช่นการจัดวางวงเล็บและเช่นนั้นฉันจัดให้อยู่ในแนวเดียวกันเพราะผลที่ได้คืออ่านง่ายขึ้น
1. How did you define and find your coding style?
ฉันไปใช้แนวทางสไตล์ที่พัฒนาแล้วซึ่งส่วนใหญ่ได้รับการพัฒนาและยอมรับอย่างกว้างขวางหรือเป็นที่นิยมของ บริษัท / โครงการขนาดใหญ่
ฉันทำด้วยเหตุผลหลายประการ แต่ส่วนใหญ่เป็นเพราะนักออกแบบสไตล์สามารถนำไปใช้ในทันทีโดยนักพัฒนา คู่มือสไตล์มีมูลค่าเท่าที่นักพัฒนาเต็มใจที่จะยึดมั่น
ตัวอย่างของการดังกล่าวมีPEP 8 ธ , คู่มือสไตล์ของ Android สำหรับ Java , คู่มือสไตล์ jQuery หลักหรือของ Google หลามคู่มือสไตล์
2. How do you keep augmenting and improving it?
อาร์กิวเมนต์ที่ใหญ่ที่สุดสำหรับไกด์นำเที่ยวเช่นนี้คือพวกเขาไม่ได้ถูกประดิษฐ์ที่นี่และไม่ได้คิดค้นโดยฉัน มันต้องใช้คะแนนของนักพัฒนา, การข่มขู่สายของรหัสและเวลามากกว่า บริษัท / ทีมของคุณจะยินดีที่จะลงทุนในการพัฒนาและรักษาคู่มือสไตล์
สำหรับการปรับปรุงนั้นไม่เคยมีคู่มือสไตล์ที่ตอบทุกสิ่งที่คุณอาจจำเป็นต้องรู้ทันที แต่ในกรณีส่วนใหญ่การปรับปรุงที่ฉันเห็นว่าถูกผลักไปข้างหน้าเป็นเพียงรุ่นที่ละเอียดมากขึ้นของสิ่งที่คู่มือสไตล์ปูทางไปแล้วด้วยวิธีการเขียนโค้ด
ในกรณีเช่นนี้เมื่อคุณพบเจอกับกลุ่มของความวิปริตคุณควรวางลงในส่วนสำคัญหรือลงในเครื่องมือการแชร์โค้ดอื่น ๆ ที่เหมาะสมพร้อมด้วยการสนับสนุนไวยากรณ์สีและหารือกับผู้พัฒนารายอื่น สิ่งที่ดีเกี่ยวกับคือในกรณีเช่นนี้คุณไม่สนใจว่าโค้ดทำอะไร แต่จะเป็นอย่างไรเมื่อโค้ดปรากฏขึ้นเพื่อให้คุณสามารถถอดบล็อกนั้นออกจากบริบทและอภิปรายว่าคุณควรปรับปรุงมันอย่างไรเปรียบเทียบกับสิ่งที่ระบุไว้แล้ว คู่มือสไตล์เป็นจุดเริ่มต้นหลักสำหรับการอภิปราย
3. How do you maintain it?
สิ่งที่ดีคือคุณมีเอกสารที่มีอยู่แล้วซึ่งได้รับการดูแลแบบออนไลน์
เมื่อพูดถึงการจัดรูปแบบโค้ดคุณยังสามารถเพิ่มความพิเศษให้กับทีมของคุณด้วยการกำหนดค่าฟอร์แมตเตอร์สำหรับเครื่องมือแก้ไขที่ชื่นชอบซึ่งควรนำความหยาบคายและการคาดเดาเกี่ยวกับการรักษารูปลักษณ์ที่ยอดเยี่ยม อันที่จริงฉันจะไม่เรียกมันว่าไกลออกไป แต่เป็นส่วนสำคัญของการพัฒนา - ไม่มีอะไรที่แย่ไปกว่าการทำส่วนต่างที่ 90% ของการเปลี่ยนแปลงรหัสคือบางคนเช็คอินรหัสที่จัดรูปแบบ / สไตล์อย่างถูกต้อง ทำความสะอาดก่อนที่พวกเขาจะยอมรับคุณสมบัติใหม่ที่ยิ่งใหญ่
หากคุณเป็นส่วนหนึ่งของทีมคุณควรปฏิบัติตามมาตรฐานของทีมเสมอ มีหลายอย่างที่ต้องบอกว่าใช้เลย์เอาต์ทั่วไปและไม่ใช่แบบส่วนตัวของคุณเอง ทำให้โค้ดของคุณง่ายต่อการอ่านและทำความเข้าใจกับผู้อื่นซึ่งเป็นสิ่งจำเป็น