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

สองตัวอย่างที่โดดเด่นเป็นMISRA Cและ C ++ มาตรฐานการพัฒนาสำหรับโครงการ JSF

เหล่านี้มักจะอยู่ในรูปแบบต่อไปนี้หลังจากระบุอย่างระมัดระวังคำว่า "ต้อง", "จะ", "ควร", "ควร", "อาจ" ฯลฯ หมายถึง:

ตัวอย่าง:

กฎข้อที่ 50: ตัวแปรจุดลอยตัวจะต้องไม่ถูกทดสอบเพื่อความเท่าเทียมหรือความไม่เท่าเทียมที่แน่นอน

เหตุผล:เนื่องจากตัวเลขจุดลอยตัวอาจมีข้อผิดพลาดในการปัดเศษและการตัดปลายดังนั้นจึงอาจไม่สามารถสร้างความเท่าเทียมกันได้แม้จะเป็นไปตามที่คาดไว้ก็ตาม

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

ตอนนี้มาทำสิ่งนี้กันเถอะ!

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

กล่าวอีกนัยหนึ่งคุณจะต้องแนะนำกฎเกณฑ์ให้กับมาตรฐานการเข้ารหัสซึ่งมีลักษณะที่ถูกต้องตามกฎหมายและมีโอกาสที่ดีในการได้รับการยอมรับจากสมาชิกของคณะกรรมการอื่น ๆ หลังจากที่โครงการเริ่มต้นขึ้นและมีการลงทุนจำนวนชั่วโมงในรหัสคุณควรจะสามารถใช้กฎเหล่านี้ในทางที่ผิด (ตัวอย่างเช่นโดยเทคนิคหรือโดยมากการตีความตามตัวอักษร) เพื่อตั้งค่าสถานะรหัสอื่นที่มีคุณภาพดีและไม่เป็นไปตามมาตรฐาน ดังนั้นพวกเขาจึงต้องใช้ความพยายามอย่างมากในการออกแบบใหม่และกฎจะขัดขวางพวกเขาจากจุดนี้ แต่เมื่อกฎมีการใช้งานมาระยะหนึ่งแล้วโมเมนตัมบริสุทธิ์จะทำให้บทบาทเหล่านี้มีชีวิตอยู่และเนื่องจากมีความขัดแย้งที่สำคัญ ผลประโยชน์ระหว่างระดับการจัดการที่แตกต่างกันผู้จัดการคนอื่นอาจจะรักษากฎชีวิตไว้ (พวกเขาจะโง่เขลาที่จะยอมรับความผิดพลาดของพวกเขา!) ดังนั้นขัดขวาง บริษัท ! Mwahahahahaaa!

เกณฑ์การให้คะแนน

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

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

กฎและข้อบังคับ

• กฎหรือกฎต้องดูอย่างมืออาชีพเช่นในตัวอย่างด้านบน
• กฎควรมีลักษณะเป็นของแท้ (ดังนั้นสิ่งต่าง ๆ เช่น"ตัวแปรทั้งหมดจะต้องมีขีดล่างอย่างน้อยหนึ่งตัวอักษรตัวพิมพ์ใหญ่หนึ่งตัวอักษรตัวพิมพ์เล็กและตัวเลขสองตัว"ไม่ได้รับการยอมรับพวกเขาจะขัดขวางผู้พัฒนาอย่างแน่นอน คณะกรรมการ) และหากบุญไม่ชัดเจนทันทีคุณควรให้เหตุผลที่ดี
• คุณควรหาวิธีใช้ / ใช้กฎของคุณในทางที่ผิดเพื่อก่อวินาศกรรมผู้พัฒนาในภายหลัง คุณอาจใช้ความคลุมเครือในกฎอื่น ๆ ในทางที่ผิดหรือคุณอาจใช้กฎหลายข้อที่ไม่เป็นอันตรายต่อตัวเอง
• คุณควรโพสต์คำอธิบายในแท็กสปอยเลอร์ที่ส่วนท้ายของโพสต์เกี่ยวกับวิธีการใช้กฎที่ผิด
• ภาษาที่ใช้ต้องไม่เป็นภาษาที่ลึกลับ ต้องเลือกภาษาที่ใช้กันอย่างแพร่หลายในโครงการจริงดังนั้นควรเลือกภาษาที่มีรูปแบบ C-like (แทนที่จะเป็นอย่าง Golfscript)

C / C ++

กฎข้อที่ 1:ค่าคงที่ฐานแปดจะไม่ถูกนำมาใช้

