Sekali lagi saya butuh dua hari untuk menulis dan men-debug hanya empat ratus baris kode perpustakaan sistem, muncul ide - "seolah-olah itu baik jika program ditulis dengan cara yang tidak terlalu menyakitkan".
Dan pertama-tama, karena debugging membutuhkan waktu lebih lama daripada menulis kode - Anda perlu perlindungan dari si bodoh (termasuk diri Anda sendiri) pada tahap penulisan. Dan saya ingin menerimanya dari bahasa pemrograman yang digunakan (YP).
Tentu saja, kita perlu menciptakan YaP baru, terbaik!Tidak, pertama-tama kami akan mencoba untuk mengekspresikan keinginan kami dan melihat apa yang telah kami ciptakan.
Jadi, apa yang ingin saya terima:
- Perlawanan terhadap kesalahan manusia, penghapusan ambiguitas selama kompilasi
- Resistensi input
- Resistensi terhadap kerusakan pada program atau data - kegagalan media, peretasan
- Pada saat yang sama, setiap orang memiliki sintaks dan fungsionalitas yang kurang lebih dapat ditoleransi
Area aplikasi adalah mesin, transportasi, sistem kontrol industri, IoT, embedd termasuk telepon.
Hampir tidak perlu untuk Web, itu dibangun (untuk saat ini) berdasarkan prinsip "berhenti dan mulai lagi" (api dan lupakan).
Cukup cepat, Anda dapat sampai pada kesimpulan bahwa bahasa harus dikompilasi (setidaknya Pi-dikompilasi) sehingga semua cek dieksekusi secara maksimal pada tahap kompilasi tanpa VS (Versus, selanjutnya adalah oposisi negatif) “oh, objek ini tidak memiliki properti seperti itu” dalam runtime. Bahkan skrip deskripsi antarmuka sudah membuatnya wajib untuk sepenuhnya menutupi skrip tersebut dengan tes.
Secara pribadi, saya tidak ingin membayar dengan sumber daya saya (termasuk uang untuk perangkat yang lebih cepat, lebih mahal) untuk interpretasi, oleh karena itu, disarankan untuk memiliki kompilasi JIT minimum.
Jadi, persyaratannya.
Toleransi kesalahan manusia
Setelah rajin membalik-balik Talmud dari PVS-Studio, saya menemukan bahwa kesalahan yang paling umum adalah kesalahan ketik dan copy-paste yang tidak lengkap.
Saya juga akan menambahkan sedikit insiden dari pengalaman saya dan bertemu di berbagai literatur, sebagai contoh negatif. Selain itu memperbarui aturan MISRA C di memori.
Setelah memikirkannya sedikit, saya sampai pada kesimpulan bahwa linter menerapkan ex-facto menderita "kesalahan selamat", karena dalam proyek-proyek lama kesalahan serius telah diperbaiki.
a) Singkirkan nama yang mirip
- Pemeriksaan ketat harus dilakukan pada visibilitas variabel dan fungsi. Setelah disegel, Anda dapat menggunakan pengidentifikasi dari ruang lingkup yang lebih umum, bukan yang diinginkan
- Gunakan nama case-insensitive. (VS) "Mari panggil fungsi sebagai variabel, hanya di Camelcase" dan kemudian bandingkan dengan sesuatu - di C ini bisa dilakukan (kami mendapatkan alamat fungsi, yang jumlahnya cukup banyak)
- Nama dengan selisih 1 huruf harus menyebabkan peringatan (bisa dibilang, Anda dapat menyorot dalam IDE) tetapi kesalahan salin-tempel yang sangat umum .x, .y, .w, .h.
- kami tidak mengizinkan untuk memberi nama entitas yang berbeda dengan cara yang sama - jika ada konstanta dengan nama itu, maka tidak boleh ada variabel dengan nama yang sama atau nama tipe
- Sangat diinginkan untuk memeriksa penamaan untuk semua modul proyek - mudah untuk membingungkan, terutama jika orang yang berbeda menulis modul yang berbeda
b) Setelah disebutkan - harus ada modularitas dan lebih disukai hirarkis - proyek VS dari 12.000 file dalam satu direktori adalah neraka pencarian.
Masih diperlukan modularitas untuk menggambarkan struktur pertukaran data antara berbagai bagian (modul, program) dari satu proyek. VS I menemui kesalahan karena perbedaan susunan angka dalam struktur pertukaran di penerima dan pemancar.
- Untuk mengecualikan kemungkinan duplikasi tautan (tata letak).
c) Ambiguitas
- Harus ada urutan panggilan fungsi tertentu. Saat menulis X = funcA () + fB () atau Fn (funcA (), fB (), callC ()) - Anda perlu memahami bahwa orang tersebut mengharapkan untuk menerima perhitungan dalam urutan tertulis, (VS) dan bukan sebagai pengoptimal yang memikirkannya.
- Kecualikan operator serupa. Dan tidak suka di C: + ++, <<<, | ||, & &&, = ==
- Dianjurkan untuk memiliki beberapa operator yang dapat dimengerti dan dengan prioritas yang jelas. Halo dari operator ternary.
- Operator utama agak berbahaya. Anda menulis i: = 2, tetapi (VS) sebenarnya menyebabkan penciptaan objek implisit yang tidak memiliki cukup memori, dan disk macet saat bertukar dan satelit Anda menabrak Mars :-(
Bahkan, dari pengalaman pribadi saya mengamati crash pada koneksi ConnectionString = "DSN", ternyata menjadi setter yang membuka database (dan server tidak terlihat di jaringan).
- Kita perlu menginisialisasi semua variabel dengan nilai default.
- Juga, pendekatan OOP menyelamatkan dari pelepasan tugas semua bidang dalam objek dalam beberapa fungsi keseratus baru.
- Sistem tipe harus aman - Anda perlu mengontrol dimensi objek yang ditugaskan - perlindungan terhadap penimpaan memori, overflow aritmatika tipe 65535 +1, kehilangan akurasi dan signifikansi saat casting, tidak termasuk perbandingan yang tak tertandingi - karena integer 2 tidak sama dengan 2.0 pada kasus umum.
Dan bahkan pembagian tipikal dengan 0 dapat memberikan + INF yang sangat pasti, bukannya kesalahan, definisi yang tepat dari hasil diperlukan.
Resistensi input
- Program harus bekerja pada setiap input data dan lebih disukai, kira-kira pada waktu yang sama. (VS) Halo untuk Android dengan reaksi terhadap tombol handset dari 0,2 ke 5; ada baiknya bukan Android yang mengendarai ABS otomotif.
Sebagai contoh, sebuah program harus memproses data 1Kb dan 1TB dengan benar tanpa menghabiskan sumber daya sistem.
- Sangat diinginkan untuk memiliki penanganan kesalahan yang andal dan tidak ambigu dalam RAII yang tidak mengarah pada efek samping (kebocoran sumber daya, misalnya). (VS) Suatu hal yang sangat lucu adalah kebocoran pegangan, yang dapat memanifestasikan dirinya setelah berbulan-bulan.
- Alangkah baiknya untuk melindungi diri Anda dari stack overflow - nonaktifkan rekursi.
- Masalah melebihi volume yang tersedia dengan memori yang diperlukan, pertumbuhan konsumsi yang tidak terkendali karena fragmentasi selama alokasi / deallokasi dinamis. Jika bahasa tersebut memiliki runtime dependen heap, masalahnya kemungkinan besar buruk - halo STL dan Phobos. (VS) Ada cerita dengan waktu-C lama dari Microsoft, yang tidak cukup mengembalikan memori ke sistem, karena msbackup yang jatuh pada volume besar (untuk waktu itu).
- Kami membutuhkan pekerjaan yang baik dan aman dengan string - tidak dibatasi oleh sumber daya. Ini sangat tergantung implementasi (tidak berubah, Kontrak Karya, R / W array)
- Melebihi waktu reaksi sistem, terlepas dari programmer. Ini adalah masalah khas pemulung. Meskipun mereka menghemat dari beberapa kesalahan pemrograman - yang lain membawa - diagnosis buruk.
- Dalam kelas tugas tertentu, ternyata Anda dapat melakukannya tanpa memori dinamis sama sekali, atau dengan memilihnya sekali saat startup.
- Untuk mengontrol jalan keluar di luar batas-batas array, dan sangat dapat diterima untuk menulis peringatan runtime dan mengabaikannya. Sangat sering ini adalah kesalahan tidak kritis.
- Memiliki perlindungan terhadap akses ke bagian memori yang tidak diinisialisasi oleh program, termasuk ke wilayah nol, dan ke ruang alamat orang lain.
- Penerjemah, JIT - lapisan tambahan mengurangi keandalan, ada masalah dengan pengumpulan sampah (subsistem yang sangat kompleks - ini akan membuat kesalahan), dan dengan waktu respons yang dijamin. Kami mengecualikannya, tetapi pada prinsipnya ada Java Micro Edition (di mana begitu banyak yang terputus dari Jawa sehingga hanya saya yang tersisa, ada
artikel menarik
oleh dernasherbrezon (maaf, tembakan) dan .NET Micro Framework dengan C #.
Namun, dengan pertimbangan, opsi ini telah menghilang:
- .NET Micro ternyata menjadi juru bahasa biasa (dicoret oleh kecepatan);
- Java Micro hanya cocok untuk aplikasi embedded, karena terlalu dikebiri oleh API, dan Anda harus beralih ke setidaknya SE Embedded untuk pengembangan, yang sudah ditutup atau Java normal, yang terlalu mengerikan dan tidak dapat diprediksi sebagai tanggapannya.
Namun, masih ada opsi , dan meskipun ini tidak terlihat seperti kosong untuk fondasi yang bisa diterapkan, itu dapat dibandingkan dengan bahasa lain, bahkan ketinggalan jaman atau dengan kerugian tertentu.
- Perlawanan terhadap pekerjaan multi-utas - perlindungan data pribadi dari suatu aliran, dan mekanisme untuk pertukaran yang dijamin antar aliran. Program dengan 200 utas mungkin tidak berfungsi sama sekali seperti dua.
- Pemograman kontrak plus tes unit bawaan juga membantu untuk tidur nyenyak.
Resistensi terhadap kerusakan pada program atau data - kegagalan media, peretasan
- Program harus dimuat sepenuhnya ke dalam memori - tanpa memuat modul, terutama dari jarak jauh.
- Kosongkan memori saat dirilis (dan bukan hanya alokasi)
- Pemantauan stack overflow, area variabel, terutama string.
- Mulai ulang setelah kegagalan.
By the way, pendekatan ketika runtime memiliki logging sendiri, dan tidak hanya menunjukkan bahwa rubah utara dan stackrace, saya sangat terkesan.
Bahasa - dan Tabel Kesesuaian
Sekilas, untuk analisis, kami mengambil PL aman yang dirancang khusus:
- Oberon aktif
- Ada
- BetterC (subset dlang)
- IEC 61131-3 ST
- Aman-c
Dan pergi melalui mereka dalam hal kriteria di atas.
Tetapi ini sudah menjadi volume untuk artikel lanjutan, jika karma memungkinkan.
Dengan faktor-faktor tersebut disorot dalam tabel, well, mungkin hal lain yang masuk akal akan diperoleh dari komentar.
Adapun bahasa lain yang menarik - C ++, Crystal, Go, Delphi, Nim, Red, Rust, Zig (tambahkan ke selera) maka saya akan menyerahkannya kepada mereka yang ingin mengisi tabel korespondensi.
Penafian:
- Pada prinsipnya, jika sebuah program, katakanlah dengan Python, mengkonsumsi 30 MB, dan persyaratan reaksi adalah detik, dan komputer mikro memiliki 600 MB memori bebas dan 600 MHz persen, lalu mengapa tidak? Hanya program seperti itu yang dapat diandalkan dengan beberapa probabilitas (meskipun 96%), tidak lebih.
- Selain itu, bahasa harus berusaha untuk nyaman bagi programmer - jika tidak, tidak ada yang akan menggunakannya. Artikel-artikel semacam itu "Saya datang dengan bahasa pemrograman yang ideal sehingga hanya nyaman bagi saya untuk menulis" juga tidak jarang di Habré, tetapi ini tentang hal lain.