10 Aturan Pengkodean NASA untuk Menulis Program - Anontekno

10 Aturan Pengkodean NASA untuk Menulis Program

Aturan Pengkodean 10 NASA

Proyek perangkat lunak yang besar dan kompleks menggunakan berbagai standar dan pedoman pengkodean. Panduan ini menetapkan aturan dasar yang harus diikuti saat menulis perangkat lunak. Biasanya, mereka menentukan:

a) Bagaimana seharusnya kode disusun?
b) Fitur bahasa apa yang harus atau tidak boleh digunakan?

Agar efektif, seperangkat aturan harus kecil dan harus cukup spesifik sehingga dapat dengan mudah dipahami dan diingat.

Programer top dunia yang bekerja di NASA mengikuti serangkaian pedoman untuk mengembangkan kode keamanan kritis. Faktanya, banyak lembaga, termasuk Jet Propulsion Laboratory (JPL) NASA, fokus pada kode yang ditulis dalam bahasa pemrograman C. Ini karena ada dukungan alat yang ekstensif untuk bahasa ini, seperti ekstraktor model logika, debugger, kompiler stabil, penganalisis kode sumber yang kuat, dan alat metrik.

Dalam kasus kritis, aturan-aturan ini perlu diterapkan, terutama di mana kehidupan manusia mungkin bergantung pada kebenaran dan efisiensinya. Misalnya, program perangkat lunak yang digunakan untuk mengontrol pesawat terbang, pesawat ruang angkasa, atau pembangkit listrik tenaga nuklir.

Tapi tahukah Kamu stKamur apa yang digunakan badan antariksa untuk mengoperasikan mesin mereka? Di bawah ini, kami telah membuat daftar 10 aturan pengkodean NASA yang ditetapkan oleh ilmuwan utama JPL Gerard J. Holzmann. Mereka semua terutama berfokus pada parameter keamanan, dan Kamu juga dapat menerapkannya ke bahasa pemrograman lain.

Aturan No. 1 – Aliran Kontrol Sederhana

Menulis program dengan konstruksi aliran kontrol yang sangat sederhana – Jangan gunakan  konstruksi setjmp  atau  longjmp ,   pernyataan goto , dan rekursi langsung atau tidak langsung  .

Alasan: Aliran kontrol yang sederhana menghasilkan kejelasan kode yang lebih baik dan kemampuan verifikasi yang lebih kuat. Tanpa rekursi, tidak akan ada grafik pemanggilan fungsi siklik. Jadi, semua eksekusi yang seharusnya dibatasi tetap dibatasi.

Aturan No. 2 – Batas Atas Tetap untuk Loop

Semua loop harus memiliki batas atas tetap. Seharusnya memungkinkan untuk alat verifikasi untuk membuktikan secara statis bahwa batas atas preset pada jumlah iterasi dari sebuah loop tidak dapat dilampaui.

Aturan dianggap dilanggar jika loop-bound tidak dapat dibuktikan secara statis.

Alasan:  Adanya batas loop dan tidak adanya rekursi mencegah kode pelarian. Namun, aturan tersebut tidak berlaku untuk iterasi yang dimaksudkan untuk non-terminating (misalnya, penjadwal proses). Dalam kasus seperti itu, aturan kebalikan diterapkan – Ini harus terbukti secara statis bahwa iterasi tidak dapat dihentikan.

Aturan No. 3 – Tanpa Alokasi Memori Dinamis

Jangan gunakan alokasi memori dinamis setelah inisialisasi.

Alasan:  Pengalokasi memori seperti  malloc , dan pengumpul sampah sering kali memiliki perilaku tidak terduga yang dapat sangat memengaruhi performa. Selain itu, kesalahan memori juga dapat terjadi karena kesalahan programmer, termasuk

  • Mencoba mengalokasikan lebih banyak memori daripada yang tersedia secara fisik
  • Lupa mengosongkan memori
  • Melanjutkan penggunaan memori setelah dibebaskan
  • Melampaui batas pada memori yang dialokasikan

Memaksa semua modul untuk hidup dalam area penyimpanan tetap yang telah dialokasikan sebelumnya dapat menghilangkan masalah ini dan mempermudah verifikasi penggunaan memori.

Satu cara untuk mengklaim memori secara dinamis saat tidak ada alokasi memori dari heap adalah dengan menggunakan memori tumpukan.

Aturan No. 4 – Tidak Ada Fungsi Besar

Aturan Pengkodean 10 NASA

Tidak ada fungsi yang lebih panjang dari yang dapat dicetak pada selembar kertas dalam format referensi stKamur dengan satu baris per pernyataan dan satu baris per pernyataan. Ini berarti suatu fungsi tidak boleh memiliki lebih dari 60 baris kode.

Alasan: Fungsi yang  terlalu panjang seringkali merupakan tKamu dari struktur yang buruk. Setiap fungsi harus menjadi unit logis yang dapat dipahami dan juga dapat diverifikasi. Cukup sulit untuk memahami unit logis yang mencakup banyak layar pada layar komputer.

Aturan No. 5 – Kepadatan Pernyataan Rendah

Kepadatan Pernyataan Rendah

Kepadatan pernyataan program harus rata-rata menjadi minimal dua pernyataan per fungsi. Pernyataan digunakan untuk memeriksa kondisi abnormal yang seharusnya tidak pernah terjadi dalam eksekusi di kehidupan nyata. Mereka harus didefinisikan sebagai pengujian Boolean. Jika pernyataan gagal, tindakan pemulihan eksplisit harus diambil.