เหตุผล: ค่าคงที่เลขฐานแปดอาจเป็นสาเหตุของความสับสน ตัวอย่างเช่นภาพรวมแบบไม่เป็นทางการเหนือเส้น const int coefficients[] = {132, 521, 013, 102};
อาจพลาดข้อเท็จจริงที่ว่าหนึ่งในตัวเลขในอาเรย์ถูกกำหนดไว้ในฐานแปด

หากคุณต้องการเป็นคนชั่วร้ายยิ่งขึ้นเพิ่มสิ่งต่อไปนี้:

กฎข้อที่ 2:ค่าคงที่เลขฐานสิบหกจะใช้ในบริบทของการจัดการบิตเท่านั้น

เหตุผล: หากค่าคงที่แสดงค่าตัวเลขจะสามารถอ่านได้ง่ายกว่าถ้าเป็นทศนิยม ค่าคงที่เลขฐานสิบหกควรระบุว่ามันแทนบิตมาสก์ไม่ใช่ค่าตัวเลข

วิธีที่จะถูกทำร้าย:

ใช้โปรแกรมอย่างง่ายต่อไปนี้ซึ่งจะเพิ่ม 10 องค์ประกอบแรกของอาร์เรย์ รหัสนี้จะไม่เป็นไปตามมาตรฐาน

sum = 0;
for (i = 0; i < 10; i++) 
{
    sum += array[i];
}

หมายเหตุนั่น0คือตามคำจำกัดความค่าคงที่ฐานแปด ตามกฎที่ 1 ซึ่งกำหนดให้เขียนเป็น 0x00 ทั้งหมดผ่านรหัสนี้เป็นที่น่าผิดหวัง ตามกฎ 2 ทำให้น่าผิดหวังยิ่งขึ้น

หลาม

กฎข้อที่ 1: รหัสทั้งหมดจะต้องถูกคอมไพล์ด้วยไบต์โดยใช้-OOแฟล็กซึ่งปรับให้เหมาะสมกับไบต์ เราต้องการไบต์ที่เพิ่มประสิทธิภาพสำหรับขนาดและประสิทธิภาพ!

กฎข้อที่ 2: การทดสอบจะต้องทำงานกับ "ส่วน" เดียวกันของรหัสที่จะนำไปผลิต ผู้ตรวจสอบของเราต้องการสิ่งนี้

การใช้-OOลบassertข้อความสั่ง เมื่อรวมกับกฎ 2 สิ่งนี้จึงห้ามการใช้assertข้อความในการทดสอบอย่างมีประสิทธิภาพ มีความสุข!

นี่เป็นโครงการ Node.JS

ส่วนที่ 3 - ความเร็วและประสิทธิภาพเป็นสิ่งสำคัญ

กฎ 3.1:ไฟล์ควรถูกเก็บไว้สูงสุดไม่เกิน 1kb ไฟล์ที่ใหญ่กว่านี้ใช้เวลาในการวิเคราะห์นานเกินไป

กฎ 3.2:อย่าซ้อนฟังก์ชันที่มีความลึกมากกว่า 3 ระดับ เอนจิ้น V8 ต้องติดตามตัวแปรหลายตัวและการปิดอย่างลึกเช่นนี้ทำให้ทำงานหนักขึ้นทำให้การตีความทั่วไปช้าลง

กฎ 3.3:หลีกเลี่ยงrequire()runarounds

กฎ 3.3.1:โมดูลใด ๆ ที่require()ไม่ควรrequire()มีความลึกมากกว่า 3 require()โซ่ลึกมีราคาแพงทั้งในแง่ของการใช้หน่วยความจำและความเร็ว

กฎ 3.3.2:โมดูลหลักนับเป็นหนึ่งเดียวrequire()ไม่ว่าจะอยู่require()ภายในกี่ครั้งก็ตาม

กฎ 3.3.3:โมดูลภายนอกนับเป็นสูงสุด 2 require()s เราไม่สามารถผ่อนปรนเช่นเดียวกับโมดูลหลัก แต่สามารถสันนิษฐานได้ว่าผู้เขียนโมดูลกำลังเขียนโค้ดที่มีประสิทธิภาพ

กฎ 3.4:หลีกเลี่ยงการโทรแบบซิงโครนัสทุกครั้ง สิ่งเหล่านี้มักจะใช้เวลานานและป้องกันการวนซ้ำของเหตุการณ์ทั้งหมด

วิธีที่จะถูกทำร้าย:

กฎ 3.1 และ 3.3 ทำงานร่วมกันได้ไม่ดี โดยการทำให้require()โซ่ลงได้มากสุด 1kb และ 3 วินาทีพวกเขาจะถูกกดให้ประสบความสำเร็จ
กฎ 3.2 และ 3.4 เกือบเข้ากันไม่ได้ 3.4 การโทรแบบซิงโครนัส 3.2 ทำให้การทำงานแบบอะซิงโครนัสขั้นสูงทำได้ยากโดย จำกัด จำนวนการโทรกลับ
กฎ 3.4 คือความซื่อสัตย์กฎที่ดีที่จะปฏิบัติตามจริง 3.1, 3.2 และ 3.3 เป็นของปลอมโดยสมบูรณ์

