ก่อวินาศกรรมมาตรฐานการเข้ารหัส [ปิด]
มีมาตรฐานการเข้ารหัสที่บังคับใช้กับ บริษัท ซอฟต์แวร์ต่าง ๆ ซึ่งมีเป้าหมายในการเพิ่มความน่าเชื่อถือของรหัสความสามารถในการพกพาและที่สำคัญที่สุดคือความสามารถในการอ่านรหัสที่เขียนร่วมกันโดยผู้พัฒนาซอฟต์แวร์ สองตัวอย่างที่โดดเด่นเป็นMISRA Cและ C ++ มาตรฐานการพัฒนาสำหรับโครงการ JSF เหล่านี้มักจะอยู่ในรูปแบบต่อไปนี้หลังจากระบุอย่างระมัดระวังคำว่า "ต้อง", "จะ", "ควร", "ควร", "อาจ" ฯลฯ หมายถึง: ตัวอย่าง: กฎข้อที่ 50: ตัวแปรจุดลอยตัวจะต้องไม่ถูกทดสอบเพื่อความเท่าเทียมหรือความไม่เท่าเทียมที่แน่นอน เหตุผล:เนื่องจากตัวเลขจุดลอยตัวอาจมีข้อผิดพลาดในการปัดเศษและการตัดปลายดังนั้นจึงอาจไม่สามารถสร้างความเท่าเทียมกันได้แม้จะเป็นไปตามที่คาดไว้ก็ตาม มาตรฐานการเข้ารหัสเหล่านี้ก่อให้เกิดข้อ จำกัด ซึ่งโดยทั่วไปจะเป็นรหัสซึ่งจะถูกกฎหมายจากมุมมองของคอมไพเลอร์ แต่เป็นอันตรายหรืออ่านไม่ได้ดังนั้นจึงถือว่าเป็นอันตราย ตอนนี้มาทำสิ่งนี้กันเถอะ! คุณได้รับการยอมรับในฐานะสมาชิกของคณะกรรมการมาตรฐานขนาดเล็กที่ บริษัท ของคุณซึ่งมีวัตถุประสงค์เพื่อออกแบบมาตรฐานการเข้ารหัสใหม่ที่นักพัฒนาทุกคนใน บริษัท จะต้องใช้ ไม่เป็นที่รู้จักกับคนอื่น ๆ คุณแอบอยู่ในการจ้างงานขององค์กรที่ชั่วร้ายและมีภารกิจในการก่อวินาศกรรม บริษัท คุณต้องเสนอหนึ่งรายการขึ้นไปกับมาตรฐานการเข้ารหัสซึ่งจะขัดขวางนักพัฒนาในภายหลัง อย่างไรก็ตามคุณจะต้องระมัดระวังที่จะไม่ทำให้เรื่องนี้ชัดเจนในทันทีมิฉะนั้นคุณเสี่ยงที่จะไม่ได้รับการยอมรับในมาตรฐาน กล่าวอีกนัยหนึ่งคุณจะต้องแนะนำกฎเกณฑ์ให้กับมาตรฐานการเข้ารหัสซึ่งมีลักษณะที่ถูกต้องตามกฎหมายและมีโอกาสที่ดีในการได้รับการยอมรับจากสมาชิกของคณะกรรมการอื่น ๆ หลังจากที่โครงการเริ่มต้นขึ้นและมีการลงทุนจำนวนชั่วโมงในรหัสคุณควรจะสามารถใช้กฎเหล่านี้ในทางที่ผิด (ตัวอย่างเช่นโดยเทคนิคหรือโดยมากการตีความตามตัวอักษร) เพื่อตั้งค่าสถานะรหัสอื่นที่มีคุณภาพดีและไม่เป็นไปตามมาตรฐาน ดังนั้นพวกเขาจึงต้องใช้ความพยายามอย่างมากในการออกแบบใหม่และกฎจะขัดขวางพวกเขาจากจุดนี้ แต่เมื่อกฎมีการใช้งานมาระยะหนึ่งแล้วโมเมนตัมบริสุทธิ์จะทำให้บทบาทเหล่านี้มีชีวิตอยู่และเนื่องจากมีความขัดแย้งที่สำคัญ ผลประโยชน์ระหว่างระดับการจัดการที่แตกต่างกันผู้จัดการคนอื่นอาจจะรักษากฎชีวิตไว้ (พวกเขาจะโง่เขลาที่จะยอมรับความผิดพลาดของพวกเขา!) ดังนั้นขัดขวาง …