thực hành mã hóa phòng thủ

Question

Kể từ lần đầu tiên tôi đã viết

if ($a = 5) { 
    # do something with $a, e.g. 
    print "$a"; 
} 

và đã trải qua phiên đánh đố bình thường của

• tại sao là kết quả luôn luôn đúng
• tại sao là $ a luôn 5

cho đến khi tôi nhận ra, tôi đã chỉ định 5 đến $ a, thay vì thực hiện so sánh.

Vì vậy, tôi quyết định viết rằng loại tình trạng trên như

if (5 == $a) 

nói cách khác:

luôn đặt giá trị không đổi sang phía bên trái của toán tử so sánh, dẫn đến một lỗi biên dịch , bạn nên quên thêm dấu "=" thứ hai.

tôi có xu hướng để gọi mã hóanày phòng thủ và có xu hướng tin rằng đó là một người anh họ để phòng thủ-lập trình, không phải trên quy mô thuật toán, nhưng từ khóa theo từ khóa.

Bạn đã phát triển những phương pháp mã hóa phòng thủ nào?

---

Một tuần sau:

Một lớn "cảm ơn" để tất cả những ai đã trả lời hoặc có thể thêm câu trả lời khác trong tương lai.

Thật không may (hoặc khá may mắn thay!) Không có câu trả lời đúng nào. Đối với câu hỏi của tôi là để rộng, yêu cầu nhiều hơn cho ý kiến ​​hoặc học hỏi kinh nghiệm, chứ không phải là sự kiện.

Answer 1

Đây là một cách đơn giản và rõ ràng, nhưng tôi KHÔNG BAO GIỜ BAO GIỜ KHÔNG BAO GIỜ lặp lại cùng một chuỗi hai lần trong mã của mình, vì tôi BIẾT rằng nếu tôi làm tôi sẽ đánh vần một trong số chúng sai :) Sử dụng hằng số, mọi người!

Answer 2

tôi đã ngừng sử dụng ngôn ngữ mà bạn có thể làm

if a = 5: print a 

này đã cứu tôi tấn đau đầu =).

Lưu ý nghiêm trọng hơn ... Bây giờ tôi luôn viết các dấu ngoặc nhọn ngay sau khi tôi viết các vòng if s và for của mình rồi điền vào sau đó. Điều này đảm bảo rằng các dấu ngoặc của tôi luôn được căn chỉnh.

Answer 3

Luôn đặt dấu ngoặc nhọn sau một if/for/while ... ngay cả khi chỉ có một câu lệnh duy nhất sau đó. BTW D. Crockford cũng nghĩ rằng nó tốt hơn: Required blocks

Answer 4

Trả lại bản sao của đối tượng có thể thay đổi, tức là bản sao của một mảng, không phải chính đối tượng có thể thay đổi.

Answer 5

Luôn luôn sử dụng niềng răng:

if(boolean) 
    oneliner(); 
nextLineOfCode(); 

là không giống nhau như:

if(boolean) 
{ 
    oneliner(); 
} 
nextLineOfCode(); 

Nếu oneliner() là một hàm #defined, và nó không được định nghĩa thì dòng tiếp theo của bạn mã đột nhiên trở thành đối tượng if(). Điều tương tự cũng áp dụng đối với cho vòng vv Với niềng răng thì mảnh tiếp theo của mã không bao giờ vô tình trở thành điều kiện trên nếu/cho, vv

Answer 6

Các top 3 thực hành mã hóa phòng thủ tôi sử dụng là

1. kiểm tra đơn vị
2. kiểm tra đơn vị
3. kiểm tra đơn vị

không có bảo vệ tốt hơn về chất lượng mã của bạn hơn là một thử nghiệm đơn vị tốt để trở lại bạn lên.

Answer 7

Tránh kiểm tra không cần thiết. Ví dụ

1. if (bool == true)
2. kiểm tra Pointer if (con trỏ)

EDIT: if (con trỏ) là không thể đọc được vì hiện nay tôi thích if (NULL = con trỏ)

Answer 8

Couple điều:

