แนวทางปฏิบัติที่ดีที่สุดในการเขียนโปรแกรมป้องกัน (โปรดปิด)

หากคุณต้องเลือกเทคนิคที่คุณโปรดปราน (ฉลาด) เพื่อป้องกันการเข้ารหัสพวกเขาจะเป็นอย่างไร? แม้ว่าภาษาปัจจุบันของฉันคือ Java และ Objective-C (มีพื้นหลังเป็น C ++) แต่สามารถตอบได้ทุกภาษา เน้นที่นี่จะเป็นเทคนิคการป้องกันที่ฉลาดกว่าที่ 70% + ของเราที่นี่รู้อยู่แล้ว ดังนั้นถึงเวลาขุดลึกลงไปในกระเป๋าของคุณ

กล่าวอีกนัยหนึ่งลองนึกถึงตัวอย่างที่ไม่น่าสนใจ :

• if(5 == x) แทน if(x == 5) : เพื่อหลีกเลี่ยงการมอบหมายที่ไม่ได้ตั้งใจ

นี่คือตัวอย่างของวิธีปฏิบัติในการตั้งโปรแกรมการป้องกันที่น่าสนใจ (ตัวอย่างเฉพาะภาษามีอยู่ใน Java):

- ล็อคตัวแปรของคุณจนกว่าคุณจะรู้ว่าคุณต้องเปลี่ยนพวกเขา

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

public void foo(final int arg) { /* Stuff Here */ }

- เมื่อมีสิ่งเลวร้ายเกิดขึ้นให้ทิ้งหลักฐานไว้ข้างหลัง

มีหลายสิ่งที่คุณสามารถทำได้เมื่อคุณมีข้อยกเว้น: การเข้าสู่ระบบอย่างเห็นได้ชัดและทำการล้างข้อมูลบางอย่างอาจเป็นเพียงเล็กน้อย แต่คุณสามารถทิ้งหลักฐานไว้ได้ (เช่นการตั้งค่าตัวแปรให้กับค่าของ Sentinel เช่น "UNABLE TO LOAD FILE" หรือ 99999 จะมีประโยชน์ในตัวดีบักในกรณีที่คุณเกิดข้อcatchผิดพลาดผ่านบล็อก -block)

- เมื่อพูดถึงเรื่องความมั่นคง: มารอยู่ในรายละเอียด

สอดคล้องกับไลบรารีอื่น ๆ ที่คุณใช้อยู่ ตัวอย่างเช่นใน Java หากคุณกำลังสร้างวิธีที่แยกช่วงของค่าจะทำให้ขอบเขตที่รวมต่ำกว่าและขอบเขตพิเศษด้านบนพิเศษสิ่งนี้จะทำให้สอดคล้องกับวิธีการต่าง ๆString.substring(start, end)ซึ่งทำงานในลักษณะเดียวกัน คุณจะพบกับวิธีการเหล่านี้ทั้งหมดใน Sun JDK ที่จะทำงานในลักษณะนี้เนื่องจากมันทำให้การดำเนินการต่างๆรวมถึงการวนซ้ำขององค์ประกอบที่สอดคล้องกับอาร์เรย์โดยที่ดัชนีมาจากศูนย์ ( รวม ) ถึงความยาวของอาร์เรย์ ( พิเศษ )

ดังนั้นอะไรคือแนวปฎิบัติการป้องกันที่คุณโปรดปราน

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

ใน c ++ ฉันเคยชอบนิยามใหม่เพื่อให้หน่วยความจำพิเศษบางอย่างเพื่อตรวจจับข้อผิดพลาดโพสต์รั้ว

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

ในฐานะ WikiKnowledge Wrote :

หลีกเลี่ยงการเขียนโปรแกรมการป้องกันล้มเหลวอย่างรวดเร็วแทน

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

SQL

เมื่อฉันต้องลบข้อมูลฉันเขียน

select *    
--delete    
From mytable    
Where ...

เมื่อฉันเรียกใช้ฉันจะรู้ว่าฉันลืมหรือไม่เรียบร้อยส่วนคำสั่งที่ ฉันมีความปลอดภัย หากทุกอย่างเรียบร้อยฉันจะเน้นทุกสิ่งหลังจากสัญลักษณ์ความคิดเห็น "-" และเรียกใช้

แก้ไข: หากฉันลบข้อมูลจำนวนมากฉันจะใช้จำนวน (*) แทนที่จะเป็น *

