สิ่งใดที่กริ่งสัญญาณเตือนทันทีเมื่อดูรหัส? [ปิด]

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

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

ฉันจะเริ่มต้นด้วยสิ่งที่ง่าย:

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

/* Fuck this error */

โดยทั่วไปมักพบในtry..catchบล็อกไร้สาระก็มีแนวโน้มที่จะดึงดูดความสนใจของฉัน /* Not sure what this does, but removing it breaks the build */เพียงเกี่ยวกับเช่นเดียวกับ

อีกสองสิ่ง:

• ifคำสั่งที่ซับซ้อนหลายระดับซ้อนกัน
• Try-catch blocks ที่ใช้เพื่อกำหนดลอจิกโฟลว์เป็นประจำ
• ฟังก์ชั่นที่มีชื่อทั่วไปprocess, data, change, rework,modify
• รูปแบบการค้ำยันหกหรือเจ็ดแบบใน 100 บรรทัด

หนึ่งที่ฉันเพิ่งค้นพบ:

/* Stupid database */
$conn = null;
while(!$conn) {
    $conn = mysql_connect("localhost", "root", "[pass removed]");
}
/* Finally! */
echo("Connected successfully.");

ถูกต้องเพราะต้องดุร้ายบังคับให้การเชื่อมต่อ MySQL ของคุณเป็นวิธีที่ถูกต้องในการทำสิ่งต่างๆ ปรากฎว่าฐานข้อมูลมีปัญหากับจำนวนการเชื่อมต่อดังนั้นพวกเขาจึงหมดเวลา แทนที่จะแก้จุดบกพร่องนี้พวกเขาเพียงแค่พยายามอีกครั้งและอีกครั้งจนกว่ามันจะทำงาน

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

ฉันเคยนับว่าไม่มีความคิดเห็นเป็นธงสีแดง แต่เมื่อไม่นานมานี้ได้ทำงานกับโค้ดที่ดีมาก ๆ โดยที่ไม่มีความคิดเห็นใดที่ฉันได้ปลดเปลื้องไปแล้ว

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

x ^= y ^= x ^= y;

• ฟังก์ชันบรรทัด 20,000 (พูดเกินจริง) ฟังก์ชั่นใด ๆ ที่ใช้เวลามากกว่าสองหน้าจอจำเป็นต้องมีแฟคตอริ่งใหม่

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

• ตัวแปรที่ไม่อธิบาย, ไม่ใช่ตัวแปร, หรือตัวแปรที่ไม่อธิบายมากเกินไป สิ่งเหล่านี้ทำให้การอนุมานสิ่งที่เกิดขึ้นจริงเป็นปริศนา

{ Let it Leak, people have good enough computers to cope these days }

สิ่งที่แย่กว่านั้นคือจากห้องสมุดเชิงพาณิชย์!

ความคิดเห็นที่ละเอียดมากว่าถ้ามีคอมไพเลอร์ภาษาอังกฤษมันจะคอมไพล์และทำงานได้อย่างสมบูรณ์แบบ แต่ก็ไม่ได้อธิบายสิ่งที่โค้ดไม่ได้

//Copy the value of y to temp.
temp = y;
//Copy the value of x to y.
y = x;
//Copy the value of temp to x.
x = temp;

นอกจากนี้ความคิดเห็นเกี่ยวกับรหัสที่สามารถทำได้โดยมีรหัสปฏิบัติตามหลักเกณฑ์พื้นฐานบางอย่าง:

//Set the age of the user to 13.
a = 13;

รหัสที่สร้างคำเตือนเมื่อรวบรวม

ฟังก์ชั่นที่มีตัวเลขในชื่อแทนที่จะมีชื่ออธิบายเช่น:

void doSomething()
{
}

void doSomething2()
{
}

กรุณาทำให้ชื่อฟังก์ชั่นมีความหมายอะไรบางอย่าง! ถ้า doSomething และ doSomething2 ทำสิ่งที่คล้ายกันให้ใช้ชื่อฟังก์ชันที่แยกความแตกต่าง ถ้า doSomething2 เป็นฟังก์ชันที่แยกออกจาก doSomething ให้ตั้งชื่อสำหรับการทำงานของมัน

