FOSSBYTES TECH SIMPLIFIED LOGO

quy tắc mã hóa nasaTcác nhà phát triển của NASA có một trong những công việc thách thức nhất trong thế giới lập trình. Họ viết mã và phát triển các ứng dụng quan trọng với sự an toàn là mối quan tâm chính của họ.

Trong những tình huống như vậy, điều quan trọng là phải tuân theo một số nguyên tắc viết mã nghiêm túc. Các quy tắc này bao gồm các khía cạnh khác nhau của phát triển phần mềm như cách một phần mềm nên được viết, các tính năng ngôn ngữ nên được sử dụng, v.v.

Mặc dù rất khó để thiết lập sự đồng thuận về một tiêu chuẩn mã hóa tốt, nhưng Phòng thí nghiệm Sức đẩy Phản lực của NASA (JPL) vẫn tuân theo một bộ hướng dẫn của mã được đặt tên là “Sức mạnh của Mười quy tắc để phát triển bộ quy tắc quan trọng về an toàn”.

Hướng dẫn này chủ yếu tập trung vào mã được viết bằng ngôn ngữ lập trình C do sự liên kết lâu dài của JPL với ngôn ngữ này. Tuy nhiên, những hướng dẫn này cũng có thể dễ dàng áp dụng trên các ngôn ngữ lập trình khác.

Được đưa ra bởi nhà khoa học hàng đầu JPL Gerard J. Holzmann, các quy tắc mã hóa nghiêm ngặt này tập trung vào bảo mật.

10 quy tắc viết mã quan trọng của NASA:

  1. Hạn chế tất cả mã trong các cấu trúc luồng điều khiển rất đơn giản – không sử dụng câu lệnh goto, setjmp hoặc longjmp cấu trúc, và đệ quy trực tiếp hoặc gián tiếp.
  2. Tất cả các vòng phải có một giới hạn trên. Công cụ kiểm tra phải chứng minh một cách tĩnh rằng không thể vượt quá giới hạn trên đặt trước về số lần lặp của một vòng lặp. Nếu giới hạn vòng lặp không thể được chứng minh một cách tĩnh, quy tắc được coi là vi phạm.
  3. Không sử dụng cấp phát bộ nhớ động sau khi khởi tạo.
  4. Không một hàm nào được dài hơn những gì có thể in trên một tờ giấy ở định dạng tham chiếu tiêu chuẩn với một dòng trên mỗi câu lệnh và một dòng trên mỗi tờ khai. Thông thường, điều này có nghĩa là không quá 60 dòng mã cho mỗi hàm.
  5. Mật độ xác nhận của mã phải trung bình đến tối thiểu hai xác nhận cho mỗi chức năng. Các xác nhận được sử dụng để kiểm tra các điều kiện bất thường không bao giờ xảy ra trong thực thi ngoài đời thực. Các khẳng định phải luôn không có tác dụng phụ và phải được định nghĩa là các thử nghiệm Boolean. Khi một xác nhận không thành công, một hành động khôi phục rõ ràng phải được thực hiện, ví dụ: bằng cách trả về một điều kiện lỗi cho trình gọi của hàm thực hiện xác nhận không thành công. Bất kỳ khẳng định nào mà công cụ kiểm tra tĩnh có thể chứng minh rằng nó không bao giờ có thể thất bại hoặc không bao giờ giữ được đều vi phạm quy tắc này (nghĩa là không thể đáp ứng quy tắc bằng cách thêm các câu lệnh “khẳng định (đúng)” vô ích).
  6. Các đối tượng dữ liệu phải được khai báo ở mức phạm vi nhỏ nhất có thể.
  7. Giá trị trả về của các hàm non-void phải được kiểm tra bởi mỗi hàm đang gọi và tính hợp lệ của các tham số phải được kiểm tra bên trong mỗi hàm.
  8. Việc sử dụng bộ tiền xử lý phải được giới hạn trong việc bao gồm các tệp tiêu đề và các định nghĩa macro đơn giản. Không được phép dán mã thông báo, danh sách đối số biến (dấu chấm lửng) và lệnh gọi macro đệ quy. 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ị biên dịch có điều kiện cũng thường không rõ ràng, nhưng không phải lúc nào cũng có thể tránh được. Điều này có nghĩa là hiếm khi có sự biện minh cho nhiều hơn một hoặc hai chỉ thị biên dịch có điều kiện ngay cả trong các nỗ lực phát triển phần mềm lớn, vượt ra ngoài bảng soạn sẵn tiêu chuẩn để tránh việc đưa vào cùng một tệp tiêu đề. Mỗi lần sử dụng như vậy phải được gắn cờ bởi một trình kiểm tra dựa trên công cụ và được chứng minh trong mã.
  9. Việc sử dụng con trỏ nên được hạn chế. Cụ thể, không cho phép quá một cấp độ hội nghị. Các hoạt động tham chiếu con trỏ không được ẩn trong định nghĩa macro hoặc bên trong khai báo typedef. Con trỏ hàm không được phép.
  10. Tất cả mã phải được biên dịch, từ ngày đầu tiên của quá trình phát triển, với tất cả các cảnh báo trình biên dịch được bật ở cài đặt ngữ nghĩa nhất của trình biên dịch. Tất cả mã phải biên dịch với cài đặt này mà không có bất kỳ cảnh báo nào. Tất cả mã phải được kiểm tra hàng ngày với ít nhất một, nhưng tốt nhất là nhiều hơn một máy phân tích mã nguồn tĩnh hiện đại và phải vượt qua các phân tích mà không có cảnh báo nào.

Về những quy tắc này, đây là những gì NASA phải nói:

Các quy tắc hoạt động giống như việc thắt dây an toàn trong xe hơi của bạn: ban đầu chúng có lẽ hơi khó chịu, nhưng sau một thời gian, việc sử dụng chúng trở thành bản chất thứ hai và việc không sử dụng chúng trở nên không tưởng.

Nguồn

Bạn có thấy bài viết này hữu ích không? Đừng quên để lại phản hồi của bạn trong phần bình luận bên dưới.

This post is also available in: Tiếng Việt

LEAVE A REPLY

Please enter your comment!
Please enter your name here