Kod geliştiricilerin ortak yazdığı kod güvenilirliğini, taşınabilirliğini ve en önemlisi de okunabilirliği artırmak amacıyla yazılım şirketlerinde uygulanan çeşitli kodlama standartları vardır.

Dikkate değer iki örnek, MISRA C ve JSF projesi için geliştirilen C ++ standardıdır .

Bunlar genellikle, "aşağıdaki", "gerekir", "gerekir", "olabilir", vb. İfadelerinin ne anlama geldiğini dikkatlice belirttikten sonra aşağıdaki biçimdedir:

Örnek:

Kural 50: Kayan nokta değişkenleri tam eşitlik veya eşitsizlik için test edilmemelidir.

Gerekçe: Kayan nokta sayıları yuvarlama ve kesme hatalarına bağlı olduğundan, beklenildiği halde bile eşitlik elde edilemeyebilir.

Bu kodlama standartları, genellikle derleyicinin bakış açısından yasal olacak kodla ilgili kısıtlamalar getirir, ancak tehlikeli veya okunamaz durumdadır ve bu nedenle "zararlı" olarak kabul edilir.

Şimdi bunu kötüye kullanalım!

Şirketinizdeki her geliştiricinin kullanması gereken yeni kodlama standartlarını tasarlamayı amaçlayan küçük bir standardizasyon komitesinin üyesi olarak kabul edilirsiniz. Diğerlerine göre, gizlice bir uğursuz organizasyonun işindesiniz ve şirketi sabote etmek için göreviniz var. Kodlama standardına, daha sonra geliştiricilere engel olacak bir veya daha fazla giriş önermek zorundasınız. Ancak, bunu derhal netleştirmemek için dikkatli olmalısınız, aksi takdirde standarda kabul edilmeme riskini alırsınız.

Başka bir deyişle, meşru görünen ve diğer komite üyeleri tarafından kabul edilme şansı yüksek olan kodlama standardına kurallar getirmelisiniz . Projeler başladıktan ve kodlara sayısız çalışma saati yapıldıktan sonra, bu kuralları kötüye kullanabilmelisiniz (örneğin, bir teknik özellik ile veya çokdeğişmez yorum) aksi takdirde normal ve iyi kalitede kodu standarda karşı olarak işaretlemek. Bu nedenle, onu yeniden tasarlamak için çok çaba sarf etmeleri gerekiyor ve kurallar bu noktadan itibaren onları engelleyecektir, ancak kurallar bir süredir aktif olduğu için saf momentum bu rolleri canlı tutacak ve önemli çatışmalar olduğu için farklı yönetim düzeyleri arasındaki çıkarların diğer yöneticiler muhtemelen kuralları canlı tutacaktır (hatalarını kabul etmek aptalca olur!), bu nedenle şirketi engelliyor! Mwahahahahaaa!

puanlama

En yüksek oy alan cevap, ilk geçerli girişten yaklaşık 2 hafta sonra kazanır. İyi bir cevap için bir fikrim var, ancak birkaç gün sonra başkası aynı fikirde olabileceği için bunları yayınlayacağım ve onları zevkten çıkarmak istemiyorum. Tabii ki, kendi cevabım, skor ne olursa olsun, diğerlerinin üzerinde kabul edilmeyecektir.

Seçmenlerin, boşlukların ne kadar iyi saklandıklarına ve geliştiricilere ne kadar sinir bozucu olduklarına dayanarak cevaplamaları için teşvik ediliyor.

Kurallar ve düzenlemeler