• Vâng, các khối 1-line. Sử dụng niềng răng ... heck, hầu hết các IDE tốt sẽ làm cho bạn cho bạn.
• Nhận xét mã của bạn sau khi bạn viết hoặc đọc lại nhận xét của bạn nếu bạn đã đọc trước. Hãy chắc chắn rằng mã của bạn vẫn làm những gì các ý kiến ​​nói.
• Kiểm tra đơn vị là một dự phòng tuyệt vời để đọc lại mã của bạn.
• Luôn đăng nhập ngoại lệ ... hoặc, KHÔNG BAO GIỜ bắt ngoại lệ mà không nói như vậy, ít nhất là trong gỡ lỗi.

Answer 9

• Luôn khởi tạo các biến
• Sử dụng const bất cứ nơi nào tôi có thể (không sử dụng mutable)
• Tránh giao năng động trần bộ nhớ hoặc các nguồn lực khác
• Luôn luôn sử dụng dấu ngoặc nhọn
• Mã trường hợp sử dụng và kiểm tra cho bất kỳ lớp nào trước khi thực hiện mã hóa
• Bật nhiều cảnh báo hữu ích nhất có thể (Tối thiểu)
• Sử dụng công cụ đơn giản nhất giải quyết được vấn đề (trong môi trường hiện tại của tôi, đó là bash ->grep -> awk -> Python -> C++).

Answer 10

Cá nhân, tôi không thích kiểu phòng thủ này, nó làm cho mã khó đọc.

Mức cảnh báo trình biên dịch VC 4 sẽ phát hiện lỗi này (có thể).
"cảnh báo C4706: phân công trong biểu thức điều kiện"

Bạn có thể bật chỉ cảnh báo trình biên dịch cụ thể này, tại bất kỳ cấp độ:

#pragma warning(3,4706) 

Answer 11

Khi so sánh một chuỗi với một hằng số, viết

if ("blah".equals(value)){} 

thay vì

if (value.equals("blah")){} 

để ngăn chặn một NullPointerException. Nhưng đây là lần duy nhất tôi sử dụng kiểu mã hóa được đề nghị (nguyên nhân "nếu (a = 1) ..." là không thể trong Java).

Answer 12

Một trong những điều tôi luôn cố gắng nhớ khi tôi ở trong thế giới Javascript là luôn luôn bắt đầu giá trị trả về của một hàm trên cùng một dòng với từ khóa trả về.

function one(){ 
    return { 
     result:"result" 
    }; 
} 

function two(){ 
    return 
    { 
     result:"result" 
    }; 
} 

Hai chức năng này sẽ không trả lại cùng một giá trị. Hàm đầu tiên sẽ trả về một đối tượng có kết quả thuộc tính được đặt thành "kết quả". Hàm thứ hai sẽ trả về undefined. Đó là một sai lầm thực sự đơn giản và điều đó xảy ra vì chiến lược Chèn-Đại Toàn cầu của Ghen. Bán dấu hai chấm là bán tùy chọn trong Javascript và vì điều này, công cụ Javascript sẽ thêm các dấu chấm than bán ở nơi mà nó cho là cần. Bởi vì return thực sự là một câu lệnh hợp lệ, một dấu chấm phẩy sẽ được chèn sau câu lệnh return và phần còn lại của hàm về cơ bản sẽ bị bỏ qua.

Answer 13

Từ blog của tôi:

1. suy nghĩ tích cực và trở về đầu cộng tránh làm tổ sâu. Thay vì

   if (giá trị! = Null) { ... làm điều gì đó có giá trị ... } trở

   ghi

   if (giá trị == null) { trở } ... làm điều gì đó có giá trị ...

2. Tránh "hằng số chuỗi" (nghĩa là văn bản giống nhau trong dấu ngoặc kép ở nhiều nơi). Luôn xác định một hằng số thực (với tên và chú thích tùy chọn ý nghĩa của nó) và sử dụng nó.

Answer 14

cài đặt Resharper;) Sau đó, tôi không cần phải viết "5 == một" để cảnh báo nếu tôi đã làm điều gì sai :)

Answer 15

Một số gợi ý cho lập trình C nhúng trong bài viết Rules for Defensive C Programming từ embedded.com.