บริษัท ของคุณมีมาตรฐานการเข้ารหัสหรือไม่? [ปิด]

ฉันเพิ่งเห็นว่า Microsoft เปิดตัวเอกสารมาตรฐานการเข้ารหัส ( All-In-One Code Framework มาตรฐานการเข้ารหัส ) และทำให้ฉันคิดว่า ... บริษัท ที่ฉันทำงานให้ไม่มีมาตรฐานการเข้ารหัสที่เป็นทางการเลย มีนักพัฒนาเพียงไม่กี่คนและเราอยู่ด้วยกันนานพอที่จะพัฒนาเป็นสไตล์ที่คล้ายคลึงกันและไม่เคยมีปัญหามาก่อน

บริษัท ที่คุณทำงานมีมาตรฐานการเข้ารหัสที่เป็นเอกสารหรือไม่ ถ้าไม่ทำไมล่ะ การมีมาตรฐานสร้างความแตกต่างหรือไม่? คุ้มค่าที่จะเขียนมาตรฐานตั้งแต่เริ่มต้นหรือคุณควรใช้มาตรฐานอื่นเป็นของคุณเอง (เช่นทำให้มาตรฐานของ Microsoft เป็นของคุณ)

สิ่งสำคัญคือทีมจะต้องมีมาตรฐานการเข้ารหัสเดียวสำหรับแต่ละภาษาเพื่อหลีกเลี่ยงปัญหาต่าง ๆ :

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

ฉันเป็นแฟนตัวยงของสิ่งที่ลุงบ๊อบพูดเกี่ยวกับมาตรฐาน:

1. ปล่อยให้พวกมันมีวิวัฒนาการในช่วงการทำซ้ำสองสามครั้งแรก
2. ให้พวกเขาเป็นทีมที่เฉพาะเจาะจงแทน บริษัท ที่เฉพาะเจาะจง
3. อย่าจดลงไปหากคุณสามารถหลีกเลี่ยงได้ ค่อนข้างปล่อยให้รหัสเป็นวิธีที่มาตรฐานถูกจับ
4. อย่าออกกฎหมายการออกแบบที่ดี (เช่นอย่าบอกให้คนอื่นไม่ใช้ goto)
5. ตรวจสอบให้แน่ใจว่าทุกคนรู้ว่ามาตรฐานนั้นเกี่ยวกับการสื่อสารและไม่มีอะไรอื่น
6. หลังจากการทำซ้ำสองสามครั้งแรกให้ทีมร่วมกันตัดสินใจ

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

• มันทำให้การอ่านผ่านทั้งรหัสฐานง่ายขึ้นมากเนื่องจากการสลับระหว่างสไตล์การเข้ารหัสระหว่างไฟล์นั้นน่ารำคาญ
• มันทำให้การอ่านไฟล์เดียวง่ายขึ้นเนื่องจากไฟล์ใด ๆ ที่อัพเดตโดยนักพัฒนาสองคนที่มีรูปแบบที่ขัดแย้งกันในที่สุดก็มักจะทำให้รูปแบบเหล่านั้นมิกซ์กัน การอ่านไฟล์ที่ผสมแท็บและช่องว่าง (และแก้ไขในภายหลัง) เป็นความเจ็บปวดในตูด
• มันช่วยให้นักพัฒนาใหม่ใช้รูปแบบที่ดีได้ง่ายขึ้นถ้ามีมาตรฐานที่ชัดเจนแทนที่จะเป็นมาตรฐาน
• ข้อตกลงการตั้งชื่อที่สอดคล้องกันทำให้การค้นหาฟังก์ชัน / ตัวแปรง่ายขึ้น มันคือ ArraySort หรือ array_Sort หรือ sortTheArray หรือ doSortArray หรือ ...

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

ฉันไม่เห็นด้วยกับ "เราเป็นร้านค้า X" ดังนั้นเราจึงจัดรูปแบบรหัสของเราในทุกภาษาในลักษณะเดียวกัน

โดยส่วนตัวแล้วฉันพบว่าภาษาส่วนใหญ่มีสไตล์ที่ยอมรับแตกต่างกัน

ฉันไม่สามารถยืนได้เมื่อโปรแกรมเมอร์ C เขียนโค้ด Java ด้วยการจัดรูปแบบ C ไม่เพียง แต่ดูเหมือนว่า Java เท่านั้น แต่ยังทำให้พวกเขาคิดว่าพวกเขาสามารถใช้วิธีปฏิบัติ C-like อื่น ๆ ใน Java

ฉันคิดว่าถ้าคุณมีมาตรฐานมันควรจะเป็นต่อภาษา

อดีตนายจ้างของฉันมีมาตรฐานการเข้ารหัส ฉันกำลังพิจารณาเอกสารอย่างเป็นทางการสำหรับตัวเองเช่นกัน

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

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

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

แต่ที่แย่ที่สุดคือบางคนเขียนชื่อตัวแปรและคลาสเป็นภาษาอิตาลีบางคนเป็นภาษาอังกฤษ ...

ฉันปรับสไตล์ของฉันให้เข้ากับภาษาห้องสมุดและกรอบงานที่ฉันใช้อยู่เสมอเพื่อให้ซอร์สโค้ดดูสม่ำเสมอและเรียบง่าย

โปรดทราบว่านี่เป็นเอกสารมาตรฐานการเข้ารหัสซึ่งเฉพาะกับ All-In-One Code Framework

