มาตรฐานการเข้ารหัสที่แย่ที่สุดที่คุณเคยทำตาม? [ปิด]

คุณเคยทำงานกับมาตรฐานการเข้ารหัสที่:

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

ถ้าเป็นเช่นนั้นกฎข้อใดข้อหนึ่งที่คุณชอบน้อยที่สุดและทำไม?

ตัวอย่างบางส่วนที่นี่

สิ่งนี้อาจทำให้ขนไม่กี่ตัว แต่มาตรฐานที่กำหนดความคิดเห็นบล็อกเทมเพลตที่ด้านบนของแต่ละวิธีมักจะดักอึออกจากฉันเสมอ

1) พวกเขาล้าสมัยอยู่เสมอเพราะรหัสเหล่านี้ทำงานเกินกว่าที่จะแจ้งให้ทราบเมื่อคุณกำลังอัพเดทสิ่งต่าง ๆ ความคิดเห็นที่ไม่ดีนั้นเลวร้ายยิ่งกว่าความคิดเห็นใด ๆ

2) พวกเขามักจะทำซ้ำข้อมูลที่มีเครื่องมือควบคุมแหล่งข้อมูลอยู่แล้วซึ่งมีความแม่นยำน้อยกว่า ตัวอย่างเช่น: แก้ไขครั้งสุดท้ายโดยรายการวันที่แก้ไข / เหตุผล

มีอาจารย์หนึ่งครั้งที่เรียกร้องเรามีความคิดเห็นอย่างน้อยหนึ่งข้อสำหรับแต่ละบรรทัดของรหัส

//Set x to 3
var x = 3;

//if x is greater than 2
if(x>2){

    //Print x
    Print(x);
}

มันไร้สาระทีเดียว