หมายเลข Magicหรือ Magic Strings

   if (accountBalance>200) { sendInvoice(...); }

   salesPrice *= 0.9;   //apply discount    

   if (invoiceStatus=="Overdue") { reportToCreditAgency(); }

• อาจไม่ใช่ระดับที่แย่ที่สุด แต่แสดงระดับผู้ใช้งานอย่างชัดเจน:

  if(something == true) 

• หากภาษานั้นมีโครงสร้าง for for หรือ iterator ดังนั้นการใช้ a while loop จะแสดงให้เห็นถึงระดับความเข้าใจของผู้ใช้ภาษา:

  count = 0; 
  while(count < items.size()){
     do stuff
     count ++; 
  }
  
  for(i = 0; i < items.size(); i++){
    do stuff 
  }
  //Sure this is not terrible but use the language the way it was meant to be used.

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

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

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

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

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

เมื่อพิจารณาโค้ดขั้นสูงเพิ่มเติมนี่คือคำเตือนอื่น ๆ ของฉัน:

• การมีคลาส Java จำนวนมากที่เป็น "structs" เท่านั้นเพื่อเก็บข้อมูล ไม่สำคัญว่าฟิลด์จะเป็นแบบสาธารณะหรือส่วนตัวและใช้ getters / setters แต่ก็ไม่น่าจะเป็นส่วนหนึ่งของการออกแบบที่ดี
• คลาสที่มีชื่อไม่ดีเช่นเพิ่งเป็นเนมสเปซและไม่มีการเชื่อมโยงกันอย่างแท้จริงในโค้ด
• อ้างอิงถึงรูปแบบการออกแบบที่ไม่ได้ใช้ในรหัส
• ตัวจัดการข้อยกเว้นว่างเปล่าโดยไม่มีคำอธิบาย
• เมื่อฉันดึงรหัสใน Eclipse สีเหลือง "คำเตือน" เรียงแถวโค้ดส่วนใหญ่เกิดจากการนำเข้าหรือตัวแปรที่ไม่ได้ใช้

ในแง่ของสไตล์ฉันมักไม่ชอบที่จะเห็น:

• ความคิดเห็น Javadoc ที่สะท้อนรหัสเท่านั้น

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

ส่วนบุคคลที่ชื่นชอบ / สัตว์เลี้ยงโกรธ: IDE สร้างชื่อที่ได้รับ comitted ถ้า TextBox1 เป็นตัวแปรที่สำคัญและสำคัญในระบบของคุณคุณจะได้รับสิ่งใหม่ ๆ ที่กำลังทบทวนโค้ด

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

ผู้คนมากมายพูดถึง:

//TODO: [something not implemented]

ในขณะที่ฉันหวังว่าสิ่งต่าง ๆ จะถูกนำไปใช้อย่างน้อยพวกเขาก็จดบันทึก สิ่งที่ฉันคิดว่าแย่ลงคือ:

//TODO: [something that is already implemented]

สิ่งที่ต้องทำไม่มีค่าและสับสนหากคุณไม่เคยสนใจที่จะลบออก!

วิธีที่ต้องให้ฉันเลื่อนลงเพื่ออ่านทั้งหมด

คำสันธานในชื่อเมธอด:

public void addEmployeeAndUpdatePayrate(...) 


public int getSalaryOrHourlyPay(int Employee) ....

ชี้แจงเหตุนี้แหวนระฆังปลุกก็คือว่ามันแสดงให้เห็นวิธีการที่มีแนวโน้มละเมิดหลักการรับผิดชอบเดียว

เห็นได้ชัดว่าการเชื่อมโยงซอร์สโค้ด GPL กับโปรแกรมเชิงพาณิชย์และปิด

ไม่เพียง แต่จะสร้างปัญหาทางกฎหมายในทันที แต่จากประสบการณ์ของฉันมันมักจะบ่งบอกถึงความประมาทหรือความไม่สนใจซึ่งจะปรากฏที่อื่นในรหัสเช่นกัน

ผู้ไม่เชื่อเรื่องภาษา:

