Lập trình viên tại NASA là 1 trong những công việc thử thách nhất trong thế giới lập trình. Họ viết code và lập trình các ứng dụng mang nhiệm vụ cực kỳ quan trọng với sự an toàn là mối quan tâm chính của họ.
Trong các tình huống nhất định, điều quan trọng là phải luôn làm theo các hướng dẫn code 1 cách nghiêm ngặt. Các quy tắc này bao gồm các khía cạnh khác nhau của việc lập trình phần mềm như việc 1 phần mềm được viết ra như thế nào, các tính năng ngôn ngữ nào nên được sử dụng v…v…
Cho dù rất khó để thiết lập sự đồng nhất về tiêu chuẩn cho code tốt là như thế nào, Phòng thí nghiệm Sức đẩy phản lực – Jet Propulsion Laboratory (gọi tắt là JPL) làm theo 1 set các hướng dẫn code được gọi là ‘Sức mạnh của 10 quy tắc cho Lập trình code tới hạn an toàn – The Power of Ten-Rules for Developing Safety Critical Code’.
Bảng hướng dẫn tập trung phổ biến với code được viết bằng ngôn ngữ lập trình C nhờ sự kết hợp có thâm niên với ngôn ngữ này của JPL. Nhưng, những hướng dẫn này có thể dễ dàng áp dụng trên các ngôn ngữ lập trình khác nữa.
Được trả lời bởi nhà khoa học đứng đầu của JPL, Gerald J. Holzmann, những quy tắc code nghiêm ngặt này tập trung vào sự bảo mật.
10 quy tắc để viết code cho các nhiệm vụ quan trọng của NASA:
- Hạn chế tất cả code thành những cấu trúc dòng điều khiển tối giản – không được dùng các statement goto, cấu trúc setjmp hay longjmp, và đệ quy trực tiếp hay gián tiếp.
- Tất cả vòng lặp phải có giới hạn trên mức cố định. Công cụ kiểm tra phải có khả năng chứng minh 1 cách static rằng 1 preset trên mức cố định trên số lần iteration của vòng lặp không thể bị vượt quá. Nếu giới hạn vòng lặp không thể được chứng minh static, quy tắc được xem là đã vi phạm.
- Không sử dụng sự phân bổ bộ nhớ dynamic sau khi khởi tạo.
- Không có function nào được dài hơn những gì được in trên 1 tờ giấy ở định dạng tham chiếu tiêu chuẩn với 1 line trên mỗi statement và 1 line trên mỗi declaration. Thông thường, điều này có nghĩa là không quá 60 line code cho mỗi function.
- Mật độ xác nhận của code phải trung bình tối thiểu là 2 assertion cho mỗi function. Assertion được dùng để kiểm tra các điều kiện bất thường vốn không nên xảy ra trong việc thực thi ngoài đời thực. Assertion phải luôn không kèm theo các tác dụng phụ và nên được xác định như là Boolean test. Khi assertion thất bại, 1 hành động phục hồi rõ ràng phải được thực hiện, ví dụ: bằng cách trả về 1 điều kiện error cho caller của function mà thực thi assertion thất bại. Bất kỳ assertion cho cái mà tool kiểm tra static có thể chứng minh rằng nó có thể không bao giờ thất bại hay không bao giờ quy phạm quy tắc này (tức là, không thể thỏa mãn quy tắc này bằng cách thêm các statement “assert(true)” vô ích).
- Các đối tượng dữ liệu phải được khai báo ở phạm vi có mức độ nhỏ nhất có thể.
- Giá trị trả về của các non-void function phải được kiểm tra bởi mỗi calling function, và tính hợp lệ của các tham số phải được kiểm tra bên trong mỗi function.
- Việc sử dụng preprocessor phải được giới hạn dựa theo việc bao gồm các tệp tiêu đề và các định nghĩa macro đơn giản. Việc dán Token hay variable argument list (dấu chấm lửng) hoặc các call macro đệ quy không được cho phép. Tất cả các macro phải mở rộng thành các đơn vị cú pháp hoàn chỉnh. Việc sử dụng các chỉ thị compile có điều kiện cũng thường không rõ ràng, nhưng không thể luôn tránh được. Điều này có nghĩa là sự chứng minh cho nhiều hơn 1 hay 2 chỉ thị compile có điều kiện nên hiếm khi xảy ra trong effort lập trình phần mềm lớn, vượt ra ngoài boilerplate tiêu chuẩn để tránh đưa vào cùng 1 tệp tiêu đề. Mỗi lần sử dụng như vậy phải được đánh dấu cờ bởi trình kiểm tra dựa trên bộ công cụ và được chứng minh trong code đó.
- Việc sử dụng pointer nên bị hạn chế. Đặc biệt, chỉ được cho phép không quá 1 level của dereferencing. Pointer dereference operations không thể được ẩn trong macro definitions hay bên trong typedef declarations. Các pointer function cũng không được cho phép.
- Tất cả code phải được compile, từ ngày đầu lập trình, với tất cả compiler warning được kích hoạt tại cài đặt mô phạm nhất của compiler. Tất cả code phải compile với những cài đặt này mà không được dính bất kỳ warning nào. Tất cả code phải được kiểm tra hàng ngày ít nhất 1 lần, nhưng tốt hơn là nên nhiều hơn 1, static source code analyzer tiên tiến nhất và nên vượt qua được phần phân tích với 0 warning.
Đây là những gì NASA nên nói về những quy tắc này:
Những quy tắc này cũng giống như cài seatbelt trong chiếc xe hơi của bạn vậy: Ban đầu chúng có thể hơi khó chịu, nhưng sau 1 thời gian sử dụng chúng trở thành bản chất thứ hai và sẽ khó mà tưởng tượng ra điều gì sẽ xảy ra nếu bạn không sử dụng chúng.
Theo Alt Bulletin