JavaScript (ECMAScript)

7.3.2: ตัวอักษรนิพจน์ปกติ

ต้องไม่ใช้ตัวอักษรนิพจน์ปกติ รหัสแหล่งที่มาต้องไม่ประกอบด้วยสตริงย่อยใด ๆ ที่ตรงกับRegularExpression nonterminal ที่กำหนดด้านล่าง

RegularExpression     :: '/' RegularExpressionBody '/'
RegularExpressionBody :: [empty]
                         RegularExpressionBody [any-but-'/']

[empty]จับคู่สตริงว่างและ[any-but - '/']จับคู่สตริงอักขระเดี่ยวใด ๆ ยกเว้นสตริงที่มี '/' (สแลชU+002F)

หลักการและเหตุผล

นิพจน์ทั่วไปมักไม่ได้รับการสนับสนุนเนื่องจากเหตุผลในการอ่าน บ่อยครั้งที่จะเข้าใจรหัสได้ง่ายขึ้นด้วยการดำเนินการกับสตริงแบบดั้งเดิมแทนที่จะใช้การแสดงออกปกติ อย่างไรก็ตามที่สำคัญกว่านั้นเอ็นจิ้นนิพจน์ทั่วไปจำนวนมากเสนอประสิทธิภาพ subpar นิพจน์ทั่วไปนั้นเชื่อมโยงกับปัญหาด้านความปลอดภัยในบริบทของ JavaScript

อย่างไรก็ตาม Organisation ™ตระหนักว่าการแสดงออกปกติบางครั้ง เป็นเครื่องมือที่ดีที่สุดสำหรับงาน ดังนั้นRegExpวัตถุจึงไม่ถูกห้าม

(ไวยากรณ์ของข้อความที่ตัดตอนมาเอง [ไม่ใช่สิ่งที่นิยาม] สอดคล้องกับข้อกำหนดของ ECMAScript แน่นอนว่าเรื่องนี้จะต้องถูกกำหนดอย่างเข้มงวดมากขึ้นในอีกจุดหนึ่งของข้อกำหนดสมมุติฐาน)

เคล็ดลับ

โปรแกรมต่อไปนี้ไม่สอดคล้อง:

// sgn(x) is -1 if x < 0, +1 if x > 0, and 0 if x = 0.
function sgn(x) {
  return x > 0?  +1
       : x < 0?  -1
       :          0
}

โปรดักชั่นสำหรับRegular ExpressionBody nonterminal ที่ระบุด้านบนแสดงวิธีการทั่วไปของการแสดงรายการใน BNF โดยอาศัยการสอบถามซ้ำอย่างชัดเจน เคล็ดลับที่นี่คือฉัน "ตั้งใจ" อนุญาตสตริงที่ว่างเปล่าเป็นRegularExpressionBodyเช่นว่า//ห้ามใช้สตริงในซอร์สโค้ด แต่ใครต้องการความเห็นแบบบรรทัดเดียวล่ะ? C89 และ CSS ดูเหมือนจะทำถูกต้องทั้งหมดในขณะที่อนุญาตเฉพาะ/* */บล็อกความคิดเห็น

C #

12.1 วิธีการคงที่ที่มีผลต่อสถานะของโปรแกรมเป็นสิ่งต้องห้าม

นี่เป็นเพราะมันยากที่จะทดสอบผลลัพธ์ของวิธีการแบบคงที่ได้อย่างน่าเชื่อถือโดยเฉพาะอย่างยิ่งวิธีการที่เปลี่ยนแปลงสถานะบางอย่าง

12.2 วิธีการคงที่จะต้องกำหนดไว้ล่วงหน้า

หากวิธีสแตติกใช้อินพุตและให้เอาต์พุตผลลัพธ์ต้องเหมือนกันทุกครั้งที่สแตติกเรียกว่าด้วยอินพุตเดียวกัน

ทำไม