จัดสรรหน่วยความจำที่เหมาะสมเมื่อแอปพลิเคชันเริ่มต้น - ฉันคิดว่า Steve McConnell เรียกสิ่งนี้ว่าเป็นร่มชูชีพหน่วยความจำใน Code Complete

สามารถใช้ในกรณีที่มีข้อผิดพลาดร้ายแรงและคุณจำเป็นต้องยกเลิก

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

• บันทึกข้อมูลถาวรทั้งหมด
• ปิดไฟล์ที่เหมาะสมทั้งหมด
• เขียนข้อความผิดพลาดไปยังไฟล์บันทึก
• นำเสนอข้อผิดพลาดที่มีความหมายกับผู้ใช้

ในทุกคำสั่งสวิตช์ที่ไม่มีตัวพิมพ์เริ่มต้นฉันเพิ่มเคสที่ยกเลิกโปรแกรมด้วยข้อความแสดงข้อผิดพลาด

#define INVALID_SWITCH_VALUE 0

switch (x) {
case 1:
  // ...
  break;
case 2:
  // ...
  break;
case 3:
  // ...
  break;
default:
  assert(INVALID_SWITCH_VALUE);
}

เมื่อคุณจัดการสถานะต่าง ๆ ของ enum (C #):

enum AccountType
{
    Savings,
    Checking,
    MoneyMarket
}

จากนั้นภายในกิจวัตรประจำวัน ...

switch (accountType)
{
    case AccountType.Checking:
        // do something

    case AccountType.Savings:
        // do something else

    case AccountType.MoneyMarket:
        // do some other thing

    default:
-->     Debug.Fail("Invalid account type.");
}

ในบางจุดฉันจะเพิ่มประเภทบัญชีอื่นให้กับ enum นี้ และเมื่อฉันทำฉันจะลืมแก้ไขคำสั่งเปลี่ยนนี้ ดังนั้นการDebug.Failล่มจึงน่ากลัว (ในโหมด Debug) เพื่อดึงดูดความสนใจของฉันกับความจริงนี้ เมื่อฉันเพิ่มcase AccountType.MyNewAccountType:ความล้มเหลวที่น่ากลัวจะหยุด ... จนกว่าฉันจะเพิ่มประเภทบัญชีอื่นและลืมอัปเดตเคสที่นี่

(ใช่แตกต่างกันน่าจะดีกว่าที่นี่ แต่นี่เป็นเพียงตัวอย่างจากส่วนบนของหัวของฉัน)

เมื่อพิมพ์ข้อความผิดพลาดกับสตริง (โดยเฉพาะอย่างใดอย่างหนึ่งซึ่งขึ้นอยู่กับการป้อนข้อมูลของผู้ใช้) ''ผมมักจะใช้ราคาเดียว ตัวอย่างเช่น:

FILE *fp = fopen(filename, "r");
if(fp == NULL) {
    fprintf(stderr, "ERROR: Could not open file %s\n", filename);
    return false;
}

การขาดเครื่องหมายอัญประกาศรอบ ๆ%sนี้ไม่ดีนักเนื่องจากการพูดชื่อไฟล์เป็นสตริงว่างหรือเพียงแค่ช่องว่างหรืออะไรบางอย่าง แน่นอนข้อความที่พิมพ์ออกมาจะเป็น:

ERROR: Could not open file

ดังนั้นดีกว่าที่จะทำ:

fprintf(stderr, "ERROR: Could not open file '%s'\n", filename);

อย่างน้อยผู้ใช้จะเห็นสิ่งนี้:

ERROR: Could not open file ''

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

ความปลอดภัยของ SQL

ก่อนที่จะเขียน SQL ใด ๆ ที่จะแก้ไขข้อมูลฉันจะสรุปสิ่งทั้งหมดในธุรกรรมย้อนกลับ:

BEGIN TRANSACTION
-- LOTS OF SCARY SQL HERE LIKE
-- DELETE FROM ORDER INNER JOIN SUBSCRIBER ON ORDER.SUBSCRIBER_ID = SUBSCRIBER.ID
ROLLBACK TRANSACTION

สิ่งนี้จะป้องกันไม่ให้คุณดำเนินการลบ / อัปเดตที่ไม่ดีอย่างถาวร และคุณสามารถดำเนินการทั้งหมดและตรวจสอบการบันทึกที่เหมาะสมนับหรือเพิ่มSELECTคำสั่งระหว่าง SQL ของคุณและROLLBACK TRANSACTIONเพื่อให้แน่ใจว่าทุกอย่างดูถูกต้อง

เมื่อคุณสมบูรณ์แน่ใจว่ามันไม่สิ่งที่คุณคาดว่าจะเปลี่ยนROLLBACKไปCOMMITและเรียกใช้จริง

สำหรับทุกภาษา:

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

เมื่อมีข้อสงสัยให้ทิ้งระเบิดแอปพลิเคชัน!

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

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

ใน Java โดยเฉพาะอย่างยิ่งกับคอลเลกชันให้ใช้ API ดังนั้นหากวิธีการของคุณส่งคืนรายการประเภท (ตัวอย่าง) ให้ลองทำดังต่อไปนี้:

public List<T> getList() {
    return Collections.unmodifiableList(list);
}

อย่าปล่อยให้สิ่งใดหลบหนีชั้นเรียนของคุณที่คุณไม่ต้องการ!

ใน Perl ทุกคนทำ

use warnings;

ฉันชอบ

use warnings FATAL => 'all';

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

use warnings FATAL => 'all';
...
my $string = getStringVal(); # something bad happens;  returns 'undef'
print $string . "\n";        # code dies here

ค#:

string myString = null;

if (myString.Equals("someValue")) // NullReferenceException...
{

}

if ("someValue".Equals(myString)) // Just false...
{

}

ในการตรวจสอบ c # ของสตริง IsNullOrEmpty ก่อนทำการดำเนินการใด ๆ กับสตริงเช่นความยาว, indexOf, mid ฯลฯ

public void SomeMethod(string myString)
{
   if(!string.IsNullOrEmpty(myString)) // same as myString != null && myString != string.Empty
   {                                   // Also implies that myString.Length == 0
     //Do something with string
   }
}

[แก้ไข]
ตอนนี้ฉันยังสามารถทำสิ่งต่อไปนี้ใน. NET 4.0 ซึ่งจะตรวจสอบเพิ่มเติมว่าค่านั้นเป็นเพียงช่องว่างหรือไม่

string.IsNullOrWhiteSpace(myString)

ใน Java และ C # ให้ทุกชื่อด้ายมีความหมาย ซึ่งรวมถึงเธรดพูลเธรด มันทำให้กองมีความหมายมากขึ้น มันต้องใช้ความพยายามมากขึ้นเพียงเล็กน้อยที่จะให้ชื่อมีความหมายกับหัวข้อสระว่ายน้ำแม้ด้าย แต่ถ้าสระด้ายหนึ่งที่มีปัญหาในการประยุกต์ใช้การทำงานนานผมสามารถทำให้กองถ่ายโอนข้อมูลที่จะเกิดขึ้น (คุณรู้เกี่ยวกับSendSignal.exeใช่มั้ย? ) คว้าล็อกและโดยไม่ต้องขัดจังหวะระบบที่กำลังทำงานฉันสามารถบอกได้ว่าเธรดใดคือ ... อะไรก็ตาม การหยุดชะงักการรั่วไหลการเติบโตสิ่งที่เป็นปัญหา

ด้วย VB.NET ให้ Option Explicit และ Option Strict เปิดเป็นค่าเริ่มต้นสำหรับ Visual Studio ทั้งหมด

C ++

#define SAFE_DELETE(pPtr)   { delete pPtr; pPtr = NULL; }
#define SAFE_DELETE_ARRAY(pPtr) { delete [] pPtr; pPtr = NULL }

จากนั้นแทนที่การเรียก ' ลบ pPtr ' และ ' ลบ [] pPtr ' ของคุณด้วยSAFE_DELETE (pPtr)และSAFE_DELETE_ARRAY (pPtr)

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

ด้วย Java คุณสามารถใช้ประโยชน์จากคีย์เวิร์ด assert ได้แม้ว่าคุณจะเรียกใช้โค้ดการผลิตที่ปิดการยืนยันแล้ว:

private Object someHelperFunction(Object param)
{
    assert param != null : "Param must be set by the client";

    return blahBlah(param);
}

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

ฉันไม่พบreadonlyคำหลักจนกว่าฉันจะพบ ReSharper แต่ตอนนี้ฉันใช้มันโดยสัญชาตญาณโดยเฉพาะอย่างยิ่งสำหรับชั้นเรียนบริการ

readonly var prodSVC = new ProductService();

ใน Java เมื่อมีบางสิ่งเกิดขึ้นและฉันไม่รู้ว่าทำไมบางครั้งฉันจะใช้ Log4J ดังนี้:

if (some bad condition) {
    log.error("a bad thing happened", new Exception("Let's see how we got here"));
}

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

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

ตัวอย่าง:

class Foo
{
   virtual void DoSomething();
}

class Bar: public Foo
{
   void DoSomething() override { /* do something */ }
}

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

สิ่งนี้ได้ช่วยแยกแยะสภาพการแข่งขันและเงื่อนไขการล๊อคหลอกที่ไม่น่าเชื่อก่อนที่ฉันจะเริ่มทำสิ่งนี้

ค#

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

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

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

ใน C # ให้ใช้asคำสำคัญเพื่อส่ง

string a = (string)obj

จะโยนข้อยกเว้นถ้า obj ไม่ใช่สตริง

string a = obj as string

จะปล่อยให้เป็นโมฆะถ้า obj ไม่ใช่สตริง

คุณยังคงต้องคำนึงถึง null แต่โดยทั่วไปแล้วจะตรงไปข้างหน้ามากขึ้นแล้วมองหาข้อยกเว้น cast บางครั้งคุณต้องการพฤติกรรมประเภท "cast or blow up" ซึ่งเป็นกรณี(string)objที่ต้องการไวยากรณ์

ในรหัสของฉันฉันพบว่าฉันใช้asไวยากรณ์ประมาณ 75% ของเวลาและ(cast)ไวยากรณ์ประมาณ 25%

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

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

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

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

ในข้อผิดพลาดในการเขียนโปรแกรม 25 อันดับแรกที่อันตรายที่สุด "การตรวจสอบอินพุตที่ไม่เหมาะสม" เป็นข้อผิดพลาดที่อันตรายที่สุดในส่วน "การโต้ตอบที่ไม่ปลอดภัยระหว่างส่วนประกอบ"

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

เพื่อที่จะใช้ค่าคงที่ฉันเขียนวิธีการในชั้นเรียนใด ๆ ที่ตรวจสอบ "ความสอดคล้องระดับ" ที่ควรจะเรียกว่าอัตโนมัติโดยเงื่อนไขก่อนและมาโคร postcondition

ผมประเมินห้องสมุดสัญญารหัส

ชวา

java api ไม่มีแนวคิดของวัตถุที่ไม่เปลี่ยนรูปซึ่งไม่ดี! รอบชิงชนะเลิศสามารถช่วยคุณได้ในกรณีนี้ แท็กทุกชั้นเรียนที่ไม่เปลี่ยนรูปด้วยรอบชิงชนะเลิศและเตรียมชั้นเรียนตามนั้น

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

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

ไม่เคยใช้โคลนใช้ตัวสร้างสำเนา

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

ฉันลืมเขียนechoPHP หลายครั้งเกินไป:

<td><?php $foo->bar->baz(); ?></td>
<!-- should have been -->
<td><?php echo $foo->bar->baz(); ?></td>

มันจะพาฉันไปตลอดกาลเพื่อลองคิดดูว่าทำไม -> baz () ไม่ได้กลับมาอะไรเลยในความเป็นจริงฉันแค่ไม่ได้สะท้อน! : -S ดังนั้นฉันจึงสร้างEchoMeคลาสที่สามารถห่อหุ้มคุณค่าที่ควรสะท้อน:

<?php
class EchoMe {
  private $str;
  private $printed = false;
  function __construct($value) {
    $this->str = strval($value);
  }
  function __toString() {
    $this->printed = true;
    return $this->str;
  }
  function __destruct() {
    if($this->printed !== true)
      throw new Exception("String '$this->str' was never printed");
  }
}

จากนั้นสำหรับสภาพแวดล้อมการพัฒนาฉันใช้ EchoMe เพื่อห่อสิ่งที่ควรพิมพ์:

function baz() {
  $value = [...calculations...]
  if(DEBUG)
    return EchoMe($value);
  return $value;
}

การใช้เทคนิคนั้นตัวอย่างแรกที่ขาดหายไปechoจะทำให้เกิดข้อยกเว้น ...

C ++

เมื่อฉันพิมพ์ใหม่ฉันต้องพิมพ์ลบทันที โดยเฉพาะอย่างยิ่งสำหรับอาร์เรย์

ค#

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

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

นอกจากนี้ 'strace -p [pid]' บน linux จะแสดงว่าคุณต้องการให้ระบบเรียกใช้กระบวนการ (หรือเธรด linux) มันอาจดูแปลกในตอนแรก แต่เมื่อคุณคุ้นเคยกับการเรียกของระบบโดยการเรียกใช้ libc คุณจะพบว่าสิ่งนี้มีค่าสำหรับการวินิจฉัยภาคสนาม