• TODO: not implemented
• int function(...) { return -1; } (เช่นเดียวกับ "ไม่ใช้งาน")
• โยนข้อยกเว้นด้วยเหตุผลที่ไม่พิเศษ
• ในทางที่ผิดหรือการใช้งานที่ไม่สอดคล้องกันของ0, -1หรือnullค่ากลับมาเป็นพิเศษ
• ยืนยันโดยไม่ต้องแสดงความคิดเห็นที่น่าเชื่อถือบอกว่าทำไมมันไม่ควรล้มเหลว

ภาษาเฉพาะ (C ++):

• C ++ แมโครเป็นตัวพิมพ์เล็ก
• ตัวแปร C ++ คงที่หรือทั่วโลก
• ตัวแปรที่ไม่ได้กำหนดค่าหรือไม่ได้ใช้
• สิ่งใดก็ตามarray newที่เห็นว่าไม่ปลอดภัย RAII
• การใช้อาเรย์หรือตัวชี้ใด ๆ ที่เห็นได้ชัดว่าไม่ปลอดภัย printfซึ่งรวมถึง
• การใช้งานส่วนที่ไม่ได้กำหนดค่าเริ่มต้นของอาร์เรย์

เฉพาะ Microsoft C ++:

• ชื่อตัวระบุใด ๆ ที่ชนกับมาโครที่กำหนดไว้แล้วโดยไฟล์ส่วนหัวของ Microsoft SDK ใด ๆ
• โดยทั่วไปการใช้ Win32 API เป็นแหล่งสัญญาณเตือนภัยขนาดใหญ่ เปิด MSDN เสมอและค้นหาอาร์กิวเมนต์ / คำนิยามค่าที่ส่งคืนเมื่อใดก็ตามที่มีข้อสงสัย (แก้ไข)

เฉพาะ C ++ / OOP:

• การใช้งาน (คลาสคอนกรีต) การสืบทอดที่คลาสพาเรนต์มีทั้งวิธีเสมือนและไม่เสมือนโดยไม่มีความแตกต่างทางแนวคิดที่ชัดเจนระหว่างสิ่งที่ควร / ไม่ควรเป็นเสมือน

สไตล์การเยื้องที่แปลกประหลาด

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

การใช้บล็อคข้อความจำนวนมากแทนที่จะใช้ enums หรือตัวแปรที่กำหนดไว้ทั่วโลก

ไม่ดี:

if (itemType == "Student") { ... }

ที่ดีกว่า:

private enum itemTypeEnum {
  Student,
  Teacher
}
if (itemType == itemTypeEnum.Student.ToString()) { ... }

ที่ดีที่สุด:

private itemTypeEnum itemType;
...
if (itemType == itemTypeEnum.Student) { ... }

พารามิเตอร์ที่พิมพ์อ่อนแอหรือคืนค่าตามวิธีการ

public DataTable GetEmployees() {...}

public DateTime getHireDate(DataTable EmployeeInfo) {...}

public void FireEmployee(Object EmployeeObjectOrEmployeeID) {...}

• ผู้ประกอบการที่ประกอบไปด้วยกันหลายคนหงุดหงิดดังนั้นแทนที่จะคล้ายif...elseบล็อกมันกลายเป็นif...else if...[...]...elseบล็อก
• ชื่อตัวแปรแบบยาวที่ไม่มีขีดล่างหรือ camelCasing ตัวอย่างจากรหัสฉันดึงขึ้นมา:$lesseeloginaccountservice
• บรรทัดของโค้ดหลายร้อยบรรทัดในไฟล์ที่มีความคิดเห็นเพียงเล็กน้อยและไม่มีเลยและโค้ดนั้นไม่ชัดเจนมาก
• ifข้อความที่ซับซ้อนมากเกินไป ตัวอย่างจากรหัส: if (!($lessee_obj instanceof Lessee && $lessee_obj != NULL))ซึ่งฉัน chomped ลงไปif ($lessee_obj == null)

กลิ่นรหัส: ไม่ปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุด

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

นี่คือข่าวด่วนสำหรับยา: 50% ของประชากรโลกต่ำกว่าความฉลาดโดยเฉลี่ย ตกลงดังนั้นบางคนก็จะมีความฉลาดโดยเฉลี่ย แต่เราจะไม่เลือก อีกด้านหนึ่งที่มีผลต่อความโง่เขลาคือคุณจำตัวเองไม่ได้ว่าโง่เขลา! สิ่งต่างๆดูไม่ดีนักถ้าคุณรวมข้อความเหล่านี้เข้าด้วยกัน