• Kural veya kurallar, yukarıdaki örnekte olduğu gibi profesyonelce yazılmış görünmelidir
• Kurallar orijinal görünmelidir ( "tüm değişkenler en az bir alt çizgi, bir büyük harf, bir küçük harf ve iki sayı içermelidir" gibi şeyler kabul edilmezler) kabul edilmezler. komite) ve onların yararı hemen belli değilse, iyi bir gerekçe göstermelisiniz.
• Geliştiricilerini daha sonra sabote etmek için kurallarınızı kullanmanın / kötüye kullanmanın bir yolunu bulmanız gerekir. Başka kurallardaki belirsizlikleri kötüye kullanabilir veya kendi başlarına zararsız olan ancak bir kez bir araya getirilen birden çok kuralı kullanabilirsiniz!
• Yazınızın sonunda kuralları nasıl kötüye kullanabileceğinize dair bir açıklama yapmalısınız.
• Kullanılan dil ezoterik bir dil olmamalıdır. Gerçek projelerde yaygın olarak kullanılan bir dil seçilmelidir, bu nedenle C benzeri sözdizimi olan diller (Golfscript gibi şeyler) tercih edilir.

C / C ++

Kural 1: sekizli sabitleri kullanılmayacak

Gerekçe: Sekizli sabitler karışıklığa neden olabilir. Örneğin, çizgi üzerinde gündelik bir bakış const int coefficients[] = {132, 521, 013, 102};
, dizideki sayılardan birinin sekizlik olarak tanımlandığı gerçeğini kaçırabilir.

Daha da kötülük yapmak istiyorsanız, aşağıdakileri ekleyin:

Kural 2: onaltılık sabitler sadece bit işleme bağlamında kullanılmalıdır.

Gerekçe: Eğer bir sabit sayısal bir değeri temsil ediyorsa, ondalık ise daha okunur. Onaltılık bir sabit, sayısal bir değeri değil bit maskesini temsil ettiğini göstermelidir.

Nasıl kötüye kullanılabilir:

Bir dizinin ilk 10 elemanını ekleyen aşağıdaki basit programı izleyin. Bu kod standartlara uygun olmaz.

sum = 0;
for (i = 0; i < 10; i++) 
{
    sum += array[i];
}

Unutmayın, 0tanım başına, sekizlik sabiti. Kural 1 uyarınca, kodun tümü boyunca 0x00 olarak yazılmasını gerektiren rahatsız edicidir. Kural 2'ye göre, daha da sinir bozucu.

piton

Kural 1: Tüm kod bayt kodunu -OOoptimize eden bayrak kullanılarak derlenmelidir . Boyut ve verimlilik için optimize edilmiş bytecode istiyoruz!

Kural 2: Testler, üretime konacak kodun "artefaktına" karşı çalıştırılmalıdır. Denetçilerimiz buna ihtiyaç duyuyor.

Kullanarak ifadeleri -OOkaldırır assert. Kural 2 ile birleştirildiğinde, bu durum asserttestlerde ifadelerin kullanımını etkili bir şekilde yasaklar . İyi eğlenceler!

Bu bir Node.JS projesi içindir.

Bölüm 3 - Hız ve verimlilik esastır

Kural 3.1: Dosyalar maksimum 1kb'de tutulmalıdır. Bundan daha büyük dosyaların ayrıştırılması çok uzun sürüyor.

Kural 3.2: 3 seviyeden daha derin işlevleri iç içe geçirmeyin. V8 motoru birçok değişkeni takip etmeli ve bunun gibi derin kapaklar çalışmayı zorlaştırmakta, genel yorumu yavaşlatmaktadır.

Kural 3.3:require() Kaçaklardan kaçının .

Kural 3.3.1: Herhangi bir modül require()d require()3 den daha derin olmamalıdır. Derin require()zincirler hem bellek kullanımı hem de hız açısından pahalıdır.

Kural 3.3.2: Çekirdek modüller require(), require()içlerinde kaç kez olursa olsun, tek sayılır .

Kural 3.3.3: Harici modüller maksimum 2 require()sn olarak sayılır . Temel modüllerle aynı esnekliği sağlayamıyoruz, ancak modül yazarlarının verimli kod yazdığını varsayabiliriz.

Kural 3.4: Her ne pahasına olursa olsun senkronize aramalardan kaçının. Bunlar genellikle uzun zaman alır ve olay döngüsünün devam etmesini engeller.