Jika alat pemeriksa statis membuktikan bahwa pernyataan tidak akan pernah gagal atau tidak pernah dapat ditahan, aturan tersebut dianggap telah dilanggar.

Alasan: Menurut statistik upaya pengkodean industri, pengujian unit menangkap setidaknya satu cacat per 10 hingga 100 baris kode. Kemungkinan cacat intersep meningkat dengan kepadatan pernyataan.

Penggunaan pernyataan juga penting karena merupakan bagian dari strategi pengkodean pertahanan yang kuat. Mereka digunakan untuk memverifikasi kondisi sebelum dan sesudah suatu fungsi, parameter, dan nilai kembalian dari suatu fungsi dan invarian-loop. Pernyataan dapat dinonaktifkan secara selektif setelah menguji kode kinerja-kritis.

Aturan No. 6 – Deklarasikan Objek Data pada Tingkat Cakupan Terkecil

Yang ini mendukung prinsip dasar penyembunyian data. Semua objek data harus dideklarasikan pada tingkat cakupan sekecil mungkin.

Alasan: Jika suatu objek tidak dalam cakupan, nilainya tidak dapat direferensikan atau rusak. Aturan ini melarang penggunaan kembali variabel untuk beberapa tujuan yang tidak kompatibel yang dapat mempersulit diagnosis kesalahan.

Aturan No. 7 – Periksa Parameter dan Nilai Kembali

Nilai kembalian dari fungsi non-void harus diperiksa oleh setiap fungsi pemanggil, dan validitas parameter harus diperiksa di dalam setiap fungsi.

Dalam bentuknya yang paling ketat, aturan ini berarti nilai kembalian dari  pernyataan printf dan  pernyataan tutup file  harus diperiksa.

Alasan: Jika respons terhadap kesalahan memang tidak berbeda dengan respons terhadap kesuksesan, seseorang harus secara eksplisit memeriksa nilai yang dikembalikan. Ini biasanya terjadi dengan panggilan untuk menutup  dan  printf . Dapat diterima untuk secara eksplisit mengubah nilai pengembalian fungsi ke  void –  menunjukkan bahwa pembuat kode secara eksplisit (tidak secara tidak sengaja) memutuskan untuk mengabaikan nilai pengembalian.

Aturan No. 8 – Penggunaan Preprocessor Terbatas

Penggunaan preprocessor harus dibatasi pada penyertaan file header dan definisi makro. Panggilan makro rekursif, penempelan token, dan daftar argumen variabel tidak diperbolehkan.

Harus ada justifikasi untuk lebih dari satu atau dua arahan kompilasi bersyarat bahkan dalam upaya pengembangan aplikasi besar, di luar boilerplate stKamur, yang menghindari beberapa penyertaan file header yang sama. Setiap penggunaan seperti itu harus ditKamui oleh pemeriksa berbasis alat dan dibenarkan dalam kode.

Alasan: The C preprocessor adalah alat yang ampuh dan ambigu yang dapat menghancurkan kejelasan kode dan membingungkan banyak dam berbasis teks. Efek konstruksi dalam kode preprocessor tak terbatas bisa sangat sulit untuk diuraikan, bahkan dengan definisi bahasa formal di tangan.

Perhatian terhadap kompilasi bersyarat sama pentingnya – dengan hanya 10 arahan kompilasi bersyarat, mungkin ada 1024 kemungkinan versi (2 ^ 10) kode, yang akan meningkatkan upaya pengujian yang diperlukan.

Aturan No. 9 – Penggunaan Pointer Secara Terbatas

Penggunaan pointer harus dibatasi. Tidak lebih dari satu tingkat dereferensi diperbolehkan. Operasi dereferensi penunjuk tidak boleh disembunyikan di dalam   deklarasi typedef atau definisi makro.

Penunjuk fungsi juga tidak diperbolehkan.

Alasan: Pointer mudah disalahgunakan, bahkan oleh para ahli. Mereka menyulitkan untuk mengikuti atau menganalisis aliran data dalam suatu program, terutama oleh penganalisis statis berbasis alat.

Pointer fungsi juga membatasi jenis pemeriksaan yang dilakukan oleh penganalisis statis. Jadi, mereka hanya boleh digunakan jika ada justifikasi yang kuat untuk implementasinya. Jika pointer fungsi digunakan, hampir tidak mungkin alat membuktikan tidak adanya rekursi, jadi metode alternatif harus disediakan untuk menutupi kerugian ini dalam kemampuan analitis.

Aturan No. 10 – Kompilasi semua Kode

Semua kode harus dikompilasi sejak hari pertama pengembangan. Peringatan compiler harus diaktifkan pada pengaturan compiler yang paling teliti. Kode harus dikompilasi dengan pengaturan ini tanpa peringatan apa pun.

Semua kode harus diperiksa setiap hari dengan setidaknya satu (sebaiknya lebih dari satu) penganalisis kode sumber statis yang canggih dan harus lulus proses analisis dengan peringatan nol.

Alasan : Ada banyak penganalisis kode sumber efektif yang tersedia di pasar; beberapa di antaranya adalah alat freeware. Sama sekali tidak ada alasan bagi pembuat kode untuk tidak menggunakan teknologi yang sudah tersedia ini. Jika compiler atau penganalisis statis menjadi bingung, kode yang menyebabkan kebingungan / kesalahan harus ditulis ulang sehingga menjadi lebih valid.

Apa Kata NASA Tentang Aturan Ini?

“Aturan berlaku seperti sabuk pengaman di mobil Kamu: awalnya mungkin sedikit tidak nyaman, tetapi setelah beberapa saat, penggunaannya menjadi kebiasaan dan tidak menggunakannya menjadi tidak terbayangkan.”