จุดเริ่มต้นสำหรับโปรแกรม C # เป็นวิธีการคงที่ส่วนตัว 'หลัก' โดยกฎข้อแรกสิ่งนี้ถูกห้ามในขณะนี้เพราะกฎลืมสถานะว่าวิธีสาธารณะการป้องกันหรือภายในควรปฏิบัติตามกฎนี้ หากการทดสอบเป็นเรื่องที่น่ากังวลเพียงวิธีสาธารณะควรปฏิบัติตามกฎ 1 ข้อหลักอาจผิดกฎ 2 เนื่องจากโปรแกรมจะให้รหัสข้อผิดพลาดหากโปรแกรมล้มเหลวสิ่งนี้อาจเกิดขึ้นโดยไม่ขึ้นอยู่กับพารามิเตอร์อินพุต ตัวอย่างเช่นโปรแกรมอาจไม่พบไฟล์หรืออาจมีการพึ่งพาระบบอื่น ๆ ที่ไม่ได้ติดตั้งอย่างถูกต้อง

Java / SPRING

4.2 การใช้การสะท้อนในรหัสการผลิต

เนื่องจากสามารถใช้การสะท้อนการเข้าถึงส่วนที่ จำกัด ของการใช้การสะท้อนกลับในรหัสการผลิตของเราเป็นสิ่งต้องห้ามอย่างเคร่งครัด

เคล็ดลับ

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

การเข้ารหัสเว็บไซต์

666.13 ต้องไม่ใช้ UTF-8 และจะถูกแทนที่ด้วย
เหตุผลUTF-7 : UTF-7 มีประสิทธิภาพมากกว่า UTF-8 โดยเฉพาะเมื่อกำหนดเป้าหมายผู้ใช้จากประเทศอาหรับที่เราทำ

วิธีที่จะถูกทำร้าย:

HTML5 ไม่อนุญาต UTF-7 โดยเฉพาะ นั่นหมายความว่าเบราว์เซอร์สมัยใหม่จะไม่สนับสนุน หากการทดสอบทั้งหมดเสร็จสิ้นบนเบราว์เซอร์เช่น IE 11 จะไม่มีใครสังเกตเห็นสิ่งนี้จนกว่าจะสายเกินไป

ตัวดำเนินการ JavaScript ระดับบิต

1.9 คุณจะต้องไม่ใช้การคูณหรือการหารหรือการปูพื้นเว้นแต่ว่าพวกเขาจะเร็วกว่าของพวกเขาบิต พวกเขาจะถูกแทนที่ด้วยตัวดำเนินการระดับบิต <<, >> และ ~~ ตามลำดับ
เหตุผล: ผู้ประกอบการระดับบิตมีประสิทธิภาพมากขึ้น

วิธีที่จะถูกทำร้าย:

การใช้ << หรือ >> แทนการคูณหรือการหารจะทำให้เกิดปัญหาเมื่อจัดการจำนวนมาก นอกจากนี้ยังละเว้นการดำเนินการก่อนหน้าและจุดทศนิยม เครื่องหมายตัวหนอนคู่จะส่งกลับค่าที่แตกต่างกันเมื่อคุณให้จำนวนลบ

JavaScript (ECMAScript)

7.3.1: อนุสัญญาบ่งชี้

ข้อ จำกัด จะอยู่ในตัวระบุขึ้นอยู่กับชนิดของตัวระบุ ตัวบ่งชี้จะแบ่งออกเป็นประเภทตัวแปร , คง , ฟังก์ชั่นและการสร้าง ; ดู 5.3 ข้อ จำกัด ได้รับด้านล่าง

• ตัวแปร: ตัวอักษรตัวแรกจะต้องเป็นตัวอักษรตัวพิมพ์เล็ก ควรใช้Camel-case (ดู 1.3) เพื่อแยกคำภายในตัวระบุ

• ค่าคงที่: ตัวระบุต้องประกอบด้วยตัวอักษรตัวพิมพ์ใหญ่และเครื่องหมายขีดล่าง ('_', U+005F) เท่านั้น ควรใช้เครื่องหมายขีดล่างเพื่อแยกคำในตัวระบุ

• ฟังก์ชั่น: ฟังก์ชั่นจะต้องปฏิบัติตามกฎเดียวกันกับ ประเภทตัวระบุ

• ตัวสร้าง: ตัวอักษรตัวแรกจะต้องเป็นตัวอักษรตัวพิมพ์ใหญ่ ควรใช้Camel-case (ดู 1.3) เพื่อแยกคำภายในตัวระบุ

หลักการและเหตุผล

ชื่อตัวระบุที่อ่านได้มีความสำคัญมากสำหรับการบำรุงรักษา การ จำกัด ตัวบ่งชี้ให้เป็นแบบแผนที่รู้จักกันดีช่วยลดการเปลี่ยนระหว่างรหัสฐานที่แตกต่างกัน การประชุมโดยเฉพาะอย่างยิ่งเหล่านี้จะตามหลังการประชุมมาตรฐานสำหรับ Java ™การเขียนโปรแกรมภาษา[1]

เคล็ดลับ

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