Kodlama Standardı (SCStd) Şablonu
Kodlama standardı (software code standards, SCStd), kaynak kodun hangi dil ve alt kümeyle, hangi kurallarla ve hangi araç kısıtlarıyla yazılacağını tanımlar. Okurları kodu yazan geliştirici ile kodu gözden geçiren doğrulama mühendisidir. Çoğunlukla kodlama lideri yazar, doğrulama ve kalite güvencesi (quality assurance) gözden geçirir, yazılım proje yöneticisi onaylar. Planlamada yazılır, kredi alınacak ilk koddan önce temel çizgiye (baseline) alınır.
Standardın neden gerektiği 5. Yazılım Planlama bölümünde, kodlama sırasında uygulanışı 8. Yazılım Gerçekleştirme: Kodlama ve Entegrasyon bölümünde, plan ve standartların ortak çerçevesi genel bakış sayfasında anlatılır.
Bir bakışta
| Özellik | Değer |
|---|---|
| DO-178C maddesi | §11.8 (ilgili: §4.5, §5.3.2.b, §6.3.4.d) |
| İlgili Ek A hedefleri | A-1 #5 (standardın tanımlanması); uyum: A-5 #4; ayrıca A-2 #6, A-9 #3 |
| Beklendiği seviyeler | A, B, C (D'de beklenmez) |
| Kontrol kategorisi | CC1/CC1/CC2/– (A/B/C/D) |
| Otoriteye | Denetimde gösterilir |
| Sahibi | Kodlama lideri; doğrulama ve kalite güvencesi gözden geçirir |
| İlgili SOI | SW SOI-1 (standart); SW SOI-2 (uyum kanıtı) |
Kodlama standardını sıfırdan yazmayın: seçtiğiniz kural kümesi (C için çoğunlukla MISRA C) kuralların gövdesini zaten verir. Şablonun sizden istediği, o kümenin üzerine verilecek kararlardır: hangi sürüm, hangi kural bağlayıcı, hangisi araçla hangisi gözle denetlenir, sapmayı kim onaylar. Başlıkları kurum yapınıza göre birleştirebilirsiniz; uyum tablosundaki her maddenin bir karşılığı kaldığı sürece yapı serbesttir.
Önerilen içindekiler
Ortak ön bölümler (belge kimliği, onaylar, revizyon geçmişi, referanslar, kısaltmalar ve tanımlar) genel bakış sayfasında anlatılır ve burada tekrarlanmaz.
1 Amaç ve kapsam
1.1 Kapsanan kod ve kapsam dışı kod
1.2 Önceden geliştirilmiş ve tedarikçi kodu
1.3 Standardın değişmesi ve mevcut kod
2 Programlama dili ve alt küme
2.1 Dil sürümü ve dili tanımlayan başvuru
2.2 Tanımsız, belirtilmemiş ve gerçeklemeye bağlı davranış
2.3 Derleyici eklentileri
3 Temel kural kümesi
3.1 Esas alınan kural kümesi ve sürümü
3.2 Bağlayıcılık ve projeye özgü değişiklikler
4 Sunum kuralları
5 Belgeleme kuralları
5.1 Dosya başlığı ve kaynak kod kimliği
5.2 Fonksiyon başlığı ve iz etiketi
6 Adlandırma kuralları
7 Kodlama kısıtları
7.1 Veri tipleri ve dönüşümler
7.2 Bileşenler arası bağlaşım ve global veri
7.3 Karmaşıklık sınırları
7.4 Savunmacı programlama ve hata işleme
7.5 Donanım erişimi ve paylaşılan veri
7.6 Nesne yönelimli ve ilgili teknikler (varsa)
8 Derleyici ve araç kullanım kısıtları
8.1 Uyarılar, pragmalar ve satır içi çevirici
8.2 Eniyileme ve ek kod üreten seçenekler
9 Otomatik denetim
9.1 Statik analiz aracı ve yapılandırması
9.2 Kural ile denetim yöntemi eşlemesi
10 Sapma süreci
10.1 Yanlış alarm, tekil sapma ve proje geneli sapma
10.2 Sapma kaydı, onay yetkisi ve izleme
11 Otomatik üretilen kod ve çevirici dili
11.1 Üretilen kod
11.2 Çevirici dili modülleri
Bölüm bölüm yazım rehberi
Örnek kurallar KS-01'den başlayarak numaralanır; sayısal sınırlar, dosya ve araç adları örnektir. MISRA C karşılığı, kitabın 8. bölümündeki gibi MISRA C:2012 numarasıyla parantez içinde verilir (K: kural, Y: yönerge); kural metni MISRA'nın yayınındadır, burada yazılmaz.
1. Amaç ve kapsam
Standardın hangi koda uygulandığı açıkça yazılır: elle yazılan C ve başlık dosyaları, çevirici dili (assembly language) modülleri, kod üretecinin (code generator) çıktısı, tedarikçi kodu ve önceden geliştirilmiş yazılım (previously developed software, PDS) ayrı ayrı ele alınır. Ticari hazır yazılım (commercial off-the-shelf, COTS) dahil PDS başka bir standarda göre yazılmışsa SDP o standardı ayrıca anar. Standart değişince mevcut kodun durumu da burada karara bağlanır; yoksa uyum kanıtının hangi sürüme dayandığı belirsizleşir.
Verilecek kararlar:
- Hangi dosya türleri kapsamda; test sürücüleri, yer tutucu kod (stub) kapsam dışı mı?
- Tedarikçi kodu ve PDS bu standarda mı, kendi standardına mı göre değerlendirilir?
- Standart değişince mevcut kod tümüyle mi yeniden denetlenir, yalnızca değişen dosyalar mı?
| Zayıf ifade | Güçlü ifade |
|---|---|
| "Bu standart projedeki tüm kod için geçerlidir." | "Standart, <ürün> uçuş yazılımının elle yazılan .c, .h ve .s dosyalarına uygulanır. Üretilen kod 11.1'e, <tedarikçi bileşeni> SDP'de anılan kendi standardına tabidir; test sürücüleri kapsam dışıdır." |
2. Programlama dili ve alt küme
Dilin anlamı tek ve kesin bir başvuruya bağlanır (§11.8.a): bir yapının nasıl derlenip
çalışacağı yoruma açık kalmamalıdır. "C" tek başına yetmez: C90, C99 ve C11 farklıdır.
Tanımsız davranış (undefined behavior) kuralla ve analizle dışarıda tutulur; belirtilmemiş
davranışa (unspecified behavior), örneğin değerlendirme sırasına, dayanılmaz. Gerçeklemeye
bağlı davranış (implementation-defined behavior) tamamen önlenemez: int genişliği,
işaretli sağa kaydırma ve bit alanı yerleşimi gibi dayanılan her davranış, derleyici
kılavuzundaki karşılığıyla bir tabloda listelenir.
Verilecek kararlar:
- Hangi dil sürümü ve baskısı esas alınıyor; derleyici hangi kipte çağrılıyor?
- Gerçeklemeye bağlı hangi davranışlara dayanılıyor; tablo nerede tutuluyor?
- Hangi derleyici eklentileri (kesme anahtar sözcüğü, bölüm özniteliği) serbest?
| No | Kural | Gerekçe | Nasıl denetlenir |
|---|---|---|---|
| KS-01 | Kod C99 (ISO/IEC 9899:1999) ile yazılır; derleyici eklentili lehçe kipinde değil, standart kipte çağrılır | Dilin anlamı tek başvuruya bağlanır | Derleme betiği, derleme kaydı |
| KS-02 | Tanımsız davranışa dayanılmaz; dayanılan gerçeklemeye bağlı davranış tabloya yazılır (K 1.3, Y 1.1) | Davranış derleyici ya da seçenekle değişmemeli | Statik analiz, değer aralığı analizi; tablo gözden geçirmede |
| KS-03 | Derleyici eklentileri yalnızca platform.h içindeki makrolarla kullanılır (K 1.2) | Eklentiler tek yerde görünür | Statik analiz, metin araması |
| Zayıf ifade | Güçlü ifade |
|---|---|
| "Kod ANSI C ile yazılır." | "Kod ISO/IEC 9899:1999 (C99) ile yazılır; <derleyici ve sürümü> SDP'deki seçeneklerle standart kipte çağrılır. Dayanılan gerçeklemeye bağlı davranışlar, derleyici kılavuzundaki bölümüyle 2.2'deki tabloda listelenir." |
3. Temel kural kümesi
C projelerinin çoğu kuralların gövdesini MISRA C'den alır. Standart, esas alınan sürümü ekleri ve teknik düzeltmeleriyle adıyla yazar; kural numaraları sürüme bağlı olduğundan araç yapılandırması ve sapma kayıtları aynı numaralandırmayı kullanır, aracın o sürümü desteklediği planlamada kontrol edilir. MISRA kuralları üç sınıftır: zorunlu (mandatory) kurala sapma yapılmaz, gerekli (required) kurala yalnızca kayıtlı ve gerekçeli sapmayla aykırı davranılır, tavsiye (advisory) kurallarının bağlayıcılığına proje karar verir. MISRA'nın uyum rehberine (MISRA Compliance:2020) göre tavsiye kuralı yükseltilebilir ya da uygulanmaz sayılabilir, gerekli kural yalnızca yükseltilebilir, zorunlu kural değiştirilmez. Tek çıkış (K 15.5) ile erken dönüş arasındaki seçim tipik bir tavsiye kuralı kararıdır; MISRA C:2025 bu kuralı uygulanmaz sınıfına almıştır, onu bağlayıcı yapmak yine proje kararıdır. C++'ta MISRA C++:2023 ya da JSF AV C++ alınabilir. Aşağıdaki tablo, rehberdeki yeniden sınıflandırma planına (guideline re-categorization plan) karşılık gelir; uygulanmaz sayılan her tavsiye kuralı da gerekçesiyle buraya yazılır.
| Kural | Değişiklik | Gerekçe |
|---|---|---|
| K 15.5 | Tavsiyeden gerekliye | Tek çıkış gözden geçirmeyi ve kapsamı sadeleştirir |
| K 11.4 | Tavsiyeden gerekliye | Tamsayıdan işaretçi üretimi yalnızca sapma kaydıyla (10.2) |
| KS-14, KS-15, KS-16 | Proje eki | MISRA'nın kapsamadığı donanım erişimi kararları |
Verilecek kararlar:
- Hangi MISRA C sürümü, hangi ek ve düzeltmelerle esas alınıyor; araç bunu destekliyor mu?
- Tavsiye kurallarından hangileri bağlayıcı, hangileri uygulanmaz sayılıyor; neden?
| Zayıf ifade | Güçlü ifade |
|---|---|
| "MISRA C kurallarına uyulur." | "MISRA C:2012, <ek ve teknik düzeltme listesi> ile esas alınır. Tavsiye kurallarının bağlayıcılığı ve yükseltilen kurallar 3.2'deki tablodadır; MISRA'da olmayan proje kuralları KS önekiyle numaralanır." |
4. Sunum kuralları
Satır uzunluğu, girinti, süslü parantez, boş satır ve dosya içi sıra gözden geçirme hızını belirler. En iyi yol, sunumu depodaki yapılandırmasıyla bir biçimlendiriciye (formatter) üretip uyumu "fark yok" diye denetlemektir. DO-248C'ye göre (FAQ #75) standarda uyum bütün kodda gösterilir; otoritenin daha dar denetimi kabul edebileceği tek alan sunum kurallarıdır. Süslü parantez zorunluluğu (K 15.6) gibi davranışa dokunan kurallar 7. bölüme yazılır.
Verilecek kararlar:
- Satır uzunluğu, girinti, süslü parantez ve dosya içi sıra kuralları nedir?
- Biçimlendiricinin adı, sürümü ve yapılandırma dosyası nerede; ne zaman koşuluyor?
| No | Kural | Gerekçe | Nasıl denetlenir |
|---|---|---|---|
| KS-04 | Biçim, depodaki <biçimlendirici> yapılandırmasıyla üretilir: 4 boşluk girinti, satır en çok 100 karakter, sekme yok | Sunumun elle denetimi kalkar | Birleştirmede biçimlendirici farkı sıfır |
5. Belgeleme kuralları
Dosya başlığı bileşenin adını ve sürümünü taşır; revizyon geçmişinin dosyada mı, yalnızca
konfigürasyon yönetimi (configuration management) aracında mı tutulacağı burada karara
bağlanır. Fonksiyon başlığının en değerli alanı iz etiketidir (ör. @iz LLR-73-2): kodu
düşük seviyeli gereksinime (low-level requirement) bağlar ve bir betikle denetlenebilir.
Girdi ve çıktılar birim ve aralıkla yazılır; okunan ve yazılan global veri satırı veri
bağlaşımı (data coupling) analizinin girdisidir, @global Yok da "ortak veriye dokunmaz"
iddiasının dayanağıdır. Başlık gereksinimi kopyalamaz; kopyalarsa gereksinim değişince eskir.
Verilecek kararlar:
- Başlıkta hangi alanlar zorunlu; iz etiketi gereksinim kimlikleriyle nasıl karşılaştırılıyor?
- Yorum dili Türkçe mi İngilizce mi; tedarikçi kodunda aynı kural geçerli mi?
| No | Kural | Gerekçe | Nasıl denetlenir |
|---|---|---|---|
| KS-05 | Dış bağlantılı her fonksiyonun başlığında iz etiketi, birim ve aralıkla girdiler, çıktılar ve okunan ya da yazılan global veri bulunur | İzlenebilirlik ve bağlaşım analizine girdi | Betik etiketi ve kimliği denetler; içerik gözden geçirmede |
| KS-06 | Yorum içine alınmış kod bırakılmaz (Y 4.4) | Hangi kodun uçuş yazılımı olduğu belirsizleşir | Statik analiz |
6. Adlandırma kuralları
Amaç estetik değil, bilginin koddan okunmasıdır: bileşen öneki çağrının bileşen sınırını geçip geçmediğini, birim soneki toplamanın birimleri karıştırıp karıştırmadığını gösterir. Tanıtıcılar ASCII ile sınırlanır; Türkçe karakter desteği gerçeklemeye bağlıdır.
Verilecek kararlar:
- Bileşen önekleri nasıl atanıyor ve tasarımdaki bileşen adlarıyla nasıl eşleşiyor?
- Fiziksel büyüklük taşıyan adlarda birim soneki zorunlu mu?
| No | Kural | Gerekçe | Nasıl denetlenir |
|---|---|---|---|
| KS-07 | Dış bağlantılı adlar bileşen önekiyle (nav_, ils_), fiziksel büyüklükler birim sonekiyle (_ms, _ft) yazılır; tipler _t ile biter | Bileşen sınırı ve birim kodda görünür | Statik analiz aracının ad deseni denetimi |
7. Kodlama kısıtları
Davranışa dokunan kurallar burada durur. Her kısıtın neden konduğu yazılır (§11.8.d): gerekçesi olmayan bir yasak, sapma istendiğinde tartışılamaz ve eskidiğinde fark edilmez; bu yüzden her kuralın "Gerekçe" sütunu doludur. MISRA'nın kural metni yinelenmez; bir KS kuralı, MISRA kuralına proje kararı (sınır, istisna, denetim yolu) eklendiğinde ya da MISRA'nın kapsamadığı bir konuda yazılır ve varsa karşılığı parantezde verilir.
| No | Kural | Gerekçe | Nasıl denetlenir |
|---|---|---|---|
| KS-08 | Sayısal amaçlı temel tipler yerine <stdint.h> tipleri kullanılır (Y 4.6) | Genişlik ve işaret hedeften bağımsız olur | Statik analiz |
| KS-09 | İşaretli ve işaretsiz işlenen aynı işlemde karıştırılmaz; dönüşüm açık ve aralığı denetlenmiş yapılır (K 10.4) | Örtük dönüşüm sessizce yanlış sonuç verir | Statik analiz, derleyici uyarısı |
| KS-10 | Bileşenler arası veri arayüz fonksiyonlarıyla aktarılır; extern değişken yalnızca tasarımdaki global veri tablosundakiler için | Veri bağlaşımı tasarımla sınırlı kalır | Bağlayıcı sembol listesi ile tablonun karşılaştırılması |
| KS-11 | Çevrimsel karmaşıklık (cyclomatic complexity) en çok 10, iç içe kontrol derinliği en çok 4, bir karardaki koşul sayısı en çok 6 | Gözden geçirilebilirlik; MC/DC test sayısı | Metrik aracı, her derlemede |
| KS-12 | Hata bilgisi döndüren her çağrının sonucu denetlenir; kasıtla kullanılmayan dönüş (void) ile işaretlenir (K 17.7, Y 4.7) | Hata sessizce yutulmaz | Statik analiz |
| KS-13 | Her switch default, her if … else if zinciri else ile biter; beklenmeyen dal hata işleyicisini çağırır (K 16.4, K 15.7) | Beklenmeyen değerde öngörülebilir davranış | Statik analiz; dalın kapsamı SVP'deki analizle |
| KS-14 | Donanım bekleyen her döngü bir deneme sınırıyla biter; zaman aşımı çağırana bildirilir | Gürbüzlük; yürütme süresi sınırlı kalır | Gözden geçirme kontrol listesi |
| KS-15 | Kesmeyle ya da başka görevle paylaşılan değişken ve bellek eşlemeli yazmaç volatile nitelenir | Derleyici yazmaç okumasını kaldıramaz | Gözden geçirme; global veri tablosu |
| KS-16 | Donanım yazmacı ve haberleşme kelimesi bit alanıyla eşlenmez; alanlara maske ve kaydırmayla erişilir (Y 1.1; proje eki) | Bit alanı yerleşimi gerçeklemeye bağlıdır | Statik analiz, gözden geçirme |
| KS-17 | Özyineleme ve dinamik bellek kullanılmaz (K 17.2, K 21.3, Y 4.12); başlatmada bellek ayırma gerekiyorsa proje geneli sapmayla (10) | Yığın ve bellek ihtiyacı analiz edilebilir kalır | Statik analiz, çağrı grafiği, bağlama haritası |
7.1 Veri tipleri ve dönüşümler. Asıl tehlike işaretli ve işaretsiz sayıların karışmasıdır. Hatalı sürüm derlenir ve olağan girdilerle doğru çalışır:
#include <stdbool.h>
#include <stdint.h>
/* Uymaz (KS-09): irtifa_ft işaretsize dönüşür; -20 ft, 4294967276 olur. */
bool alcak_irtifa_hatali(int32_t irtifa_ft, uint32_t esik_ft)
{
return irtifa_ft < esik_ft;
}
/* Uyar (KS-08, KS-09): yerde radyo altimetresi eksi değer verebilir;
negatif değer ayrıca ele alınır, dönüşüm yalnızca sıfır ve üstünde. */
bool alcak_irtifa(int32_t irtifa_ft, uint32_t esik_ft)
{
return (irtifa_ft < 0) || ((uint32_t)irtifa_ft < esik_ft);
}
GNU derleyicisi bu karşılaştırmayı -Wextra ile açılan bir uyarıyla da yakalar (KS-18).
7.2 Bileşenler arası bağlaşım ve global veri. Bileşen sınırları ve global veri tablosu tasarım standardındadır; kodlama standardı kodun onları delmemesini sağlar (KS-10).
7.3 Karmaşıklık sınırları. Sınırlar ölçülebilir ve tasarım standardıyla tutarlıdır. Bir karardaki koşul sayısını sınırlamak, Seviye A'da değiştirilmiş koşul/karar kapsama (modified condition/decision coverage, MC/DC) için gereken test sayısını da sınırlar.
| Zayıf ifade | Güçlü ifade |
|---|---|
| "Fonksiyonlar gereksiz karmaşık olmamalıdır." | "Çevrimsel karmaşıklık en çok 10, iç içe kontrol derinliği en çok 4'tür; <metrik aracı ve sürümü> her derlemede ölçer, aşım sapma kaydı olmadan birleştirilmez." |
7.4 Savunmacı programlama ve hata işleme. Savunmacı programlama (defensive programming), beklenmeyen girdi ya da durumda kodun öngörülebilir davranmasını sağlayan yapılardır ve gürbüzlükle (robustness) ilgilidir. DO-248C'nin açıklaması (FAQ #32) bunların tasarım ve kodlama standartlarında ele alınabileceğini, anormal girdiye doğru tepkinin ise gereksinimlerde tanımlanacağını belirtir. Standart hangi savunmacı yapının zorunlu olduğunu söyler (KS-13, KS-14); tetiklendiğindeki davranış bir gereksinimde yazılıdır, hatalar tek bir raporlama arayüzüne bildirilir (KS-12). Bu dallara çoğu zaman gereksinim tabanlı testle (requirements-based testing) ulaşılamaz ve yapısal kapsam analizinde (structural coverage analysis) gerekçe istenir; kuralın standartta yazılı olması, boşluğun sonradan uydurulmuş bir etiketle değil belgeli bir dayanakla açıklanmasını sağlar (17. Kapsanmayan Kodlar).
7.5 Donanım erişimi ve paylaşılan veri. Bellek eşlemeli yazmaçlar ve kesme servis rutini (interrupt service routine, ISR) ile paylaşılan veri, derleyicinin eniyileme (optimization) sırasında kodu "gereksiz" sayıp değiştirebildiği yerlerdir. Çok kelimelik paylaşılan verinin tutarlı okunma yöntemi tasarım standardında seçilir. ARINC 429 kelimesini bit alanıyla eşleyen yapı da derlenir, ama alanların kelimedeki sırası derleyiciye bağlıdır.
#include <stdbool.h>
#include <stdint.h>
#define UART_TX_BOS (0x00000080U)
#define UART_BEKLEME_SINIRI (1000U)
/* Uymaz (KS-15): volatile yok. while ((UART_DURUM_HATALI & UART_TX_BOS) == 0U)
gibi bir beklemede eniyileyici okumayı döngü dışına alabilir; döngü bitmez. */
#define UART_DURUM_HATALI (*(uint32_t *)0x40011000U)
/* Uyar (KS-14, KS-15): yazmaç her turda okunur; zaman aşımında false
döner, çağıran hata işler (LLR-12-7). Adres dönüşümü: SAP-003. */
#define UART_DURUM (*(volatile const uint32_t *)0x40011000U)
bool uart_bos_bekle(void)
{
uint32_t deneme = 0U;
bool bos = false;
while ((!bos) && (deneme < UART_BEKLEME_SINIRI))
{
bos = ((UART_DURUM & UART_TX_BOS) != 0U);
deneme++;
}
return bos;
}
7.6 Nesne yönelimli ve ilgili teknikler. DO-332 uygulanıyorsa standart, ekin saydığı yedi teknik için kısıt koyar: kalıtım, parametrik çok biçimlilik (şablon ve genel türler), aşırı yükleme, tip dönüşümü, istisna yönetimi, dinamik bellek yönetimi ve sanallaştırma. "İlgili teknikler" (tip dönüşümü, dinamik bellek) C'de de geçerlidir; serbest bırakılan her özellik için ekteki doğrulama planlanır (15. bölüm).
Verilecek kararlar:
- Sayısal sınırlar hangi değerlerde ve tasarım standardıyla tutarlı mı?
- Kayan nokta serbest mi; eşitlik karşılaştırması, sıfıra bölme, NaN ve sonsuz değer, sabit noktada taşma ve çözünürlük hangi kuralla ele alınıyor?
- Hangi savunmacı yapılar zorunlu; tetiklendiklerindeki davranış hangi gereksinimde?
- Dinamik bellek, özyineleme, fonksiyon işaretçisi ve nesne yönelimli yapılar ne zaman serbest?
8. Derleyici ve araç kullanım kısıtları
Derleme seçeneklerinin listesi SDP'de durur; derleyici ve sürümü SECI'de, seçeneklerin kullanıldığı derleme talimatları SCI'de kayıtlıdır. Standart o listenin kodun içinden delinmemesini sağlar. Seviye A'da kaynak koda izlenemeyen nesne kodu ek doğrulama istediğinden, yığın koruyucu gibi ek kod üreten seçenekler ve eniyileme düzeyinin yerel olarak değiştirilmesi doğrudan iş yüküne dönüşür (9. Yazılım Doğrulama). Derleyicinin bilinen hata listesinde projeyi etkileyen yapılar burada yasaklanır. Kapsam nesne kodunda ölçülüyorsa denkliği koruyan kurallar (ör. karar içinde bit düzeyi işleç olmaması) da buraya eklenir (DO-248C, FAQ #42).
Verilecek kararlar:
- Uyarılar hata sayılıyor mu; tek bir uyarı hangi sözdizimiyle ve hangi kayıtla bastırılır?
- Ek kod üreten seçenekler açık mı; açıksa Seviye A'daki ek doğrulama nasıl planlandı?
- Derleyici hata listesini kim izliyor; satır içi çevirici (inline assembly) nerede serbest?
| No | Kural | Gerekçe | Nasıl denetlenir |
|---|---|---|---|
| KS-18 | Derleme bütün uyarılar açık ve uyarılar hata sayılarak yapılır; bastırma yalnızca sapma kaydıyla | Uyarı, statik analizden önceki en ucuz denetimdir | Derleme betiği; derleme kaydında sıfır uyarı |
| KS-19 | Eniyileme düzeyini yerel olarak değiştiren pragma ve öznitelik kullanılmaz | Nesne kodu analizi tek seçenek kümesine dayanır | Statik analiz, metin araması |
| KS-20 | Satır içi çevirici yalnızca cpu_ önekli modüllerde, tek amaçlı küçük fonksiyonlarda kullanılır (Y 4.3) | Çevirici kod yalıtılır, gözden geçirilebilir kalır | Statik analiz, gözden geçirme |
| Zayıf ifade | Güçlü ifade |
|---|---|
| "Derleyici uyarıları dikkate alınır." | "Derleme SDP'deki seçeneklerle (ör. -Wall -Wextra -Wconversion -Werror) yapılır. Tek bir uyarı yalnızca sapma kaydıyla, kaydın kimliği bastırılan satırda yazılarak bastırılır." |
Komut satırından kapatılan uyarı ya da bastırma pragması, gözden geçirilen kodu değiştirmeden kanıtı zayıflatır: proje geneli kapatma SDP'de gerekçesiyle, tekil bastırma sapma kaydıyla.
9. Otomatik denetim
Bu bölüm statik analiz (static analysis) aracını, sürümünü, yapılandırmasını ve ne zaman koşulduğunu tanımlar. MISRA kuralları araçla kesin karar verilebilen (decidable) ve verilemeyen (undecidable) diye ayrılır; ikincilerde ve yönergelerin çoğunda araç bulgusu gözden geçirmeyle tamamlanır. Bu yüzden her kural için "araç", "araç ve gözden geçirme" ya da "yalnızca gözden geçirme" kararı bir eşleme tablosunda tutulur (MISRA'nın uyum rehberindeki denetim planı, guideline enforcement plan); elle denetlenenler kontrol listesinde madde numarasıyla yer alır. Proje sonunda kural bazında uyum özeti çıkarılır.
Bir kuralın uyumu yalnızca aracın "ihlal yok" sonucuna dayanıyor ve kod o kural için gözden geçirmede ayrıca denetlenmiyorsa araç, ihlali gözden kaçırabilecek bir doğrulama aracıdır: Ölçüt 3'e girer, TQL-5 kalifikasyonu gündeme gelir ve karar PSAC'ta yazılır (13. bölüm). Raporu gözden geçirmek yalnızca yanlış alarmı ayıklar; aracın atladığı ihlali göstermez.
Verilecek kararlar:
- Hangi araç, hangi sürüm; yapılandırma dosyası hangi konfigürasyon öğesi?
- Araç ne zaman koşuluyor; yeni ihlal ya da kaydı olmayan bastırma birleştirmeyi durduruyor mu?
- Araçla denetlenen her kuralda uyum kanıtı nedir: kalifiye aracın sonucu mu, kontrol listesiyle ek gözden geçirme mi; bu seçimi kural kural kim yapıyor?
- Araçla tam denetlenemeyen kuralları kontrol listesinin hangi maddesi karşılıyor? Araçta kapatılan her kural standartta "uygulanmaz" ya da "elle denetlenir" diye görünüyor mu?
10. Sapma süreci
Sapma (deviation), bir kuralın bilerek ve gerekçeyle ihlal edilmesidir; DO-178C kaynak kodun standarda uyumunu doğrularken sapmaların gerekçeli olmasını da arar. Sapma akışının ayrıntısı bu belgededir; gereksinim ve tasarım standartları buna atıf yapar. Yanlış alarm (false positive), aracın uymaz dediği ama kuralın ihlal edilmediği yerdir; sapma değildir, analiz kaydında kısa gerekçeyle kapatılır. Tekil sapma tek bir yere ilişkindir. Proje geneli sapma, aynı gerekçeye dayanan çok sayıda ihlali tek kayıtta toplar; kullanım yerleri kayıtta listelenir ya da her yer kaydın kimliğini anar. MISRA'nın uyum rehberindeki sapma izni (deviation permit) ise önceden onaylanmış bir kullanım durumudur; kaydın yerine geçmez, içeriğinin çoğunu hazır verir. Zorunlu kurallara sapma yapılmaz.
| Alan | Örnek: SAP-003 (proje geneli) |
|---|---|
| Kural | MISRA C:2012 K 11.4 (3.2 ile gerekli sayıldı) |
| Yer | donanim_yazmac.h içindeki yazmaç makroları ve açıldıkları yerler; makro dışındaki dönüşüm ayrı kayıt ister |
| Gerekçe | Bellek eşlemeli yazmaca erişim, tamsayı adresten işaretçi üretmeyi gerektirir |
| Emniyet etkisi değerlendirmesi | Yanlış adres yanlış donanım okuması doğurur; her adres donanım arayüz belgesine izlenir |
| Alternatif önlem | Adresler tek dosyada; gözden geçirmede donanım belgesiyle karşılaştırılır; bellek haritası analizi |
| Onaylayan | Yazılım teknik lideri |
| Kalite güvencesi görüşü | Kayıt eksiksiz; kullanım yerleri araç raporuyla sınırlı |
| Durum | Onaylı; standart <sürüm>, kod <temel çizgi kimliği> |
Onaylı sapmalar konfigürasyon yönetimi altında tutulur, kalite güvencesi kaydedildiklerini denetler. Liste, kodun standarda uyum kanıtının (A-5 #4) parçasıdır; yazılım başarım özetinde (Software Accomplishment Summary, SAS) sapmalar anılırken de ona dayanılır.
Verilecek kararlar:
- Yanlış alarm, tekil sapma ve proje geneli sapma nerede, hangi biçimde kaydediliyor?
- Onay yetkisi kimde; koddaki bastırma yorumu kayda nasıl bağlanıyor?
| Zayıf ifade | Güçlü ifade |
|---|---|
| "Gerekli durumlarda kurallardan sapılabilir." | "Gerekli kurala sapma, SAP kaydı açılıp <onaylayan rolü> onaylamadan birleştirilmez; zorunlu kurallara sapma yapılmaz. Bastırma yorumu kaydın kimliğini taşır." |
11. Otomatik üretilen kod ve çevirici dili
11.1 Üretilen kod. Kod üreteci kalifiye değilse üretilen kaynak kod elle yazılmış kod gibi gözden geçirilir ve analiz edilir (A-5); bu yüzden ona hangi kuralların uygulandığı yazılır. Üreteç çıktısı çoğu zaman bütün kuralları karşılamaz; standart, geçerli kural alt kümesini ya da üreteç ayarlarının hangi kalıpları önlediğini söyler, model standardına ve elle yazılan kodla arayüze atıf yapar.
11.2 Çevirici dili modülleri. Çevirici dili, C ile yapılamayan işlerle (başlatma kodu, bağlam değiştirme (context switch), önbellek ayarı) sınırlandırılır. Kurallar kapsamı ölçülebilir kılar; C ile çağrı kuralı (calling convention) elle sağlandığından kontrol listesinde ayrıca yer alır (9. Yazılım Doğrulama).
Verilecek kararlar:
- Üretilen koda hangi kurallar uygulanıyor; elle dokunulmadığı nasıl gösteriliyor?
- Hangi işler çevirici diliyle yazılabilir; kapsam ölçütünün karşılığı SVP ile aynı mı?
| No | Kural | Gerekçe | Nasıl denetlenir |
|---|---|---|---|
| KS-21 | Üretilen dosyalar elle değiştirilmez; başlıkta model sürümü ve üreteç ayarları yazılıdır | Model ile kod arasındaki bağ korunur | Üretim yeniden koşulup fark alınır |
| KS-22 | Çevirici rutini tek girişlidir; kendini değiştiren kod yoktur; dolaylı atlama yalnızca sınırı denetlenen tablodan; her koşullu dal yorumda karar kimliği ve gereksinim taşır | Kapsam ölçülebilir, gözden geçirilebilir kalır | Gözden geçirme kontrol listesi |
Seviyeye göre farklar
| Konu | A ve B | C | D |
|---|---|---|---|
| Standardın tanımlanması (A-1 #5) | Beklenir | Beklenir | Beklenmez |
| Kontrol kategorisi | CC1 | CC2 | – |
| Kodun standarda uyumu (A-5 #4) | Hedef; bağımsızlık aranmaz | Hedef; bağımsızlık aranmaz | Hedef yok |
| Kodun doğrulanabilirliği (A-5 #3) | Hedef | Hedef değil | Hedef değil |
| Standartlara uyum güvencesi (A-9 #3) | Kalite güvencesi, bağımsız | Kalite güvencesi, bağımsız | Hedef yok |
| Kuralların desteklediği kapsam ölçütü | A: MC/DC; B: karar | Satır | Yapısal kapsam hedefi yok |
Seviye A, B ve C. Kural seti çoğunlukla aynıdır. Seviye A'da kaynak koda izlenemeyen nesne kodu temsilî örnekle analiz ediliyorsa, analiz proje kodunun standardın izin verdiği yapılarla sınırlı kaldığı iddiasına dayanır; bu iddianın kanıtı standart ve statik analizdir. Standarda yeni bir dil yapısı eklemek analizi yineletebilir. Seviye C'de standart CC2 ile yönetilir: değişikliği problem raporu (problem report) ve resmî onay akışı istemez.
Seviye D. Ek A'da kaynak kodun geliştirilmesi ve gözden geçirilmesi hedef değildir; standart da beklenmez. Hafif bir standart (zorunlu ve gerekli MISRA kuralları, araçla denetim) yine de ucuz bir hata yakalama yoludur. Ancak SDP standarda uyulacağını yazarsa, süreçlerin planlara uyduğuna ilişkin kalite güvencesi hedefi (A-9 #2, D'de de geçerli) bu taahhüdü denetlenebilir kılar; standart ya tavsiye olarak anılır ya da gerçekten uygulanır.
DO-178C uyum tablosu
| DO-178C | Konu | Şablondaki yer |
|---|---|---|
| §11.8 | Standardın tanımı ve kapsamı | 1 Amaç ve kapsam |
| §11.8.a | Dil, başvuru ve alt küme | 2 Programlama dili ve alt küme; 3 Temel kural kümesi |
| §11.8.b | Sunum kuralları | 4 Sunum kuralları |
| §11.8.b | Belgeleme kuralları | 5 Belgeleme kuralları |
| §11.8.c | Adlandırma kuralları | 6 Adlandırma kuralları |
| §11.8.d | Kısıtlar ve gerekçeleri | 7 Kodlama kısıtları |
| §11.8.e | Kodlama araçlarının kısıtları | 8 Derleyici ve araç kullanım kısıtları; 9.1 |
| §11.11 | Kaynak kod bileşeni kimliği | 5.1 Dosya başlığı ve kaynak kod kimliği |
| §11.2.a | PDS ve COTS standartları | 1.2 Önceden geliştirilmiş ve tedarikçi kodu |
| §4.2.b | Standardın tanımlanması ya da seçilmesi | 3.1 Esas alınan kural kümesi ve sürümü |
| §4.2.g | Değişiklik kontrolü ve gözden geçirme | Ortak ön bölümler (onaylar, revizyon geçmişi); 1.3 |
| §4.4.1.c, f | Ortam hatalarına karşı kurallar, araç sorunları | 8 Derleyici ve araç kullanım kısıtları |
| §4.4.2.a, b | Eniyileme, kaynağa izlenemeyen kod | 8.2 Eniyileme ve ek kod üreten seçenekler |
| §4.5.b | Bileşenler arası tekdüzelik | 1.1 Kapsanan kod; 6 Adlandırma kuralları |
| §4.5.c | Doğrulanamayan yapıların yasaklanması | 2.2; 7 Kodlama kısıtları; 11.2 |
| §4.5.d, Not 1 | Gürbüzlük, karmaşıklık, savunmacı programlama | 7.3; 7.4 Savunmacı programlama ve hata işleme |
| §5.3.2.b | Kodun standarda uyması | 9 Otomatik denetim |
| §5.3.2.d | Kod üreteci kullanım kısıtları | 11.1 Üretilen kod |
| §6.3.4.d | Standarda uyum, gerekçeli sapma | 9 Otomatik denetim; 10 Sapma süreci |
| §6.4.4.2.b | Seviye A ek nesne kodu | 8.2 Eniyileme ve ek kod üreten seçenekler |
| §8.2.d.2, 3 | Sapmaların izlenmesi ve kaydı | 10.2 Sapma kaydı, onay yetkisi ve izleme |
Teknoloji ekleri
| Ek | Madde | Şablona etkisi |
|---|---|---|
| DO-331 | MB.11.8 | Değişmez; standart aynen geçerlidir |
| DO-331 | MB.4.5, MB.11.23 | Model standardı dördüncü standarttır; 11.1, üretilen kodla model standardı arasındaki sınırı yazar |
| DO-332 | OO.11.8.a–e | DO-178C §11.8.a–e ile aynı |
| DO-332 | OO.11.8.f.1–f.3 | Kalıtım, parametrik çok biçimlilik ve aşırı yükleme kısıtları: 7.6 |
| DO-332 | OO.11.8.f.4, f.5 | Tip dönüşümü (7.1) ve istisna yönetimi (7.4) kısıtları; 7.6 |
| DO-332 | OO.11.8.f.6 | Dinamik bellek kısıtları: 7.6 (KS-17) |
| DO-332 | OO.11.8.f.7 | Sanallaştırma kısıtları: 7.6; yorumlanan kod çalıştırılabilir kod sayılır |
| DO-332 | Ek OO.D.1 | Özellik zafiyetleri; 7.6'daki kısıtların gerekçe kaynağı |
| DO-333 | FM.11.8.a | Biçimsel analizin girdisi olan dilin matematiksel tanımı ve kısıtları: 2.1 ve 2.2; FM.11.8.b–e DO-178C §11.8 ile aynı |
Bu eşleme bir başvuru aracıdır; DO-178C'nin ve eklerinin metninin yerine geçmez.
Diğer belgelerle tutarlılık
| Bu belgede | Örtüşmesi gereken belge | Nasıl denetlenir |
|---|---|---|
| Dil sürümü, uyarı politikası (2, 8) | SDP (geliştirme ortamı, seçenekler), SECI | Derleme betiğindeki seçenekler SDP'deki listeyle karşılaştırılır |
| Ek kod üreten seçenekler (8.2) | SVP (derleyici varsayımları, nesne kodu analizi) | Temsilî örneğin yapıları standardın izin verdikleriyle aynı mı |
| Statik analiz aracı ve yapılandırması (9) | PSAC (kalifikasyon kararı), SCMP (ortam kontrolü) | Araç sürümü ve yapılandırma kimliği belgelerde aynı mı |
| Sapma süreci (10) | SQAP (sapma kayıtlarının denetimi); gereksinim ve tasarım standardı (atıf) | Öteki standartlar ayrı bir sapma akışı tanımlamıyor mu |
| Karmaşıklık, özyineleme, dinamik bellek (7) | Tasarım standardı | Sayısal sınırlar ve yasaklar iki belgede aynı mı |
| İz etiketi biçimi (5) | Gereksinim ve tasarım standardı (kimlik biçimi) | Etiket betiği aynı kimlik desenini kullanıyor mu |
| Kodlamaya giriş ve çıkış (1, 9) | SDP geçiş kriterleri (Ek A) | Giriş: standart temel çizgide; çıkış: araç raporu temiz ya da sapmalar onaylı |
Sık hatalar
| Hata | Tipik nedeni | Önlem |
|---|---|---|
| MISRA'ya atıf var, proje kararı yok | "MISRA'ya uyuyoruz" kısayolu | Sürüm, bağlayıcılık ve değişiklikleri (3) yazmak |
| Araçta kapatılan kurallar standartta yok | Yapılandırmanın araç uzmanında kalması | Yapılandırmayı konfigürasyon öğesi yapıp eşleme tablosuyla karşılaştırmak |
| Yanlış alarm sapma diye açılmış ya da tersi | Ayrımın tanımlanmaması | 10.1'deki ayrım; yanlış alarm için kısa analiz kaydı |
| Toplu, gerekçesiz sapmalar | Takvim baskısı, "eski kod" bahanesi | Emniyet etkisi ve alternatif önlemi zorunlu alan yapmak |
| Kurallar "kaçınılmalıdır" diye yazılmış | Kılavuz dilinin kopyalanması | Her kuralı "uyar / uymaz" diye yanıtlanabilir yazmak |
| Çevirici ve üretilen kod unutulmuş | Kapsamın yalnızca .c dosyalarıyla tanımlanması | 1.1 ve 11'de kapsamı açıkça yazmak |
Yayımlamadan önce
- Dil, derleyici ve MISRA sürümleri (ekleriyle) adıyla yazılmış; SDP ve SECI ile aynı mı?
- Tavsiye kurallarının bağlayıcılığı ve projeye özgü değişiklikler kural kural listelenmiş mi?
- Her kuralın gerekçesi ve denetim yolu (araç ya da kontrol listesi maddesi) var mı?
- Statik analiz yapılandırması standarttaki kural listesiyle karşılaştırılmış ve konfigürasyon yönetimi altına alınmış mı?
- Uyarıların hata sayıldığı, bastırmanın sapma kaydına bağlandığı ve onay yetkisi yazılı; zorunlu kurallara sapma yapılamayacağı belirtilmiş mi?
- Çevirici dili, üretilen kod ve tedarikçi kodu için kapsam kararı açık mı; sınırlar tasarım standardıyla çelişmiyor mu?
Otoritenin planlama denetiminde standartlara baktığı noktalar SW SOI-1, standarda uyum kanıtının arandığı noktalar SW SOI-2 kontrol listesindedir.
İlgili bölümler
- 5. Yazılım Planlama
- 8. Yazılım Gerçekleştirme: Kodlama ve Entegrasyon
- 9. Yazılım Doğrulama
- 13. DO-330 ve Yazılım Aracı Kalifikasyonu
- 15. DO-332 ve Nesne Yönelimli Teknoloji ve İlgili Teknikler
- 17. Kapsanmayan Kodlar: Ölü, Gereksiz ve Devre Dışı Bırakılmış Kodlar
- Şablonlar: gereksinim standardı, tasarım standardı, SDP, SQAP
- SW SOI-1, SW SOI-2; kütüphane: MISRA C