Nasıl kötüye kullanılabilir:

Kural 3.1 ve 3.3 birlikte iyi çalışmaz. require()Zincirde maksimum 1kb ve 3 s'nin altında tutularak başarılı olmak için baskı altında kalacaktır.
Kural 3.2 ve 3.4 neredeyse uyumsuz. 3.4 senkron aramaları yasaklar; 3.2, geri arama sayısını sınırlayarak gelişmiş zaman uyumsuz çalışmayı zorlaştırır.
Kural 3.4, tüm dürüstlükle, gerçek için izlenmesi iyi bir kuraldır. 3.1, 3.2 ve 3.3 tamamen sahtedir.

JavaScript (ECMAScript)

7.3.2: Düzenli ifade değişmezleri

Normal ifade değişmezleri kullanılmamalıdır. Özellikle, kaynak kodunun aşağıda tanımlanan RegularExpression nonterminaliyle eşleşen herhangi bir alt dizeyi içermemesi gerekir .

RegularExpression     :: '/' RegularExpressionBody '/'
RegularExpressionBody :: [empty]
                         RegularExpressionBody [any-but-'/']

[empty] , boş dizeyle eşleşir ve [any-but - '/'] , '/' işaretini içeren tek karakterli dizelerle eşleşir U+002F.

gerekçe

Düzenli ifadeler genellikle okunabilirlik nedenleriyle önerilmemektedir. Düzenli ifadelere başvurmak yerine geleneksel dize işlemleriyle kodu anlamak genellikle daha kolaydır. Daha da önemlisi, birçok normal ifade motoru, subpar performans sunar. Düzenli ifadeler , JavaScript bağlamındaki güvenlik sorunlarıyla da ilişkilendirilmiştir .

Bununla birlikte, Kuruluş ™, düzenli ifadelerin ara sıra iş için en iyi araç olduğunu kabul eder. Bu nedenle, RegExpnesnenin kendisi yasaktır.