มาตรฐานการเข้ารหัส บริษัท ของเรา (C #) เรียกว่าการใช้งานอย่างครอบคลุมของ #REGIONs (สำหรับผู้ที่ไม่ทราบว่าจะทำเครื่องหมายบล็อกของซอร์สโค้ดที่จะยุบตัวเป็นบรรทัดเดียวใน Visual Studio) ด้วยเหตุนี้คุณจึงเปิดสิ่งที่ดูเหมือนว่าจะเป็นคลาสที่มีโครงสร้างอย่างดีเสมอเพื่อค้นหากองและกองขยะกวาดใต้พรมที่ซ้อนกันอย่างลึกล้ำของ #REGION constructs คุณอาจมีพื้นที่รอบ ๆ บรรทัดเดียวเช่นต้องย่อส่วนของ LOG เพื่อย่อเพื่อค้นหาการประกาศเพียงครั้งเดียวของ Logger แน่นอนว่ามีวิธีการมากมายที่เพิ่มเข้ามาหลังจากที่บางพื้นที่ถูกวางไว้ในขอบเขตของ "ผิด" เช่นกัน สยองขวัญ. สยองขวัญ.

ภูมิภาคเป็นหนึ่งในคุณสมบัติที่แย่ที่สุดที่เคยเพิ่มเข้าไปใน Visual Studio มันสนับสนุนโครงสร้างพื้นผิวมากกว่าโครงสร้าง OO จริง

ทุกวันนี้ฉันฆ่า #REGIONs ตามที่เห็น

ในงานเดียวเราถูกบังคับให้ใช้สัญกรณ์ฮังการีบางรูปแบบในฐานข้อมูล

ฉันจำรายละเอียดไม่ได้ แต่จากหน่วยความจำชื่อแต่ละฟิลด์ต้องมี:

• ไม่มีสระ
• ตัวอักษรตัวพิมพ์ใหญ่ทั้งหมด
• การอ้างอิงถึงตาราง
• ตัวบ่งชี้ชนิดข้อมูล
• ความยาวข้อมูล
• ตัวบ่งชี้ nullable

ตัวอย่างเช่นคอลัมน์ที่มีชื่อแรกของบุคคลนั้นอาจถูกเรียกว่า: PRSNFRSTNMVC30X(ตารางบุคคล, คอลัมน์ชื่อ, Varchar 30 ตัวอักษร, ไม่เป็นโมฆะ)

ยืนยันว่าการจัดฟันทั้งหมดตามด้วยความคิดเห็นสำหรับสิ่งที่วงเล็บปีกกาสิ้นสุดลง:

เช่น:

for (int i = 0; i < 10; i++)
{
    if (foo > bar)
    {
        printf("Foo greater than bar");
    } // End If (foo > bar)

    while (baz)
    {
       farb();
    } // End while (baz)
} // End For

#define AND  &&
#define OR   ||
#define EQ   ==

'Nuff กล่าวว่า.

• ชื่อตัวแปรท้องถิ่นเป็นตัวพิมพ์เล็กทั้งหมดโดยไม่มีขีดล่าง

ตัวอย่างจริง: paymentmethodtotalshtml, contracttypechangecontexts, customsegmentspectexts,potentialmsceventref

New York Times มีน้ำหนัก :

“ ไม่ควรใช้ช่องว่างของ Word เพื่อรับสิทธิ์ กรีกโบราณตัวอักษรตัวแรกของสระสามารถถอดรหัสได้โดยไม่ต้องเว้นวรรคหากคุณออกเสียงออกมาและไม่ได้ใช้ […] ละตินก็หยุดแยกคำในศตวรรษที่สอง การสูญเสียนั้นทำให้งงเพราะตาต้องทำงานหนักกว่ามากในการอ่านข้อความที่ไม่คั่น แต่ดังที่พอลซาเคอนักอธิบายเรื่องโลกยุคโบราณไม่ต้องการ 'ทำให้การอ่านง่ายขึ้นและเร็วขึ้น'”

ฉันถูกถามโดยผู้นำซอฟแวร์ของ บริษัท ที่จะทำ " ง่ายอีกnรหัส dundant " มันเป็นสิ่งต้องห้ามเช่นการเพิ่มพารามิเตอร์ใหม่ให้กับฟังก์ชั่นที่มีอยู่ คุณต้องทำซ้ำฟังก์ชั่นโดยปล่อยให้ไม่มีใครแตะต้องต้นฉบับเพื่อหลีกเลี่ยงการถดถอย ไม่มีการทดสอบแน่นอน (เสียเวลา)

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

วันที่มีความสุขที่สุดในชีวิตของฉันคือเมื่อเขาถูกไล่ออก (พิจารณาว่าเป็นเรื่องยากมากที่จะยิงใครบางคนในอิตาลี)

ปฏิสัมพันธ์กับฐานข้อมูลทั้งหมดจะต้องมีการดำเนินการผ่านวิธีการจัดเก็บ มันอาจสมเหตุสมผลถ้าเราอยู่ในปี 1997 ไม่ใช่ปี 2010

ฉันเพิ่งรู้ว่าสิ่งนี้ครอบคลุมถึงเกณฑ์ทั้งหมดของคำถามเดิม:

• ลดประสิทธิภาพการทำงานลงอย่างมากใช่ไหม ตรวจสอบ โปรด - เพียงแค่ใช้ออม
• ตอนแรกมีการรวมไว้ด้วยเหตุผลที่ดี แต่ถูกเก็บรักษาไว้นานหลังจากความกังวลดั้งเดิมกลายเป็นสิ่งที่ไม่เกี่ยวข้องหรือไม่? ตรวจสอบ ผู้จัดการเป็นผู้พัฒนาเซิร์ฟเวอร์ฐานข้อมูลเมื่อ 1,000 ปีที่แล้วและวางมาตรฐานการเข้ารหัสนี้
• อยู่ในรายการนานมากจนเป็นไปไม่ได้ที่จะจดจำพวกเขาทั้งหมดหรือไม่? ตรวจสอบ ซึ่งรวมถึง 'ลอจิกมากควรเก็บไว้ในฐานข้อมูลที่เป็นไปได้'
• ทำให้คุณคิดว่าผู้แต่งพยายามที่จะทิ้งเครื่องหมายไว้แทนที่จะให้กำลังใจการเขียนโปรแกรมที่ดี? ตรวจสอบ ทำให้กลับมาที่ผู้จัดการเป็นผู้พัฒนาเซิร์ฟเวอร์ฐานข้อมูล
• คุณไม่รู้ว่าทำไมรวมอยู่ด้วย? ตรวจสอบ

ไม่ได้รับอนุญาตให้ใช้ STL หรือไลบรารี C ++ มาตรฐานอื่น ๆ เนื่องจาก CTO เชื่อว่า 'เรา' สามารถทำได้ดีขึ้นและเร็วขึ้น แม้แต่โครงสร้างพื้นฐานเช่นรายการและคลาสสตริง

สัญกรณ์ฮังการี

ตัวอย่างที่แยกออกมาจาก " Charles Simonyi การอธิบายของแบบแผนการระบุชื่อตัวบ่งชี้ฮังการี " บน MSDN

1 # รวม“ sy.h”
2 int ภายนอก * rgwDic;
3 ภายนอก bsyMac;
4 struct SY * PsySz (char sz [])
6 {
7 ถ่าน * pch;
8 int cch;
9 struct SY * psy, * PsyCreate ();
10 int * pbsy;
11 int cwSz;
12 wHash ที่ไม่ได้ลงชื่อ = 0;
13 pch = sz;
14 ในขณะที่ (* pch! = 0
15 wHash = (wHash11 + * pch ++;
16 cch = pch-sz;
17 pbsy = & rgbsyHash [(wHash & 077777)% cwHash];
18 สำหรับ (; * pbsy! = 0; pbsy = & psy-> bsyNext)
19 {
20 ถ่าน * szSy;
21 szSy = (psy = (struct SY *) & rgwDic [* pbsy]) -> sz;
22 pch = sz;
23 ในขณะที่ (* pch == * szSy ++)
24 {
25 ถ้า (* pch ++ == 0)
26 return (psy);
27}
28}
29 cwSz = 0;
30 ถ้า (cch> = 2)
31 cwSz = (cch-2 / sizeof (int) +1;
32 * pbsy = (int *) (psy = PsyCreate (cwSY + cwSz)) - rgwDic;
33 ศูนย์ ((int *) psy, cwSY);
34 bltbyte (sz, psy-> sz, cch + 1);
35 return (psy);
36}

ฉันเคยทำงานในโครงการที่นำโครงการบังคับให้ทุกตัวแปร - ตัวแปรทุกตัว - จะขึ้นต้นด้วย "v" ดังนั้น vCount, vFirstName, vIsWarranty ฯลฯ

ทำไม? “ เพราะเรากำลังทำงานใน VBScript และทุกอย่างก็แปรปรวนอยู่แล้ว”

WTF

เกือบลืมสิ่งนี้:

อ้างจากผู้จัดการ:

อย่าแก้ไขหรือบันทึกข้อผิดพลาดใด ๆ ของปัญหาที่พบในรหัสของคุณเอง ลูกค้าจะจ่ายเงินให้เราเพื่อระบุและแก้ไขในอีกไม่กี่ปีข้างหน้า

สิ่งนี้ไม่ได้มีไว้สำหรับซอฟต์แวร์ผู้บริโภค แต่กำหนดเองสำหรับองค์กรขนาดใหญ่เดียว ลูกค้าไม่ต้องจ่ายเงินเป็นเวลาหลายปีหลังจากนั้น อาจดูเล็กน้อย แต่การพยายามละเว้นข้อบกพร่องนั้นยากกว่าการค้นหาพวกมัน

ความคิดเห็น XML ที่มีการบังคับใช้เกี่ยวกับวิธีการที่ไม่ใช่ส่วนตัวค่าคงที่ enums และคุณสมบัติทั้งหมด

มันนำไปสู่รหัสที่ค่อนข้างยุ่งเหยิงโดยเฉพาะอย่างยิ่งเนื่องจากผลลัพธ์ที่ได้คือผู้คนเพียงแค่กดปุ่ม /// เพื่อสร้าง stub ความคิดเห็นที่ว่างเปล่าสำหรับทุกสิ่งหรือติดตั้ง GhostDoc และให้เพิ่มความคิดเห็นที่สร้างขึ้นอัตโนมัติ:

/// <summary>
/// Validations the handler.
/// </summary>
/// <param name="propertyName">The property name.</param>
public void ValidationHandler(string propertyName) 
{
   // whatever
}

[แก้ไข] เหตุผลที่ฉันพูดถึงสิ่งนี้ว่าเป็นมาตรฐานที่ไร้สาระไม่ใช่เพราะฉันคิดว่าความคิดเห็นของวิธีการนั้นโง่ แต่เพราะคุณภาพของความคิดเห็นเหล่านี้ไม่ได้ถูกบังคับใช้ในทางใดทางหนึ่งและทำให้เกิดความยุ่งเหยิงมากมายในไฟล์รหัส . มีวิธีที่ดีกว่าในการสร้างเอกสารรหัสที่มีความหมายมากกว่า blind "ต้องมีความคิดเห็น" ข้อกำหนดของการสร้าง

ไม่ใช่มาตรฐานการเข้ารหัส แต่เรามีไฟล์ในตัวควบคุมแหล่งข้อมูลที่เรียกว่า 'changelog.txt'

ทุกครั้งที่คุณเช็คอินคุณต้องเพิ่มรายการในไฟล์นี้ด้วยตนเอง รายการนี้เป็นหมายเลขการแก้ไขที่ถูกโค่นล้มและความคิดเห็นในการเช็คอินของคุณ

เมื่อ CTO ใหม่เริ่มต้นและมีคนบอกเขาสิ่งนี้เขาตัดสินใจทันทีโดยผู้บริหารและกล่าวว่า "เราจะไม่ทำอีกต่อไป" และลบไฟล์ สิ่งนี้เกิดขึ้นหลายปี

สถานที่บางแห่งที่ฉันทำงานด้วยยืนยันในการแสดงความคิดเห็นรหัสที่ไม่ได้ใช้หรือเลิกใช้แทนที่จะลบออก แทนที่จะไว้วางใจ VCS สำหรับประวัติ ฯลฯ มันได้รับการดูแลรักษาอย่างเจ็บปวดในไฟล์ผ่านโค้ดที่ใส่ความเห็น

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

มาตรฐานการเข้ารหัสที่แย่ที่สุดที่ฉันเคยเข้าร่วมคือเบสโค้ดที่ไม่มีเลย ฉันควรทำตามมาตรฐานการเข้ารหัสที่ฉันไม่เห็นด้วยอย่างสมบูรณ์กว่าการทำงานในฐานรหัสที่ไม่มีเลย มันทำให้การเรียนรู้ส่วนใหม่ ๆ ของโค้ดเบสนั้นยากขึ้นมาก

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

//Changed on 2/2/2004 By Ryan Roberts for work item #2323332
Dim Some Horrendous VB
//End Changed

Oracle DBA ที่ยืนยันในการใช้ที่ถูกต้องของช่องว่างในขณะที่ 'รักษา' ฐานข้อมูลที่มีตาราง contended สูงที่มีมากกว่า 200 สาขาและ 40 ทริกเกอร์เข้ามาใกล้

ฉันทำการตรวจสอบโค้ดในโปรเจ็กต์ที่นำโดยตัวจับเวลาแรกของ C ++ ที่ตัดสินใจว่าฟังก์ชั่นสมาชิกคลาสทั้งหมดควรนำหน้าด้วยชื่อคลาสและการมองเห็น:

class MyClass
{
   public:
      void MyClass_Public_setValue(int value);
}

จะต้องเยื้องรหัสทั้งหมดโดยสี่ช่องว่าง;)

ฉันมีงานหลายปีก่อนที่รหัสของเราทั้งหมดจะต้องจัดชิดซ้าย - ไม่เยื้อง ผู้ชายที่มาพร้อมกับนโยบายนั้นไม่ชอบเลื่อนไปมาในแนวนอนเมื่อดูรหัสยาว ๆ ซึ่งเท่ากับว่ามันเล่นปิงปองด้วยสายตาของเขา

นี่เป็นตัวอย่างเพิ่มเติมว่าการไม่มีมาตรฐานการเข้ารหัสสามารถทำให้เกิดความเสียหายได้อย่างไร

ผู้รับเหมาที่ทำงานในธนาคารขนาดใหญ่ยืนยันว่าการปฏิบัติตามมาตรฐานนั้นดีที่สุดเท่าที่เคยมีมา แอปพลิเคชันนี้เขียนด้วย dBase / Clipper ซึ่งเขาเป็นผู้พัฒนาเพียงผู้เดียวและแน่นอนว่าเขาได้มาตรฐาน

• ทุกอย่างเป็นตัวพิมพ์ใหญ่ ฉันหมายถึงทุกอย่างรวมถึงความคิดเห็นที่หายากที่เขาทำ
• ไม่มีการเยื้อง
• การตั้งชื่อตัวแปรเป็นบางสิ่งบางอย่างตามแนวของ APRGNAME A = ขอบเขตของตัวแปรเช่น P สำหรับสาธารณะ PRG = อักขระสามตัวแรกของไฟล์ต้นฉบับที่สร้างตัวแปร NAME = ชื่อตัวแปรใน 6 ตัวอักษรที่เหลือที่อนุญาตให้ dBase / Clipper
• บรรทัดซอร์สโค้ด 4 และ 4 บรรทัดแรกมีความยาว 80 * ทำไม? ดังนั้นเขาจึงได้ยินเสียงเครื่องพิมพ์ดอทเมทริกซ์เริ่มต้นและสิ้นสุดการพิมพ์ไฟล์ หน่วยความจำคือโปรแกรมทั้งหมดที่พิมพ์ผ่านเมนเฟรมประจำสัปดาห์ 20,000 หน้า
• ฉันแน่ใจว่ามีอีกมากมายที่ฉันสามารถถ่ายโอนข้อมูลจากสมองของฉันได้

ฉันเป็นโปรแกรมเมอร์คนใหม่ที่สอนตัวเองในขั้นตอนนั้น แต่รู้ดีว่าไม่ควรฟังนักวิทยาศาสตร์ที่บ้าและกำจัดนรกก่อนที่ฉันจะขอทำโครงการ

และใช่เราบอกผู้บริหารว่าการปฏิบัติเหล่านี้ไม่ดี แต่มักได้รับตามปกติ "จ่ายเงินให้กับผู้รับเหมารายนี้เขาต้องรู้ว่าเขากำลังพูดถึงอะไร"

อีกหนึ่งระเบิดจากอดีตของฉัน

อ้างจากเจ้าของ บริษัท :

จะไม่มีการเขียนโค้ดโดยใช้ภาษาที่สื่อความหมายเพราะฉันทำ 25 ล้านในโครงการ {expletive} ที่เขียนด้วยภาษาจาวา

โครงการ Java เป็นระบบการซื้อขายหุ้นที่ออกแบบมาเพื่อจัดการกับหุ้นไม่กี่โหลซึ่งตอนนี้ถูกใช้เพื่อประมวลผลหลายพันรายการ แทนที่จะต้องจัดการกับข้อบกพร่องในการออกแบบหรือฮาร์ดแวร์ที่ไม่ดีทั้ง บริษัท ถูกบังคับให้เปลี่ยนแอพพลิเคชั่นที่ไม่ใช่ C / C ++ เป็น C / C ++ และการพัฒนาใหม่ทั้งหมดจะต้องอยู่ใน C / C ++ ภาษาที่สื่อความหมายแปลว่าอะไรที่ไม่ได้รวบรวมไว้และเจ้าของพิจารณาว่า Assembler, C และ C ++ ที่คอมไพล์แล้วเท่านั้น

สำหรับ บริษัท 800 คนซึ่งส่วนใหญ่ของรหัสอยู่ใน Java และ Perl นี่หมายความว่าทั้ง บริษัท ใช้เวลาส่วนใหญ่ในสองสามปีถัดไปในการเขียนโค้ดที่สมบูรณ์แบบใน C / C ++

ตลกพอเมื่อยี่สิบปีก่อนความล้มเหลวนี้ฉันอยู่ที่ บริษัท อื่นซึ่งผู้นำทางด้านเทคโนโลยีตัดสินใจว่าตรรกะการเรียงลำดับของเรา (มันเป็น Bubble Sort) จำเป็นต้องได้รับการบันทึกในแอสเซมเบลอร์แทนการแทนที่ด้วย Quick Sort เพราะ - อัลกอริทึม ไม่ปรับปรุงประสิทธิภาพ วิธีเดียวในการปรับปรุงประสิทธิภาพคือการเขียนตรรกะเดียวกันในแอสเซมเบลอร์

ในทั้งสองกรณีฉันจากไปไม่นานหลังจากผู้บงการลงมา

เช่นโปรแกรมเมอร์จำนวนมาก (แต่ไม่เพียงพอ) ฉันเกลียดการตกแต่งโค้ด มันทำให้ฉันโมโหเมื่อฉันต้องใช้คำนำหน้าเครื่องหมายดอลลาร์ ($) สำหรับชื่อตัวแปรหรือขีดเส้นใต้สำหรับตัวแปรส่วนตัวแม้จะไม่มี getters / setters หากคุณจำเป็นต้องตกแต่งโค้ดให้คุณเข้าใจแล้วคุณต้องกำจัดนรกออก!

ฉันทำงานกับระบบเว็บมาระยะหนึ่งแล้วซึ่งพารามิเตอร์ทั้งหมดที่ส่งผ่านจะต้องมีชื่อว่า P1, P2, P3 และอื่น ๆ ไม่มีโอกาสที่จะได้รู้ว่าพวกเขาอยู่ที่ไหนโดยไม่มีเอกสารประกอบ

นอกจากนี้ - แม้ว่าจะไม่ได้มาตรฐานการเข้ารหัสอย่างเคร่งครัด - ในระบบเดียวกันทุกไฟล์เดียวจะต้องมีชื่อว่า xyz0001.ext, xyz0002.ext, xyz0003.ext ฯลฯ - โดยที่ xyz เป็นรหัสสำหรับแอปพลิเคชันในตัวเอง

นี่เป็นเวลานานมาแล้ว - ปี 1976 ที่แน่นอน เจ้านายของฉันไม่เคยได้ยิน Edsger Dijkstra หรืออ่านปัญหาของ CACM แต่เขาเคยได้ยินข่าวลือจากที่หนึ่งว่า "GOTO ไม่ดี" ดังนั้นเราจึงไม่ได้รับอนุญาตให้ใช้ GOTO ในโปรแกรมภาษาโคบอลของเรา นี่คือก่อนที่ COBOL จะเพิ่ม "end if" ดังนั้นในเวลานั้นมีเพียงสองและครึ่งหนึ่งของโครงสร้างการควบคุมแบบคลาสสิกทั้งสาม (ลำดับถ้า / จาก / อื่นดำเนินการ เขาอนุญาตให้ GOTO อย่างไม่เต็มใจในโปรแกรมพื้นฐานของเราและคำแนะนำสาขาในโปรแกรมภาษา Assembler ของเรา

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

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

private string DoSomething( bool verbose )
{
    if ( verbose ) { return someString; }
    else if ( !verbose ) { return otherString; }
    else { return string.Empty; }
}

แม้แต่ReSharperก็บอกคุณว่านี่มันผิด!

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

• อย่าใช้รวมถึง ฉันชอบหน้าใหญ่หนึ่งหน้า
• แยกคำในชื่อตัวแปรและคอลัมน์ด้วยเครื่องหมายขีดล่างเสมอ (ยกเว้น isactive, firstname เป็นต้น)
• อย่าใช้ตัวย่อ - เขียนชื่อแรกเสมอ (เขามักจะเขียนชื่อและอื่น ๆ )
• อย่าใช้ชื่อที่สับสน (เช่น amount_charged และ charge_amount ซึ่งวัดได้ต่างกัน แต่เกี่ยวข้องกัน)
• อย่าใช้DIVและใช้CSSขั้นต่ำ- ใช้ตารางที่ซ้อนกันแทน (ฉันพบว่ามีหกชั้นลึกลงไปหนึ่งครั้ง)
• อย่าแคชแบบสอบถามใด ๆ เคย
• จะใช้ตัวแปรมากกว่าหนึ่งหน้าหรือไม่ ขอบเขตแอปพลิเคชัน
• แต่ละหน้าเป็นบล็อคลอง / จับของตัวเอง เราไม่ต้องการ / ต้องการเครื่องมือจัดการข้อผิดพลาดทั่วโลก

ฉันเริ่มเปลี่ยนสิ่งเหล่านี้ทันทีที่เขาเลิก

ในชีวิตของฉันในฐานะ C ++ coder มีการบังคับใช้ "กฎ" ที่น่ารังเกียจจริงๆสองประการ:

1. "เราไม่สามารถใช้ STL ได้เนื่องจาก VC ++ 4.1 ไม่รองรับ (และเราไม่สามารถเปลี่ยนเป็น VC ++ 6.0 ได้ในขณะนี้)"
2. "ไม่ไม่ใช้ QuickSort เพราะมันสามารถเป็น O (n ^ 2) ในกรณีที่ไม่ดีใช้การดำเนินการตามขั้นตอนวิธีการ heapsort ฉัน (ชื่อหัวหน้าโครงการลบ) เขียนเป็นนักเรียนนี้".

ฉันถูกบังคับให้มีเอกสาร XML สำหรับชั้นเรียนและสมาชิกชั้นเรียนทั้งหมด รวมถึงส่วนตัว ฉันได้รับการสนับสนุนให้ใช้ความคิดเห็น ghostdoc เริ่มต้น

public class User 
{
    /// <summary>
    /// the _userID
    /// </summary>
    private int _userID;
}