ฉันทำงานที่ บริษัท หลายแห่งซึ่งบางแห่งมีมาตรฐานที่มีอยู่และบางแห่ง (ส่วนใหญ่) ที่ฉันช่วยพัฒนามาตรฐาน ส่วนใหญ่หากคุณกำลังพัฒนาโดยใช้. NET (และแม้ว่าคุณจะไม่ได้ใช้กฎส่วนใหญ่ยังคงมีผลบังคับใช้) คุณควรดูที่แนวทางการออกแบบเฟรมเวิร์ก แม้ว่านี่จะเป็นสิ่งเฉพาะสำหรับการเขียน API ที่เปิดเผยต่อสาธารณะ แต่แนวทางส่วนใหญ่จะใช้กับโค้ดใดก็ได้

ข้อกังวลที่ใหญ่ที่สุดของมาตรฐานรหัสคือทำให้มันค่อนข้างเรียบง่ายและตรงไปตรงมา คุณต้องการให้นักพัฒนาสามารถปรับใช้แนวทางที่นำเสนอเพื่อให้เอกสาร 50+ หน้าแก่พวกเขานั้นไม่มีประโยชน์ คุณยังคงสามารถสร้างเอกสารนั้นได้หากคุณต้องการให้พื้นหลังตัวอย่าง ฯลฯ แต่คุณจะต้องการบางสิ่งที่ทำให้ชุดแนวทางการใช้สัญลักษณ์แสดงหัวข้อย่อยหายไป มาตรฐานการเข้ารหัสของคุณจะต้องเป็นเอกสารที่มีความยืดหยุ่นและมีชีวิตซึ่งต้องเปลี่ยนตามการเปลี่ยนแปลงของเทคโนโลยี

การอภิปรายมาตรฐานการเข้ารหัสมีดังนี้

• ใช่คุณต้องการรหัสที่สม่ำเสมอและสะอาดเป็นรากฐานสำคัญของการพัฒนาที่ดี
• สิ่งที่พวกเขาเกือบจะไม่สำคัญตราบใดที่ทุกคนปฏิบัติตามมาตรฐานเดียวกัน
• อย่าเขียนของคุณเองคุณจะจบลงด้วยการสนทนาที่ไม่รู้จบและเจ็บปวด มีมากมายออกมีที่เป็นที่นิยม
• การใช้มาตรฐานสาธารณะ (เช่นเดียวกับในMSDN ) ช่วยให้คุณเป็นบุคคลที่สามผู้ไม่เชื่อเรื่องพระเจ้าที่ไม่สามารถโต้เถียงได้ หากคุณต้องการโต้แย้งกับพวกเขาอ้างถึงจุดที่ 2

หากคุณกำลังพัฒนาใน C # ใน Visual Studio แล้วStyleCopเป็นสัญลักษณ์แสดงหัวข้อเงิน หากคุณใช้ ReSharper ด้วยเช่นกันปลั๊กอินStyleCop สำหรับ ReSharperนั้นยอดเยี่ยมมาก

เราเป็นร้านร้องไห้สะอึกสะอื้นดังนั้นเราจึงใช้การประชุมการเขียนโปรแกรมร้องไห้สะอึกสะอื้น

ตอนนี้พอลเกรแฮมและเพื่อน ๆ ฉลาดกว่าพวกเรามาก แต่พวกเราเขียนโปรแกรมร้องไห้สะอึกสะอื้นพวกเราทุกคนสามารถอ่านร้องไห้สะอึกสะอื้นกันในความเป็นจริงโปรแกรมเมอร์เขียนเสียงร้องไห้ใด ๆ สามารถอ่านรหัสร้องไห้สะอึกสะอื้นของเราได้

ในความเป็นจริงเนื่องจากการออกแบบของร้องไห้สะอึกสะอื้นโปรแกรมเมอร์ใด ๆ ร้องไห้สะอึกสะอื้นสามารถอ่านไฟล์ร้องไห้สะอึกสะอื้นเดียวและเข้าใจมันเพราะร้องไห้สะอึกสะอื้นไม่ได้มีระบบมาโคร

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

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

มันสามารถช่วยเหลือผู้คนได้นอกจากนี้มันยังสามารถช่วยด้วยเครื่องมือจริง ๆ :

หากคุณต้องการที่จะใช้การจัดรูปแบบรหัสอัตโนมัติใด ๆ ที่คุณต้องการจริงๆเพื่อสร้างมาตรฐานกฎที่จะใช้มิฉะนั้นคุณจะได้รับการเปลี่ยนแปลงการจัดรูปแบบที่ไม่มีความหมายมากมายอย่างต่อเนื่อง

ชุดกฎเริ่มต้นสำหรับเครื่องมือวิเคราะห์แบบคงที่อาจตรวจสอบรูปแบบการตั้งชื่อที่เฉพาะเจาะจงและอาจง่ายกว่าทุกรอบในการปฏิบัติตามกฎนั้นจากนั้นจึงเขียนกฎใหม่ขึ้นมา (ยกเว้นว่าคุณกำลังจะปิดกฎโดยสิ้นเชิง)

สุดท้ายก็เป็นเรื่องดีที่จะสร้างมาตรฐานให้กับทุกสิ่งที่จำเป็นต้องปรึกษากับใครบางคนที่อยู่นอกทีมของคุณ เช่นคุณอาจต้องการประกาศเกี่ยวกับลิขสิทธิ์มาตรฐานในส่วนหัวของคุณเนื่องจากคุณไม่ต้องการเรียกใช้ทุกไฟล์ใหม่ที่คุณเขียนผ่านทีมกฎหมายของ บริษัท และแน่นอนว่าคุณต้องการรับชื่อ API สาธารณะใด ๆ ในครั้งแรก