(Dilbilgisinin sözdizimi, kendisini [tanımladığı birine değil] ECMAScript spesifikasyonuna karşılık gelir.

Numara

Aşağıdaki program uygun değildir:

// sgn(x) is -1 if x < 0, +1 if x > 0, and 0 if x = 0.
function sgn(x) {
  return x > 0?  +1
       : x < 0?  -1
       :          0
}

Yukarıda verilen RegularExpressionBody nonterminal için yapımlar , açık bir özyinelemeye dayanarak BNF'de listeleri ifade etmenin ortak bir yolunu gösterir. Buradaki hile, "tesadüfen" boş dize RegularExpressionBody olarak izin veriyor , öyle ki dize //kaynak kodunda yasaklanmış. Fakat kim yine de tek satırlık yorumlara ihtiyaç duyar? C89 ve CSS sadece /* */blok yorumlara izin verirken her şey yolunda gözüküyor .

C #

12.1 Programın durumunu etkileyen statik yöntemler yasaktır.

Bunun nedeni, özellikle bazı durumları değiştiren statik bir yöntemin sonuçlarını güvenilir bir şekilde test etmenin zor olmasıdır.

12.2 Statik yöntemler deterministik olmalı

Statik yöntem bir girdi alır ve bir çıktı verirse, sonuç, statik yöntem aynı girdiyle her çağrıldığında aynı olmalıdır.

Neden

C # programının giriş noktası özel statik yöntem olan 'main'. İlk kural gereği, bu artık yasaktır çünkü kural, yalnızca kamuya açık, korunan veya iç yöntemlerin bu kurala uyması gerektiğini belirtmeyi unutur. Eğer gerçekten test yapmak endişeliyse, sadece kamu yöntemlerinin kural 1'e uyması gerekir. Ana, program başarısız olursa programın bir hata kodu vermesi nedeniyle kural 2'yi de bozabilir, bu giriş parametrelerinden bağımsız olarak oluşabilir. Örneğin, program bir dosya bulamayabilir veya doğru şekilde kurulmamış diğer sistemlere bağımlı olabilir.

JAVA / YAY

4.2 Üretim Kodunda Yansıma Kullanımı

Yansıma, kaynak kodumuzun kısıtlı kısımlarına erişmek için Üretim Kodunda yansıma kullanmak kesinlikle yasaktır.

Numara

Spring, desteklediği nesneleri örneklemek ve yönetmek için teknik olarak yansıma kullanır. Bu kuralı uygulayarak, tüm Spring hizmet programı kaldırılmalıdır.

Web sitesi kodlaması

666.13 UTF-8 kullanılmamalıdır ve yerine UTF-7 kullanılır.
Gerekçe: UTF-7, özellikle yaptığımız Arap ülkelerinden kullanıcıları hedeflerken UTF-8'den daha verimlidir.

Nasıl kötüye kullanılabilir:

HTML5 özellikle UTF-7'ye izin vermiyor. Bu, modern tarayıcıların desteklemeyeceği anlamına gelir. Tüm testler IE 11 gibi bir tarayıcıda yapılırsa, çok geç olmadan hiç kimse bunu fark etmeyecektir.

JavaScript Bitwise Operatörleri

1.9 Bitsel emsallerinden çok daha hızlı olmadıkça çarpma, bölme veya döşeme kullanmazsınız. Sırasıyla bit bit operatörleri <<, >> ve ~~ ile değiştirilir.
Gerekçe: Bitsel operatörler daha verimlidir.

Nasıl kötüye kullanılabilir:

Çarpma veya bölme yerine << veya >> kullanılması büyük sayılarla işlem yaparken sorunlara neden olur. Ayrıca, işlem önceliğini ve ondalık noktaları dikkate almazlar. İkili tilde, negatif bir sayı verdiğinizde farklı değerler döndürür.

JavaScript (ECMAScript)

7.3.1: Tanımlayıcı kurallar

Sınırlayıcılar, tanımlayıcının ne tür tanımlayıcı olduğuna bağlı olarak belirlenir. Tanımlayıcılar Değişken , Sabit , İşlev ve Yapıcı türlerine ayrılır ; bakınız 5.3. Kısıtlamalar aşağıda verilmiştir.

• Değişken: İlk karakter küçük harfli bir karakter olmalıdır. Bir tanımlayıcı içerisindeki kelimeleri ayırmak için deve çantası (bkz. 1.3) kullanılmalıdır.

• Sabit: Tanımlayıcı yalnızca büyük harf karakterlerden ve alt çizgilerden ('_', U+005F) oluşmalıdır . Bir tanımlayıcı içindeki kelimeleri ayırmak için alt çizgiler kullanılmalıdır.

• İşlev: İşlevler, Tanımlayıcı türü ile aynı kurallara uymalıdır .

• Yapıcı: İlk karakter bir büyük harf karakter olmalıdır. Bir tanımlayıcı içerisindeki kelimeleri ayırmak için deve çantası (bkz. 1.3) kullanılmalıdır.

gerekçe

Okunabilir tanımlayıcı adları, sürdürülebilirlik için çok önemlidir. Tanımlayıcıları iyi bilinen sözleşmelerle sınırlandırmak aynı zamanda farklı kod tabanları arasında geçişi kolaylaştırır. Bu özel kurallar, Java ™ programlama dili için standart kurallardan sonra modellenmiştir [1] .

Numara

JQuery ekibine, "global jQuery nesnesi" için en yaygın olan adın bu ad kuralına uyduğunu bildirmekten pişmanım. Neyse ki, onlar çoktan düşündüm ve her iki sağlamak ettik $ve jQueryküresel adlarıyla aynı nesneye atıfta. Kullanıcı tabanının her yerden $, jQueryher yere geçmek için istekli olmayabileceğini hayal ediyorum .