สิ่งใดที่กริ่งสัญญาณเตือนทันทีเมื่อดูรหัส?

มีการพูดถึงสิ่งดี ๆ มากมายและโดยทั่วไปดูเหมือนว่าการไม่ปฏิบัติตามวิธีปฏิบัติที่ดีที่สุดคือกลิ่นรหัส

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

ตัวอย่างหนึ่งของแนวปฏิบัติที่ดีที่สุดอาจใช้ curlies กับ if-block ทุกรายการแม้ว่าจะมีเพียงหนึ่งบรรทัด:

if (something) {
    // whatever
}

คุณอาจไม่คิดว่ามันจำเป็น แต่เมื่อเร็ว ๆ นี้ฉันอ่านว่ามันเป็นแหล่งสำคัญของข้อบกพร่อง การใช้วงเล็บยังถูกกล่าวถึงในStack Overflowเสมอและตรวจสอบว่า if-statement มีวงเล็บเป็นกฎในPMDตัววิเคราะห์โค้ดแบบคงที่สำหรับ Java

โปรดจำไว้ว่า: "เพราะเป็นวิธีปฏิบัติที่ดีที่สุด" ไม่ใช่คำตอบที่ยอมรับได้สำหรับคำถาม "ทำไมคุณถึงทำเช่นนี้" หากคุณไม่สามารถระบุได้ว่าทำไมบางสิ่งถึงเป็นแนวปฏิบัติที่ดีที่สุดนั่นก็ไม่ใช่แนวปฏิบัติที่ดีที่สุดนั่นคือความเชื่อโชคลาง

ความคิดเห็นที่บอกว่า "นี่เป็นเพราะการออกแบบของระบบย่อย froz นั้นเต็มไปด้วยบอร์ก"

ที่ดำเนินต่อไปในย่อหน้าทั้งหมด

พวกเขาอธิบายว่า refactor ต่อไปนี้จำเป็นต้องเกิดขึ้น

แต่ไม่ได้ทำ

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

หากหัวหน้างานคิดว่า j.random โปรแกรมเมอร์ไม่สามารถทำการปรับโครงสร้างใหม่ได้จากนั้นหัวหน้างานควรทำ

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

เรื่องจริง. มันอาจจะเกิดขึ้นกับคุณ.

ทุกคนสามารถนึกถึงตัวอย่างที่รหัสควรอ้างถึงไฟล์อย่างถูกต้องตามเส้นทางที่แน่นอน?

การจับข้อยกเว้นทั่วไป:

try {

 ...

} catch {
}

หรือ

try {

 ...

} catch (Exception ex) {
}

ภูมิภาคมากเกินไป

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

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

ตัวอย่างที่เด่นชัดขึ้นมาในชั้นเรียน VB ที่ฉันเห็นครั้งหนึ่งเคยมีชื่อว่าDataและมีความยาวมากกว่า 30,000 บรรทัด ... ในไฟล์แรก มันเป็นชั้นบางส่วนแบ่งออกเป็นอย่างน้อยครึ่งโหลไฟล์อื่น ๆ ส่วนใหญ่ของวิธีการที่ถูกห่อรอบ procs FindXByYWithZ()เก็บที่มีชื่อเหมือน

แม้จะมีตัวอย่างที่น่าทึ่งน้อยกว่าฉันแน่ใจว่าเราทุกคนแค่ 'ทิ้ง' ตรรกะในชั้นเรียนที่ไม่ดีให้มันเป็นชื่อสามัญทั้งหมดและเสียใจในภายหลัง

ฟังก์ชั่นที่ปรับใช้การทำงานพื้นฐานของภาษาอีกครั้ง ตัวอย่างเช่นหากคุณเคยเห็นเมธอด "getStringLength ()" ใน JavaScript แทนที่จะเรียกใช้คุณสมบัติ ".length" ของสตริงคุณจะรู้ว่าคุณกำลังมีปัญหา

#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...

แน่นอนโดยไม่ต้องใด ๆ ของเอกสารและบางครั้งซ้อนกัน#defines