Nasıl Sürdürülemez Kod Yazılır?

Yaşam için garantili bir iş ;-)

Giriş

Yetersizlikle açıklanabilecekleri, muzipliğe ithaf etmeyin.
- Napolyon

Java programlama alanında yaratıcı iş fırsatları ile ilgilenirken, sürdürülmesi imkansız olan ve arkanızdan gelenlerin en basit değişiklik için bile yıllarca uğraşmasını sağlayan kod yazma sanatını ustalardan öğrenme şansına sahip oldum. Eğer bu kuralların tümünü sadık kalırsanız, kendinize kod sürdürmenin cehenneminde ömür boyunca sürecek bir işi garantilemiş olursunuz. Ayrıca, eğer bu kuralların tümünü adımı adımına takip ederseniz, artık kod sürdürmeyeceksiniz!

Ama kendinizi bu kadar yormanıza gerek yok. Kodunuz umut verici bir şekilde sürdürülemez gözükmeyecek, yalnızca o yolda olacak. Aksi taktirde, tamamen sürdürülemez gözüken bir kod yeniden yazılma ya da yeniden elden geçirilme edilme riski taşıyabilir!

Genel Prensipler

Quidquid latine dictum sit, altum sonatur.
- Latince söylenen herşey kulağa bilgince gelir.

Bakım programcısı, kodunuzu bir tuvalet kağıdı rulosundan bakıyormuş gibi görür. Tek bir zamanda, kodunuzun yalnızca tek bir parçasını görebilir. Sizse, programcınızın bu yolla asla büyük resmi göremeyeceğinden emin olmak istersiniz. Bu yüzden aradığı kodu mümkün olduğu kadar bulunması zor hale getirmek istersiniz. Ama en önemlisi, herhangi bir şeyi rahatça gözardı etmemesi için işi elinizden geldiğince karmaşıklaştırırsınız.

Programcılar geleneklere bağlılıktan memnuniyet duyan insanlardır. Basitçe, bir geleneği değiştirdiğiniz zaman, bakım programcısının kodunuzun her satırını büyüteçle okumasına yol açarsınız.

Artık her dil özelliğinin kodu sürdürülemez hale getirdiği fikrini kavramaya başladınız -- aslında o kadar değil, sadece hakkıyla kötüye kullanıldığı zaman.

İsimlendirme

Humpty Dumpty küçümser bir tavırla, "Bir kelime kullandığım zaman," dedi, " yalnızca ifade etmesini istediğim anlama gelir - ne daha fazlası ne de daha azı."
- Lewis Carroll -- Aynanın İçinden, Bölüm 6

Yeni Doğanlar İçin İsim'in Yeni Kullanımı

Kendinize bir Yeni Doğanlar İçin İsimler kitabı aldığınız zaman değişkenleri isimlendirmekle ilgili sıkıntınız kalmaz. Fred harika bir isim, ve yazımı da kolay. Eğer yazımı kolay değişken isimleri arıyorsanız adsf'yi ya da DSK klavye kullanıyorsanız aoeu'yu deneyebilirsiniz.

Tek Harfli Değişken İsimleri

Eğer değişkenlerinizi a, b, c şeklinde isimlendirirseniz, basit bir metin editörü kullanarak aynı değişkenin diğer örneklerini aramak imkansız hale gelir. Aynı zamanda, hiçkimse bu değişkenlerin ne iş yaptığı hakkında fikir sahibi olamaz. Eğer herhangi birinin FØRTRAN'dan bu yana süregelen, indeks değişkenleri için i, j ve k kullanma geleneğini ii, jj ve kk olarak değiştirdiğini görürseniz, onları hemen İspanyol Engizisyonu'nun [ÇN #1] kafirlere yaptıkları hakkında uyarın.

Yaratıcı Yazım Hataları

Eğer tanımlayıcı değişken ya da fonksiyon isimleri verecekseniz, yazım hataları yapın. Bazı değişken isimlerini ya da fonksiyonları yanlış isimlendirirken, diğerlerinde düzgün kullanmanız (SetPintleOpening SetPintalClosing gibi) efektif olarak grep ya da IDE arama tekniklerini safdışı bırakmanızı sağlar. Gerçekten harika bir metot. tory ya da tori'yi heceleyerek vizyona uluslararası bir tat katın.

Soyut Olun

Fonksiyonları ya da değişkenleri isimlendirirken, it, everything, data, handle, stuff, do, routine, perform gibi soyut kelimeler ve rakamlar seçmeye özen gösterin. Örneğin: routineX48, PerformDataFunction, DoIt, HandleStuff ve do_args_method.

Kısaltmalar

Kodu kısa tutmak için isimlendirmede kısaltmalar kullanın. Çünkü esas oğlan asla kısaltma tanımlamaz; onları genetik olarak otomatikman anlar.

Eşanlamlı Vekiller

Sıkıcılığa aman vermemek için, display, show, present gibi alternatif kelime dağarcığınızda, aynı anlama gelen ne kadar kelime varsa, aynı işi yapan değişken ya da fonksiyonlarda kullanmaya çalışın. Yine de hiç yoktan, bu isimler arasında bazı kurnaz farklılıklar olabilir. Buna rağmen iki fonksiyon arasında işleyiş bakımından ciddi fark varsa, her iki fonksiyonu da tanımlamak için mutlaka aynı kelimeleri kullanın (örneğin print "dosyaya yaz" anlamına geldiği gibi, "yazıcıdan çıktı al" ya da "ekrana bas" anlamlarına gelebilir). Her ne koşul altında olursa olsun, projeye özel bir kelime dağarcığı ya da özel lügat kullanmak ölümle cezalandırılır. Bu eylemi gerçekleştirmek, herşeyden önce yapısal dizayn prensibi bilgi saklama'nın ihlali olacağı için, profesyonelce bir davranış kabul edilmez.

Diğer Dillere Ait Çoğul Eklerini Kullanın

Bir VMS betiği kayıtları bir kaç "Vaxen"'den dönen "statii"'ler ile takip ediyor. Esperanto , Klingon ve Hobbitese dilleri [ÇN #2] bu amaçla kullanılmaya hak kazanıyorlar. Örneğin Esperanto kullanarak çoğullamak için değişkenlerin sonuna oj getirin, örn: pluraloj. Unutmayın, bunu dünya barışı için yapıyorsunuz.

BüYÜk vE KüÇüK HaRFleR

Değişkenlerinizi isimlendirirken tamamen tesadüfi olarak seçtiğiniz bir hecenin ilk harfini büyük yapın. Örneğin ComputeRasterHistoGram() gibi.

İsimleri Yeniden Kullanın

Kullandığınız programlama dili sizi ne kadar kısıtlamaya çalışırsa çalışsın, sınıflara, yapılandırıcılara, metotlara, üye değişkenlere, parametrelere ve yerel değişkenlere aynı ismi vermeye özen gösterin. Ekstra noktalar için, yerel değişkenleri {} blokları arasında kullanın. Buradaki amacınızın bakım programcısını, her değişken için faaliyet alanını dikkatlice analiz edip bulmasını sağlamak olduğunu unutmayın. Java'ya özel olarak, basit metotları yapılandırıcılar gibi maskelemeye özen gösterin.

Eğik Harfler

Değişken isimleri için eğik karakterler kullanın. Örneğin
typedef struct { int i; } ínt;
kodunda ikinci ínt'in í'si eğik karakterdir. Böylece basit bir metin editöründe, bu değişkenin eğik karakterini asla açamama gibi harika bir iş başarmış olursunuz.

Derleyicinin Değişken İsmi Uzunluğu Limitini İstismar Edin

Eğer derleyici değişkenlerin yalnızca, örneğin ilk 8 karakterini anlayabiliyorsa, o zaman var_unit_update() ve var_unit_setup()'da olduğu gibi, değişkenlerinizin ilk bölümlerini aynı, son bölümlerini değişik karakterlerden oluşturun. Bu sayede derleyici her iki değişkene de var_unit muammelesi yapsın.

Altçizgi, Kadim Dostumuz

_ ve __ karakterlerini tanıtıcı olarak kullanın.

Mix Languages

İki dili (insan ya da bilgisayar) rastgele olarak serpiştirin. Eğer patronunuz kendi dilini kullanmanızda ısrar ediyorsa, ona kendi dilinizle düşüncelerinizi daha iyi organize edebildiğinizi söyleyin.

Uzatılmış ASCII Karakterler

Özellikle ß, Ð ve ñ gibi uzatılmış ASCII karakterler değişken isimleri için mükemmel seçimlerdir. Bu tür değişkenleri bir metin editörüne kopyala/yapıştır yapmadan yazmak neredeyse imkansızdır.

Diper Dillerden Kelimeler

Yabancı dillerin kelime dağarcığı da, değişken isimlendirme için potansiyel bir kaynaktır. Örneğin point için Almanca punkt kelimesini kullanabilirsiniz. Bakım kodcuları da, sizin engin Almanca bilginiz olmaksızın, çoklu dil destekli anlam çözme deneyimi yaşarlar.

Matematikten İsimler

Matematiksel operatörler olarak maskelenebilecek değişken isimleri seçin. Örneğin:
openParen = (slash + asterix) / equals;

Gözkamaştırıcı İsimler

Değişken isimlerinizi yerli yersiz çağrışımlar yaptıracak kelimelerden seçin. Örneğin:
karamurat = (battalgazi + uzaygemisi) / tanri;
Bu sayede kodu okuyan kişi işin mantığından sıyrılıp kelimelerin anlamı üzerinde derin düşüncelere dalmasını sağlarsınız.

Yeniden İsimlendirin ve Yeniden Kullanın

Bu numara özellikle, bir çok şaşırtmacalı tekniğe karşı dayanıklı olan Ada'da işe yarar. Aslında sizin kullandığınız tüm değişkenleri ve paketleri önceden isimlendirenler morondur. Onları ikna etmektense, basitçe değişkenleri yeniden isimlendirmeyi deneyin. Ancak yine de açıkgözlülere tuzak olması açısından, eski değişkene ait bir kaç referansı ortada bırakmayı unutmayın.

i'yi Ne Zaman Kullanmalı?

i'yi asla iç döngü değişkeni olarak kullanmayın. Ancak i'yi başka herhangi bir amaçla, özellikle de sayı olmayan değişkenler için çömertçe kullanabilirsiniz. Benzer şekilde döngü indeksi olarak n kullanabilirsiniz.

Kurallari İstismar Edin

Sun Java Kodlama Kuralları'nı boşverin, nasıl olsa Sun var.. Neyse ki kuralları ihlal ettiğiniz zaman derleyici dedikodunuzu yapmıyor. Buradaki amaç değişik durumlara göre farklı isimlendirmeler kullanmak. Eğer büyük/küçük harf kurallarına uymanızda ısrar ediliyorsa, yine de seçimin belirsiz olduğu yerlerde kuralları çiğneyebilirsiniz. Örneğin inputFilename ve inputfileName gibi. Kendi karmaşık isimlendirme kurallarınızı yaratın ve herkesi bunlara uymadıkları için azarlayın.

Küçük Harfli l 1 Rakamına Benzer

Uzun sabitleri isimlendirmek için küçük harfli l kullanın. Örneğin 10l'nin, 10L'ye göre 101 ile karıştırılma olasılığı daha yüksektir. uvw wW gq9 2z 5s il17|!j oO08 `'" ;,. m nn rn {[()]} karakterleri için belirsizliği giderebilecek bütün karakterleri yasaklayın. Yaratıcı olun.

Global'lerin Özel Olarak Yeniden Kullanılması

A modülünde global bir dizi tanımladıktan sonra, başlık dosyasında B modülü için aynı isimde bir özel dizi daha tanımlayın. Böylece aslında öyle olmasa da B modülünde kullandığınız dizi global gözüksün. Bu çakışma için yorum kısımlarında hiçbir referans da girmemeye özen gösterin.

Geridönüşümlü Yeniden Ziyaret

Değişken isimlerini aykırı yollarla yeniden kazanmak için mümkün olduğunca faaliyet alanları ile oynayın. Örneğin, global değişkenler A ve B'ye, ve foo ile bar fonksiyonlarına sahip olalım. Eğer A değişkeninin düzgünce foo'ya, B'nin de bar'a geçeçeğini biliyorsanız, fonksiyonlarınızı foo(B) ve bar(A) şeklinde tanımlayın. Böylece fonksiyonlarınızın içinde A her zaman B gibi refere edilecek ve B de A gibi. Daha fazla fonksiyon ve globalle birbirinin ismini kullanarak karşılıklı karışıklık çıkaran ağlar yaratabilirsiniz.

Değişkenlerinizi Geridönüşümlü Yapın

Faaliyet alanı kuralları ne derse desin, varolan bağlantısız değişken isimlerini tekrar kullanın. Benzer şekilde, aynı geçiçi değişkeni apayrı iki amaç için kullanmalısınız (yığın yuvalarından tasarruf etmek için). Uzun bir metodun en başında bir değişkene değer atayın, daha sonra kurnaz bir şekilde değişkenin anlamını değiştirin. Örneğin 0-tabanlı bir koordinattan 1-tabanlı bir koordinata çevirmek gibi. Bu değişikliği dökümante etmediğinizden emin olun.

Cd wrttn wtht vwls s mch trsr

Değişken ya da metot isimlerinde kısaltma kullanırken, aynı kelimenin çeşitli versiyonları ile ortamdaki sıkıcı havayı dağıtın. Bu metot kodunuzun yalnızca belli bir parçasını anlamak için metin araması kullanan serserileri mahvetmekte size yardımcı olur. Ayrıca bir değişken ismini, değişik imla okuyuşları ile geliştirebilirsiniz. Örneğin uluslararası colour kelimesini Amerikan kullanışıyla color ve sokak ağzı ile kulerz olarak kullanabilirsiniz. Eğer kelimeleri tam olarak okursanız, kelimeleri telaffuz etmek için tek bir seferde yalnızca bir olasılığınız olur. Bu durumsa bakım programcısının hatırlaması için çok kolaydır. Oysa önce kelimeleri çeşitli şekillerde kısaltıp, sonra telaffuz ederseniz elinize sayısız değişik isim geçer. Ve bonus olarak, bakım programcısının bunların ayrı değişkenler olduğunu farketmemesi gerekir.

İsimleri Yanıltıcı Hale Getirin

Her metodun, taşıdığı ismin öne sürdüğünden daha fazlasını (ya da azını) yaptığına emin olun. Basit bir örnek verirsek, isValid(x) isimli bir metot yan etki olarak x'i ikiliğe çevirdikten sonra sonucu veritabanına yazabilmelidir.

m_

C++ dünyasının bir isimlendirme kuralı da üyelerden önce "m_" kullanımıdır. Bu kullanım sayesinde bunların metotlardan farklı olduğunu anlamaya yardımcı olması umulur; ve metodu unuttuğunuz sürece ve "m" harfi ile başlıyorsa zaten amacımıza ulaşmışız demektir.

o_apple obj_apple

Bir sınıfın her örneği için önek olarak "o" ya da "obj" kullanırsanız, bu sizin büyük, polimorfik bir resim düşündüğünüzü gösterir.

Macar Gösterimi

Macar Gösterimi kaynak kodun şaşırtılması tekniğine karşı taksiksel bir nükleer silahtır. Bir bakım programcısını iyi planlanmış bir Macar Gösterimi saldırısından daha kolay öldürebilecek başka bir taktik yoktur. Aşağıdaki tavsiyeler, size Macar Gösterimi'nin gerçek amacından saptırmanız için yardımcı olacaktır:
C++'da ve diğer dillerde sabitler için "c" kullanımında ısrarcı olarak bir değişkenin direktman zorla sabit olmasını sağlayın.

O an çalıştığınız dil dışındaki diller için değişik Macar gösterimleri araştırın ve kullanın. Örneğin öneklerde faaliyet alanını belirlerken PowerBuilder "l_" ve "a_" {yerel ve argüman} kullanmakta ısrarcı olun ve C++ kodlarken kontrol tipleri için her zaman VB-esque stilini kullanın. Bu süre zarfında MFC kaynak kodlarının Macar kontrol tiplerini kullanmadığını tamamen gözmezden gelin.

Her zaman, sık kullanılan değişkenlerin yanında ek bilgi olması gerektiğini söyleyen Macar prensibini ihlal edin. Bunu yaparken yukarıda saydığımız ipuçlarını da gözönünde bulundurun ve her sınıf tipi için özel bir önek vermeye özen gösterin.

Macar gösteriminin getirdiği, fonksiyon parametrelerinin ve diğer kullanılma olasılığı fazla sembollerin anlamlı isimlere sahip olması gerektiği prensibini rahatça çiğneyin.

Değişken isimlendirmede tamamen alakasız Macar gösterimlerini kullanın. Gerçek dünyadan bir örnek olarak "a_crszkvc30LastNameCol"'a bakalım. Bu değişkenin bir sabit, bir referans, "LastName" isimli ve Varchar[30] tipli, tablonun birincil anahtarı olan bir veritabanı kolonundaki bilgiyi tutan bir fonksiyon argümanı olduğunu anlaması, bir grup bakım mühendisinin yaklaşık 3 gününü alır. "Tüm değişkenler public olmalıdır" prensibi ile birleştirildiğinde bu teknik binlerce satır kaynak kodunu anında kullanılamaz yapma gücüne sahiptir!

İnsan beyninin aynı anda yalnızca 7 bilgi parçası tutabildiği gerçeğini avantaja çevirin. Örneğin yukarıdaki standarta göre yazılmış bir kod aşağıdaki özelliklere sahiptir:

• basit bir atama ifadesi, beraberinde 14 parça tip ve isim bilgisi taşır.
• üç parametre geçen ve bir sonuca atanan basit bir fonksiyon çağrısı 29 parça tip ve isim bilgisi taşır.
• Özellikle bakım programcısı kontrol ettiği blokları ekranda aynı anda göremiyorsa, karmaşık bir içiçe geçmiş yapı ile kısa terim hafızasını mahvetmek oldukça basittir.

Yeniden Isıtılmış Macar Gösterimi

Macar gösterimindeki diğer bir numara da, bir değişkenin tipini değiştirmek, ama ismini aynı bırakmaktır. Bu numara, istisnasız olarak Win16 :- WndProc(HWND hW, WORD wMsg, WORD wParam, LONG lParam)'dan Win32 WndProc(HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam)'a geçirildiği tüm windows uygulamalarında gerçekleştirilmiştir. Böylece w ile başlayan değerler word'leri temsil etmeleri gerekirken, aslında long'ları temsil etmiştir. Bu girişimin asıl etkisi Win64 göçü sırasında tüm parametreler 64 bit genişliğine çevrilirken eski "w" ve "l" öneklerinin sonsuza dek kalması gerektiğinde olmuştur.

Çevir, Yeniden Kullan, Yeniden Çevrime Sok

Eğer geriçağrımlar için veri tutacak bir yapı tanımlayacaksanız, her zaman PRIVDATA yapısını çağırın. Her modül kendi PRIVDATA'larını tanımlayabilir. Örneğin VC++'da, eğer bir PRIVDATA değişkeniniz varsa ve bu değişkeni pencerenizde kullanmak istiyorsanız, bu durumun hata ayıklayıcıyı şaşırtmak ve hangi PRIVDATA'yı kullanacağını bilemediği için rastgele bir tanesini seçmek gibi avantajları vardır.

Meçhul film referansları

blue yerine LancelotsFavouriteColour gibi sabit isimleri kullanın ve sabite $0204FB değerini verin. Böylece aslında rengin ekranı masmavi yapacağı gün gibi ortada iken, bakım programcısı herhangi bir grafik aracı kullanarak 0204FB renginin nasıl gözüktüğüne bakmak zorunda kalsın. Yalnızca Monty Python ve Holy Grail ile haşır neşir olanlar Lancelot'un favori renginin mavi olduğunu bilir. Ve eğer bir bakım programcısı Monty Python'u ezberden okuyamıyorsa, programcılıkla uzaktan yakından ilgisi yoktur.

Kamuflaj

Bir böceğin yüzeye çıkması ne kadar zaman alıyorsa, bulması da o kadar zordur.
- Roedy Green

Yorummuş Gibi Maskelenen Kod ya da Tam Tersi

Aşağıdaki kod parçasının iç kısımlarındaki kod aslında yorumdur fakat ilk bakışta kod gibi gözükür.
for(j=0; j<array_len; j+ =8)
{
total += array[j+0 ];
total += array[j+1 ];
total += array[j+2 ]; /* Main body of
total += array[j+3]; * loop is unrolled
total += array[j+4]; * for greater speed.
total += array[j+5]; *
total += array[j+6 ];
total += array[j+7 ];
}
Kod renklendirmesi olmadan, bu üç satırın kod mu yorum mu olduğunu farkedebilir miydiniz?

namespace'ler

Yapılar/union'lar ve typedef yapılar/union'lar C dilinde farklı namespace'lerdir (C++'da değil). Hem union'ların ya da yapıların namespace'inde aynı isimleri kullanın. İkisini de olabildiğince birbiriyle uyumlu hale getirin.
typedef struct {
char* pTr;
size_t lEn;
} snafu;

struct snafu {
unsigned cNt
char* pTr;
size_t lEn;
} A;


Makro Tanımlamalarını Gizleyin

Makro tanımlamalarını saçma sapan yorumların arasına gizleyin. Programcı bir süre sonra sıkılacak ve yorumları okumayı bırakacaktır. Böylece orada duran makroyu asla farkedemeyecektir. Makronun aslında gayet normal bir atama yapılıyormuş gibi gözükmesine dikkat edin.
#define a=b a=0-b

Meşgul Görünün

define ifadelerini sanki fonksiyonların argümanlarını yorumluyormuşsunuz gibi kullanın, örneğin:
#define fastcopy(x,y,z) /*xyz*
...
fastcopy(array1, array2, size); /* hiçbir şey yapılmıyor */

Değişkenleri gizlemek için uzatma kullanın

Aşağıdaki tanımlamayı
#define local_var xy_z
"xy_z"'yi bölerek iki satır halinde yazabiliriz:
#define local_var xy\
_z // local_var OK
Böylece xy_z için yaptığımız global bir arama sonucunda elimize hiçbir sonuç geçmez. C önişlemcisi için bir satırın sonundaki "\" karakteri, bu satırın bir sonrakine yapıştırılması gerektiği anlamına gelir.

Anahtar Kelimeler Gibi Gözüken Keyfi İsimler

Dökümantasyon yaparken, bir dosya adı kullanacaksanız "file" ismini kullanın. Asla "Charlie.dat" ya da "Frodo.txt" gibi dosyaların ismini açıkça vermeyin. Genel olarak, sanki rezerve edilmiş anahtar kelimeler gibi duran dosya adları seçmelisiniz. Örneğin parametreler ya da değişkenler için bazı isim seçenekleri "bank", "blank", "class", "const ", "constant", "input", "key", "keyword", "kind", "output", "parameter" "parm", "system", "type", "value", "var" and "variable " olabilir. Eğer gerçekten rezerve edilmiş ve derleyici tarafından reddedilecek anahtar kelimeler seçtiyseniz daha iyi olur. Eğer işinizi güzel yaptıysanız, kullanıcılar rezerve edilmiş anahtar kelimeler ile sizin örneğinizdeki keyfi değişkenler arasında kalacaklardır.

Kod Ekran İsimleri ile Uyuşmamalıdır

Değişken isimlerinin ekrana basarken kullandığınız etiketlerle değişken isminin hiçbir bağlantısı olmamasına dikkat edin. Örneğin ekrandaki etiket alanı "Postal Code"'sa kodunuzda ilişkili değişken ismi "zip" gibi bağlantısız bir isim olmalı.

İsimleri Değiştirmeyin

Kodu iki kısımda senkronize etmek için global yeniden isimlendirmenin yerine, aynı sembol için çoklu TYPEDEF'ler kullanabilirsiniz.

Yasaklı Globalleri Nasıl Gizlersiniz?

Global değişkenler "kötü" olarak benimsendikleri için, bir yapı tanımlayıp içine globallere koymak istediğiniz herşeyi koyun. Bunu yaparken EverythingYoullEverNeed gibi yaratıcı bir isim verebilirsiniz. TÜm fonksiyonların bu yapıya işaretçi almalarını sağlayın. Böylece global kullanmıyormuşsunuz izlenimi verirlen, aslında herşeye bir "kulp" ile ulaşırsınız. Sonra da bir statik tanımlayarak tüm kodun aynı kopyayı kullanmasını sağlayın.

Örnekleri Eşanlamlıları Kelimeler Kullanarak Saklayın

Bakım programcıları, yaptıkları değişikliklerin basamak halinde ilerleyip ilerlemeyeceğini görmek için değişken ismini kullanarak global bir arama yaparlar. Bunu engellemek için aşağıdaki gibi eşanlamlı değişkenler kullanabilirsiniz:
#define xxx global_var // in file std.h
#define xy_z xxx // in file ..\other\substd.h
#define local_var xy_z // in file ..\codestd\inst.h
Bu tanımlar değişik include dosyalarında bulunuyor. Eğer bu dosyalar farklı dizinlere yerleştirilmişse o zaman yöntemimiz daha da efektif hale gelecektir. Başka bir yöntem de bir ismi her faaliyet alanında kullanmaktır. Derleyici bunların aynı olduğunu söyleyebilir, ama akılsız metin editörü söyleyemez. Maalesef SCIDler sayesinde editörler de tıpkı derleyici gibi faaliyet alanı kurallarını tanır hale geleceği için gelecek onyıl içinde bu yöntemi teknik olarak imkansız hale getirecekler.

Uzun ve Benzer Değişken İsimleri

Çok uzun ve yalnızca tek karakterleri farklı olan değişken ya da sınıf isimleri kullanın ve yalnızca büyük/küçük harfle yazın. Bu iş için ideal bir çift swimmer ve swimner olabilir. Özellikle birbiri ile karıştırılmaya müsait ilI1| ya da oO08 karakterlerini değişkenlerde kullanmaya dikkat edin. Örneğin parselnt ve parseInt ya da D0Calc ve DOCalc gibi. l karakteri, 1 rakamı ile sıkça karıştırıldığı için diğer karakterler arasında ayrı bir yeri vardır. Aynı zamanda rn dizgesi tıpkı m harfine benzediği için bunu da sıkça kullanmanızda yarar var. Böylece swirnrner gibi bir değişken tanımlaması yapabilirsiniz. Ayrıca birbiriyle yalnızca büyük/küçük harf farkı olan değişkenlere de yer verin, HashTable ve Hashtable gibi.

Benzer Görünüşlü Değişkenler

xy_z adında bir değişkenimiz olduğu halde, xy_Z, xy__z, _xy_z, _xyz, XY_Z, xY_z, ve Xy_z gibi başka değişkenler tanımlamamızda hiçbir sakınca yok.

Aşırı Yükleyin ve Sersemletin

C++'da aşırı yükleme kütüphane fonksiyonları #define ile tanımlanırlar. Bu yolla aslında tamamen başka birşey kullanırken, sanki alışılmış bir kütüphane fonksiyonu kullanıyormuşsunuz gibi gözükür.

En İyi Aşırı Yükleme Operatörünü Seçmek

C++'da +,-,*,/ gibi operatörleri aşırı yükleyerek, toplama ya da çıkarma ile hiç alakası olmayan işleri bu operatörlerin yapmasını sağlayabilirsiniz. Ne de olsa Stroustroup bir öteleme operatörünü G/Ç işlemi yapmak için kullanmışsa, siz neden aynı yaratıcılıkta olmayasınız? Eğer + operatörünü aşırı yüklediyseniz kullanımının da i = i + 5; yoluyla olmasına ve i += 5;'ten tamamen farklı anlam taşımasına dikkat edin. Şimdi nadide bir aşırı yükleme örneği inceleyelim. Bir sınıf için '!' operatörünü aşırı yükleyin ancak yaptığınız aşırı yüklemenin reddetme ya da çevirme ile hiçbir alakası olmasın. Daha sonra mantıksal bir değer almak için '!!' kullanmayı deneyin. Ancak bu da mantığı ters çevirir ve [ta ta ta taaam] şimdi de '!!!' kullanmalısınız. Bool 0 ya da 1 döndüren ! operatörü ile ~ bitwise mantıksal olumsuzluk operatörünü karıştırmayın.

new'i Aşırı Yükleyin

"new" operatörünü aşırı yükleyin - bu işlem +-/* operatörlerini aşırı yüklemekten çok daha tehlikelidir. Bu durum eğer aşırı yüklenmiş şey kendi orijinal fonksiyonundan tamamen farklı bir iş yapacaksa top yekün bir tahribata yol açar (ama nesnenin fonksiyonu için hayati gereklilik taşıdığı için değiştirmesi de zordur). Böylece dinamik bir örnek yaratmak isteyen kullanıcılar gerçekten şaşakalırlar. Bu numarayı aynı zamanda "New" adında bir üye fonksiyon yaparak daha da eğlenceli hale getirebilirsiniz.

#define

C++'daki #define, şaşırtmaca için sunduğu eşsiz olanakları ile kendi başına bir araştırma konusudur. Küçük harfli #define değişkenleri kullanırsanız sıradan değişkenler gibi görünecekleri için işiniz daha da kolaylaşır. Önişlemci fonksiyonları için asla parametre kullanmayın. Herşeyi global #define'lar ile yapın. define ve ifdef'lerin zekice kullanımı sayesinde, header dosyalarının kaç kere eklendiğine bağlı olarak farklı şeyler için daha iyi şaşırtmacalar yapabilirsiniz. Bu durum özellikle bir header dosyasını diğeri içine eklendiği durumlarda ortaya çıkar. Aşağıda çılgın bir örnek görülüyor:
#ifndef DONE

#ifdef TWICE

// 3.cü turda tanımlanacak şeyleri buraya ekleyin.
void g(char* str);
#define DONE

#else // TWICE
#ifdef ONCE

// 2.ci turda tanımlanacak şeyleri buraya ekleyin.
void g(void* str);
#define TWICE

#else // ONCE

// 1.ci turda tanımlanacak şeyleri buraya ekleyin.
void g(std::string str);
#define ONCE

#endif // ONCE
#endif // TWICE
#endif // DONE
Bu iş g()'ye bir char* geçtiğinizde daha eğlenceli bir hal almaya başlar, çünkü g()'nin değişik bir versiyonu header'in eklendiği her sefer zaten çağırılmaktadır.

Derleyici Yönergeleri

Derleyici yönergeleri aynı kodun tamamen farklı çalışması için tasarlanmıştır. Bool kısa-çevrim yönerge kodunu aktif halden pasif hale getirmak ya da uzun dizgelerin yönergesiyle oynamak hiç beklemediğiniz olaylara sebep olabilir.

Belgeleme

Her enayi gerçeği söyleyebilir, ama nasıl iyi yalan söyleneceğini bilmek için aklı başında biri gerekir.
- Samuel Butler (1835 - 1902)

Hatalı belgeleme çoğu zaman hiç belge olmamasından daha kötüdür.
- Bertrand Meyer

Yorumlarda Yalan Söyleyin

Faal olarak yalan söylemek zorunda değilsiniz, yalnızca yorumları güncellememeniz işinizi görecektir.

Apaçık Ortada Olanları Belgeleyin

/* i'ye 1 ekliyoruz */ gibi yorumlarla koda tuz biber ekerken, asla bir paket ya da metot hakkında belgeleme yapmayın.

Neden Olmasın?'ı Belgeleyin

Yalnızca bir programın ne yaptığını belgeleyin, ne yapmaya çalıştığını değil. Böylece eğer bir hata varsa, düzeltmek için kodun aslında ne yapması gerektiğine dair en ufak bir ipucu kalmaz.

Apaçık Olanı Belgelemekten Kaçının

Örneğin bir havayolu rezervasyon sistemi yazıyorsanız, başka bir havayolu ekleneceği zaman, kodda en azından 25 yerin tekrar elden geçirilmesi gerektiğini yazın. Ancak nerede olduklarını değil. Böylece sizden sonra gelen ve kodunuzu düzenleme ile ilgili hiç tecrübesi olmayan insanlar kodun her satırını incelemeden ne yapacakları hiçbir fikre sahip olamasın.

Belge Taslaklarının Uygun Kullanımı

Fonksiyon belgeleme prototiplerinin koddan otomatik olarak belgeleme çıkarabildiğini farzedelim. Bu prototipler bir fonksiyondan (ya da bir metot ya da sınıftan) diğerine kopyalanmalıdır ancak doldurulması gereken alanları asla doldurmayın. Eğer herhangi bir sebeple bu alanları doldurmaya zorlanırsanız tüm parametrelerin tüm fonksiyonlar için aynı olmasına ve fonksiyonla alakası olsun ya da olmasın tüm uyarı mesajlarının aynı olmasına özen gösterin.

Tasarım Belgelerinin Uygun Kullanımı

Çok karmaşık bir algoritmayı gerçekleştirirken, klasik yazılım mühendisliği prensiplerini göz önünde bulundurun ve kodlamaya başlamadan önce en ince ayrıntılarına kadar anlattığınız bir tasarım belgesi hazırlayın. Bir belge ne kadar detaylıysa o kadar iyidir.

Aslında yapısal basamaklardan oluşan hiyerarşik ve bu hiyerarşinin için de otomatik numaralandırılmış tekil paragraflardan oluşan bir tasarım belgesi algoritmayı çözebilir. Yazdığınız belgede en az 5 kere iç içe geçmiş başlıklar bölümler olmalı. Bitirdiğinizi düşündüğünüzde, belgede en az 500 tane otomatik numaralandırılmış paragraf olduğundan emin olmalısınız. Örneğin bir paragraf aşağıdaki gibi olabilir (bu gerçek bir örnektir)

1.2.4.6.3.13 - Seçilen hafifletmelerin yapabileceği tüm etkileri gösterir (kısa yalancı kod çıkarıldı).

sonra... (asıl vurucu kısım) bu kodu yazdığınızda bu paragrafların her birine karşılık gelen global fonksiyon aşağıdaki gibidir:

Act1_2_4_6_3_13()
Bu fonksiyonları belgelemeyin. Ne de olsa, tasarım belgesi bunun için var!

Tasarım belgesi otomatik numaralandığından, koddaki herhangi bir değişiklikte belgeyi güncel tutmak imkansız hale gelir (çünkü fonksiyon isimleri, tabii ki, statiktirler ve otomatik-numaralandırılmış değildirler.) Bu sizin için problem değil, çünkü siz zaten belgeyi güncel tutmakla ilgilenmiyorsunuz. Aslında belgede bulabildiğiniz ipuçlarını ne kadar yok edebilirseniz o kadar iyi olur.

Sizden sonra gelenler yalnızca erken tasarım taslaklarını arka odadaki 286 külüstür bilgisayarın yanında bulmalıdırlar. room near the dead 286 computers.

Ölçü Birimleri

Asla herhangi bir değişkenin, girişin, çıkışın ya da parametrenin ölçü birimini feet, metre ya da karton gibi belgelemeyin. Bu para sayarken önemli değil, ama mühendislik işinde büyük önem taşır. Sonuç olarak, değerlerin nasıl alındığını, birimler arası dönüşümde nasıl bir ölçü kullanılacağını asla belgelememelisiniz. Yine de kodun bir iki yerine yanlış ölçü birimlerini yazarak işin içine tuz biber ekebilirsiniz. Eğer gerçekten art niyetliyseniz kendi ölçü biriminizi yapabilir ve herhangi bir yerde tanımlamayabilirsiniz. Eğer birisi size meydan okursa, kendinizin yaptığını ve kayan noktalı sayılar yerine tamsayı kullanabildiğinizi söyleyebilirsiniz.

Gotcha'lar

Kodun hiçbir yerinde gotcha'ları belgelemeyin. Eğer bir sınıfta bir hata olduğundan şüphelenirseniz bu bilgiyi kendinize saklayın. Eğer kodun nasıl yeniden organize edilmesi ya da yazılmasına dair bir fikriniz varsa, gölgelerin gücü adına, kendinize saklayın. Bambi filminde Thumper'ın sözlerini hatırlayın: "Eğer sevimli birşey söylemeyeceksen, hiçbir şey söyleme". Kodu yazan programcı sizin yorumlarınızı okuduğu zaman ne olur? Eğer şirketin sahibi bu yorumları okursa ne yapar? Peki ya müşteri? Kendinizi kovdurtabilirsiniz. Ama belki de "Bunun düzeltilmesi gerek!" diyen anonim bir yorum, özellikle de neyi kastettiği açıkça belli değilse daha çok işe yarar. Belirsizlik en iyisidir, ve kimse kişisel olarak tenkit edilmez.

Değişkenleri Belgelemek

Asla bir değişken tanımlamasına yorum eklemeyin. Değişkenin ne yaptığı, faaliyet alanı, alabileceği deperleri, ölçü birimleri, gösterim formatı, veri girişi kuralları (örn. tamamen doldurulmalı, kesinlikle girilmeli), gelen veriye ne zaman güvenilebileceği vb. gibi bilgiler prosedürel koddan toplanmalıdır.

Yorum İçinde Kötüleme

Koda müdahale ederek diğer yazılım firmalarındakilere, özellikle de eğer işle alakalı ise herhangi bir müdahale edilmesini engelleyin. Koda, diğer yazılım firmalarında çalışanları hedef alarak kötüleme yorumları eklemekten kaçının. Örn:
/* Optimize edilmiş iç döngü.
Bu zımbırtı <math.h>'daki aptal rutinleri kullanarak muhtemelen 50 bellek zamanı
harcayacak Yazılım Servisi AŞ.'de ki dullard için çok akıllıca!
*/
class clever_SSInc
{
.. .
}
Eğer mümkünse özellikle sözdizimi olarak kodun görülebilecek yerlerine hakaret dolu yorumlar yerleştirin, böylece yönetim kodu bakıma yollamadan önce patlatmış olursunuz.

DELİKLİ KARTTA KODLANMIŞ CØBØL İLE YORUM YAZ

Geliştirme ortamı arenasında, özellikle SCIDs gibi ilerlemelere her zaman karşı çıkın. Asla tüm fonksiyonların ve değişken tanımlamalarının bir tık ötenizde olduğu ve söylentilerine inanmayın ve her zaman Visual Studio 6.0'da kodlanmış programınızın başkaları tarafından edlin ya da vi'de sürdürüleceğini farzedin. Israrcı ve acımasız yorum kuralları kaynak kodunuzu ait olduğu yere gömecektir.

Monty Python Yorumları

makeSnafucated isimli bir metot JavaDoc'a yalnızca /* make snafucated */ yorumunu ekler. snafucated kelimesinin ne anlama geldiğini asla hiçbir yerde açıklamayın. Çünkü yalnızca bir zavallı snafucated kelimesinin ne olduğunu bilemez. Bu tekniğin klasik örnekleri için Sun AWT JavaDOC'a bakın.

Program Tasarımı

Sürdürülemez kod yazmanın ana kuralları, bir durumu olabildiğince fazla yerde ve olabildiğince fazla yolla ifade etmektir.
- Roedy Green

Sürdürülebilir kod yazmanın ilk anahtarı, uygulama hakkındaki tüm gerçekleri yalnızca tek bir yere yazmaktır. Böylece eğer fikrinizi değiştirirseniz yalnızca değişiklikleri burada yapar ve programınızın hala eskisi gibi çalıştığından emin olabilirsiniz. Bu nedenle sürdürülemez kod yazmanın anahtarı, kod hakkındaki gerçekleri defalarca olabildiği yer yerde ve değişik varyasyonlar halinde yazmaktır. Ne kadar şanslıyız ki, Java gibi diller bu tarz sürdürülemez kod yazmamız için ellerinden geleni yapıyorlar. Örneğin sıkça kullanılan bir değişkenin tipini değiştirmek neredeyse imkansız, çünkü tüm dönüştürme fonksiyonları işlevsiz hale gelecektir ve geçiçi değişkenlerle ilişkilendirilmiş tipler artık kullanılamaz olacaktır. Aynı zamanda, eğer bir değişken ekrana bastırılıyorsa, onunla ilişkili tüm veri girişleri ve görüntüler manuel olarak düzenlenmiş olmalıdır. C ve Java gibi Algol ailelerinden gelen dillerde verileri dizilere, Hash tablolarına düz dosyaya ya da veritabanına yerleştirmek tamamiyle farklı sözdizimleri gerektirir. Abundance ve Smalltalk gibi dillerde sözdizimi aynıdır, yalnızca tanımlama değişir. Java'nın beceriksizliğini bir avantaja dönüştürebilirsiniz. RAM için çok büyük geleceğinizi düşündüğünüz bir veriyi diziye yerleştirin. Böylece bakım programcınız daha sonra diziyi dosyaya çevirmek için müthiş bir çaba harcamak zorunda kalsın. Aynı şekilde veritabanına da küçük alanlar yerleştirin ki, sıra performans ayarlarına geldiğinde bunları diziye çevirirken nirvanaya ulaşsınlar.

Java Cast'leri

Java'nın casting şeması tanrının insanlara armağanıdır. Dil buna ihtiyaç duyduğu için, hiç çekinmeden bunları kullanabilirsiniz. Bir koleksiyondan bir nesneye eriştiğiniz her zaman, bunu tekrar orijinal tipine fırlatmanız gerekir. Ancak bu tip binlerce yerde belirtilmiş olabilir. Eğer tip değişirse bu cast'lerin da değiştirilmesi gerekir. Derleyici zavallı bakım programcısının tüm tipleri yakalayıp yakalayamadığını anlamayabilir. Benzer şekilde (int)'e dönüştürülmesi gereken tüm (short)'lar, eğer veri tipi short'tan int'e döndürülürse, (int)'e döndürülmek zorundadır. Değişkenin tipi değiştiği zaman hiçbir sürdürmeye gerek kalmamasını sağlayacak jenerik bir cast operatörü (cast) ve jenerik bir dönüştürme operatörü (convert) yaratmak için bir eğilim vardır. Bir çok cast'in sonunu getirecek bu sapkınlığa dur demek için RFE 114691'a "hayır" oyu verin.

Java'nın Fazlalıklarını İstismar Edin

Java, her değişkenin tipini iki kere belirtmenizde ısrarcıdır. Bu yüzden Java programcıları bu fazla belirtimlere alışıktır ve iki tipi çaktırmadan farklı yaptığınızda hiçbirşey fark etmeyecektirler. Aşağıdaki örneğe bakalım:
Bubblegum b = new Bubblegom();
Ne yazık ki ++ operatörünün popülaritesi aşağıdaki gibi göz yanılmalarını yutturmayı zorlaştırır:
swimmer = swimner + 1;

Asla Onaylamayın

Asla bir giriş verisini herhangi bir doğrulama ya da tutarsızlık kontrolünden geçirmeyin. Böylece şirkete olan güveninizi ispatlamış ve kendinizi tüm proje partnerlerinize ve sistem operatörlerine güvenen mükemmel bir takım oyuncusu olarak göstermiş olursunuz. Giriş verileri hatalı ya da muallakta olsa bile, her zaman makul sonuçlar döndürmeye özen gösterin.

Kibar Olun, İddia Etmeyin

assert() mekanizmasını kullanmaktan kaçının, çünkü üç günlük bir hata ayıklama festivalini on dakikaya indirebilir!

Kapsüllemeden Kaçının

Efektiflik için, kapsüllemeden kaçının. Bir metodun çağırıcıları, metodların içeride nasıl çalıştıklarını hatırlamak için tüm harici ipuçlara ihtiyaç duyarlar.

Klonla & Düzenle

Efektiflik adına, kes/yapıştır/klonla/düzenle yöntemini takip edin. Bu yöntem küçük yeniden kullanılabilir modüllerden çok daha hızlıdır. Bu özellikle gelişmenizi kaç satır kod yazdığınızı hesaplayarak ölçmeye çalışanlar için kullanışlıdır.

Statik Diziler Kullanın

Eğer bir kütüphanedeki bir modül, bir görsel tutacak bir diziye ihtiyaç duyuyorsa, hemen statik bir dizi tanımlayın. Hiçkimse 512 x 512'den daha büyük bir görsele sahip olmayacaktır, böylece boyutu sabitlenmiş bir dizi sorun çıkarmaz. En iyi etki için, diziyi double yapmanız önerilir. Böylece 2 megabaytlık statik bir diziyi saklamaya çalışmak istemcinin makinasında bellek taşımına sebep olacak ve rutininizi hiç kullanmasa bile deliye döndürecektir.

Sahte Arayüzler

"WrittenByMe"'ye benzer isimlendirilmiş, boş bir arayüz yazın ve tüm sınıflarınızın bu boş arayüzü gerçekleştirdiğinden emin olun. Daha sonra, kullandığınız her Java'nın gömülü sınıfı için sarma paket sınıfları yazın. Bu eylemin arkasında yatan fikir, programınızdaki her nesnenin bu arayüzü kullandığından emin olmaktır. Son olarak, tüm metodları argümanları ve geri dönüş değerlerinin tipleri WrittenByMe olacak şekilde yazın. Artık metodların ne yaptıklarını ve casting gereksinimlerini tespit etmeyi imkansız hale getirmiş oldunuz. Bu numaranın daha da genişletilmiş hali için, her takım üyesinin kendi kişisel arayüzü (örn., WrittenByJoe) olmasını sağlayın; her programcının çalıştığı sınıf, kendi ismiyle anılan arayüzü kullanmış olsun. Artık keyfi olarak anlamsız arayüzleri kullanan nesnelere referans edebilirsiniz!

Dev Yakalayıcılar

Her bileşen için ayrı yakalayıcılar yaratmayın. Bir proje için basitçe tek bir yakalayıcı bulundurun ve hangi düğmeye basıldığını anlamak için if...else ifadelerini kullanın.

Kabul Edilemeyecek Derecede Çok ^TM

Kapsülleme ve nesneye yönelimle daha da vahşileşin. Örneğin:
myPanel.add( getMyButton() );
private JButton getMyButton()
{
return myButton;
}
Bu pek de eğlenceli gözükmeyebilir. Telaşlanmayın. Nasıl olsa bir gün başınıza gelecek.

Arkadaşça Arkadaş

C++'da friend tanımlamasını olabildiğince fazla kullanmaya çalışın. Arayüzler hakkında tasaya düşmemek için yaratılmış sınıflara işaret eden göstericileri de kullanın. Ayrıca sınıflarınızın iyi korunduğunu ispat etmek için private ve protected anahtar kelimelerini bolca kullanmaya özen gösterin.

Üç Boyutlu Diziler Kullanın

Olabildiğince üç boyutlu diziler kullanmaya çalışın. Verileri dizilerde diziA'dan aldığınız satırları diziB'deki sütunlara geçirme gibi anlaşılmaz yollarla taşıyın. Bunları yaparken herhangi bir sebep olmadan 1 ofsetini kullanmak da, programcıyı asabileştiren güzel bir noktadır.

Karıştır ve Eşleştir

Erişgeç metotları ve genel değişkenleri bir arada kullanın. Bu yolla nesnenin değerini erişgeç kullanmadan değiştirebilir ve sınıfın hala "Java Bean" olduğunu iddia edebilirsiniz. Böylece bakım programcısı, değeri kimin değiştirdiğini anlamak için bir loglama fonksiyonu yazmak zorunda kalır.

Sarmala, sarmala, sarmala

Kendinizin yazmadığı bir kodda, metod kullanmak zorunda kalırsanız kendi kodunuzu en azından bir seviye sarmalayıcı ile ayırın. Böylece, günün birinde diğer programcı tüm metodları yeniden adlandırır ve ne olur dersiniz? Java'nın temel eksikliklerinden biri, hiçbirşey yapmayan ama sadece aynı ya da benzer isimli bir metod çağıran sarmalayacılar olmaksızın bir çok basit sorunu çözümsüz bırakmasıdır. Bu da hiçbirşey yapmayan ve kimsenin dikkatini bile çekmeyecek en azından dört seviyeli sarmalayıcılar yazmanın mümkün olduğu anlamına gelir. Kafa karıştırıcılığı daha da arttırmak için her seviyede metodları yeniden adlandırın ve eşsiz kelime hazinenizden rastgele isimler seçin. Bu, arkaplanda birşeyler oluyormuş izlenimi uyandırır.

Wrap Wrap Wrap..!

Tüm API fonksiyonlarının, her biri ayrı kaynak dosyalarında olmak üzere en az 6-8 kere sarmalandığından emin olun.

Sır Yok!

Tüm metodlarınızı ve değişkenlerinizi public olarak tanımlayın. Ne de olsa herhangi biri, günün birince onları kullanmak isteyebilir. Bir metot public olarak tanımlandığında nasılsa artık geri dönüşü yoktur, değil mi? Eğer patron kafanızın ayık olup olmadığını sorarsa, ona klasik şeffaf arayüz prensiplerini takip ettiğinizi söyleyin.

Kama Sutra

Bu teknik sadece bakım programcılarını değil, tüm kullanıcıları ve belgeleyicileri de oyalamak için birebirdir. Aynı metodun aşırı yüklenmiş binlerce değişik versiyonunu yaratın ve sadece son dakika detayını değiştirin. Sanırım 47.ci ile 115.ci Kama Sutra pozisyonlarının 115.cideki kadının parmaklarının birbirine geçmesi haricinde tamamen aynı olduğunu söyleyen Oscar Wilde'dı. Bu metod ile paketi kullanan programcıları, yüzlerce metod listesi içinden hangi versiyonu kullanacakları konusunda derin düşüncelere sevk etmiş olursunuz. Ayrıca belgelendirmeyi de şişirmiş ve bir süre sonra muhtemelen geçerliliğini yitirmiş hale getireceksiniz. Eğer patronununuz niçin böyle yaptığınızı sorarsa, ona yalnızca kullanıcıların konforunu düşündüğünüzü söyleyin. Ve yine, tam etki için tüm genel mantığı klonlayıp arkanıza yaslanın, ve programın nasıl patladığını zevkle seyredin.

Sırasını değiştir ve Engel Ol

drawRectangle(height, width) gibi bir metodun parametrelerini drawRectangle(width, height) olacak şekilde değiştirin. Bir kaç sürüm sonra, bu parametreleri eski haline getirin. Bakım programcıları şüphesiz tek bir bakışta, fonksiyonun o sürümde hangi parametreleri aldığını bilecektirler!

Temalar ve Değişimler

Basit bir metoda parametre vermek yerine, yaratabildiğiniz kadar metot yaratın. Örneğin alignment isimli parametre left, right ve center değerlerini alabilen bir belirlenmiş değişken tipi olmak üzere setAlignment(int alignment) fonksiyonu yerine setLeftAlignment, setRightAlignment, ve setCenterAlignment gibi üç değişik metot yaratın. Tabii ki tam etki için genel mantığı da klonlamalısınız.

Statik İyidir

Değişkenlerinizi olabildiğince statik tanımlamaya çalışın. Eğer programda sınıfın birden fazla örneğine ihtiyacınız yoksa, diğerlerinin de yoktur. Tanımlayabildğiniz kadar statik değişken tanımlayın. Eğer programda bir sınıfın birden fazla örneğine ihtiyacınız yoksa, başkalarının da olmayacaktır. Ve yine, eğer diğer programcılar yakınmaya başlarsa, onlara elde ettiğiniz performans değerlerini gösterin.

Cargill Açmazı

Cargill Açmazının avantajını yanınıza alın; herhangi bir tasarım problemmi ek bir kapalılık katmanı eklenerek çözülebilir. OO programları, hangi metodun program durumunu güncellediğini bulmayı imkansız kılacak şekilde yeniden düzenleyin.

Eskileri Atmayın

Tüm kullanılmayan ve geçerliliğini kaybetmiş tüm metodları ve değişkenleri kodunuzda bulundurmaya özen gösterin. Eğer bir tanesini 1976'da kullandıysanız, bir daha aynısını kullanmaya ihtiyacınız olmayacağını kim söyleyebilir? Şüphesiz programlama o zamandan bu zamana çok değişti, ama eski metodlar kolayca yeni haline dönüştürülebilir, " tekerleği yeniden keşfetmek istemeyiz, değil mi?")(denetmenler böyle konuşmayı çok sever). Eğer bu metodların ya da değişkenlerin yanında, tercihen kriptografik bir takım yorumlar da bıraktıysanız, bakım programcıları dahil herkesi bunlara göz atmaktan dahi uzak tutmuş olacaksınız.

Ve.. Final!

Tüm yaprak sınıflarınızı final yapın. Ne de olsa, artık proje ile işinz bitti -şüphesiz kimse sınıflarınızı genişletmek suretiyle işinizi geliştirmek istemeyecek. Üstelik final kullanmamak bir güvenlik açığı! -ne de olsa, java.lang.String bu yüzden final değil mi? Eğer projedeki diğer programcılar itiraz ederse, onlara elde ettiğiniz performans üstünlüğünden bahsedin.

Arayüz Kullanımından Çekinin

Java'da interface kullanımını küçümseyin. Eğer denetmeniniz itiraf ederse, ona Java'nın sizi "kopyala pastala" kodlamaya sürüklediğini ve aynı arayüz için değişik sınıflar kullanmak zorunda bırakıldığınızı söyleyin. Buna ek olarak, Java AWT tasarımcılarının yaptığı gibi, sadece onlardan miras alan sınıfların kullanabilmesi için, tüm işlevsellikleri sıfının içine koyun. Böylece, eğer birisi kodunuzu kullanmak isterse, önce sınıfınızı eklemek zorunda kalacak. Eğer kodunuzu iki değişik sınıfta kullanmaya kalkarsa, heyhat! -bir seferde ikisini birden ekleyemeyecek!

Ortam Değişkenleri

Eğer başka programcıların da kullanacağı bir sınıf yazacaksanız, ortam-kontrolü kodunu (C++'da getenv()/Java'da System.getProperty()) sınıfınızdaki isimsiz statik başlatıcılara koyun ve yapılandırıcılar yerine sınıfınıza tüm parametreleri bu şekilde geçin. Böylece daha main() çalışmadan, tüm bu başlatıcı metodların çağrılmasını sağlayın. Diğer bir dille, sıfınızda kullanılmadan önce bu parametreleri herhangi bir şekilde düzenleme şansınız kalmasın.

Tablo Güdümlü Mantık

Tablo-güdümlü mantığın her türlü formunu küçümseyin. Başlangıçta masumca başlasa da, sonrasında kullanıcıları tabloları düzenlemeye kadar götüren bir dizi olaya sebep olur.

Annenin Alanlarını Değiştirin

Java'da parametre olarak geçilen tüm primitifler, aslında değer olarak geçildiği için yalnızca-okunabilir moddadır. Çağrılan parametreleri tekrar düzenleyebilir ama çağıranın değişkenleri üzerinde hiçbir etkisi yoktur. Buna karşın, tüm enseneler okunur-yazılır olarak geçilirler. Referans değer olarak geçilir, yani nesnenin kendisi efektif olarak referans olarak geçilmiş olur. Çağrılan, sizin nesnenizde istediği alanla oynayabilir. Geçilen parametrelerin alanlarını değiştiren metodları asla belgelemeyin. Metodlarınızı, sadece değişkenleri değiştirecekleri zaman alanlara bakıyormuş izlenimi verecek şekilde isimlendirin.

Global Değişkenlerin Sihri

Hata yakalama mekanizmalarını kullanmak yerine, kendi global hata mesajınızı tutun. Sonra da sistemdeki her uzun süreli döngü için bu global bayrağını kontrol edip hata döndürüp döndürmediğine bakın. Ayrıca 'reset' düğmesine basıldığında sinyal üretecek başka bir global değişken tanımlayın. Tabii ki sistemdeki tüm büyük döngülerin bu ikinci bayrağı kontrol ettiğinden emin olun. İsteğe göre sonlanmayacak bir iki döngüyü de gizlediğiniz zaman, üzerinize düşen görevi layıkı ile yapmış olacaksınız.

Globaller, Bu Kadar Stres Yapamayız!

Eğer Tanrı global değişkenler kullanmamızı istemeseydi, onları yaratmazdı. Tanrı'yı hayal kırıklığına uğratacağımıza, kullanabildiğiniz kadar global değişken kullanmaya özen gösterin. Her fonksiyon ve set, herhangi bir sebep olmaksızın en azından iki global kullanmalıdır. En sonunda, gerçekten iyi bir bakım programcısı bunun bir hafiyelik egzersizi olduğunu anlar ve kendisini amatörlerden ayıran bu egzersiz için müteşekkir kalır.

Globaller, Bir Kez Daha

Global değişkenler, sizi fonksiyonlar içerisinde argümanlar tanımlamaktan kurtarır. Bunun bütün avantajlarını kullanabilirsiniz. Bu global değişkenlerden bir kaçını eleyerek ne gibi reaksiyonlar elde edebileceğinize bakın. Bir de zavallı bakım programcıları C fonksiyonlarının yan etkisi olmadığını iddia ederler!

Yan Etkiler

C'de fonksiyonların yan etkisiz olmaları beklenir. Umarım bu ipucu yeterli olmuştur.

Döneklik Edin

Bir döngü yapısının içinde, döngü koşulunun başarılı olduğunu ve tüm işaretçi değişkenlerini güncellediğini farzedin. Döngü içerisinde bu aşamadan sonra yakalanan herhangi bir istisna işaretçi ilerlemesine bir yan etkide bulunacaktır ve döngünün çalışmasını etkileyecektir.

Yerel Değişkenler

Asla yerel değişkenler kullanmayın. Eğer gerçekten bunu yapmak zorundaysanız, o zaman değişkeninizi cömertçe sınıfın diğer metodlarının da kullanımına açmak yerine, bir örneğe bağlamalı ya da statik bir sabit yapmalısınız. Böylece aynı tanımlamalara ihtiyaç duyan diğer metodlar için ek iş yapmamış olursunuz. C++ programcıları biraz daha ileri giderek hepsini global yapabilirler.

Çevir, Yeniden Kullan, Yeniden Çevrime Sok

Eğer geriçağrımlar için veri tutacak bir yapı tanımlayacaksanız, her zaman PRIVDATA yapısını çağırın. Her modül kendi PRIVDATA'larını tanımlayabilir. Örneğin VC++'da, eğer bir PRIVDATA değişkeniniz varsa ve bu değişkeni pencerenizde kullanmak istiyorsanız, bu durumun hata ayıklayıcıyı şaşırtmak ve hangi PRIVDATA'yı kullanacağını bilemediği için rastgele bir tanesini seçmek gibi avantajları vardır.

Yapılandırma Dosyaları

Bunlar genellikle keyword=value formunda olurlar. Bu değerler Java değişkenlerine yükleme zamanında yerleştirilirler. Bulanıklık yaratmanın en kolay yolu Java değişkenleri ve anahtarlar için çaktırmadan farklı isimler kullanmaktır. Çalıştırma zamanı asla değişmeyen sabitler için yapılandırma dosyaları kullanın. Böylece basit bir değişkenin yapabileceği iş için parametre dosyasına kod içinde en az beş kere ihtiyaç duyulsun.

Şişirilmiş Sınıflar

Sınıflarınızı olabildiğince geniş açıyla tasarlamaya çalışın. Örneğin astrofiziksel yörünge geometrisi için bir sınıf yazıyorsanız, okyanus genişliği hesaplamaları ve Crane hava modelini kapsayan bir metodunuz olmasına dikkat edin. Bu sayede yalnızca sınıfı aşırı-tanımlamış olmuyorsunuz, genel sistem kodunda bu metodları bulmayı kumda gitar penası aramayla aynı kademeye sokmuş oluyorsunuz.

Altsınıf Çılgınlığı

Nesneye yönelik programlama, sürdürülemez kod yazmak için tanrıdan gelen bir armağandır. Eğer içinde 10 özellik (üye/metod) bulunan bir sınıfınız varsa, bir özellik eklemek için sadece bir sınıf ve altında 9 seviyeli bir altsınıf olduğunu farz edin. Son çocuğu da alırsanız, 10 özelliğin hepsini edinmiş olacaksınız. Eğer mümkünse her sınıf tanımlamasını ayrı bir değişkene koyun. Böylece INCLUDE ya da USES ifadelerini şişirmiş olacak ve bakım programcısının düzenleyici ekranında gereğinden fazla dosya açmasına neden olacaksınız. Son olarak, her altsınıfın en az bir örneğini yarattığınızdan emin olun.

Kod Bulanıklığı

Sedulously eschew obfuscatory hyperverbosity and prolixity.

C Şaşırtmacası

Internetteki kafa karıştıran C yarışmalarını takip edin ve ustaların kurallarına uyun.

Bir APL Gurusu Bulun

Şu dünyada, kodunuz ne kadar kısa ve tuhaf yolla çalışırsa, o kadar saygı görürsünüz.

Düzinelerce Kullanın

Asla iki ya da üç tane kullanmak varken, bir toparlayıcı değişken kullanmayın.

Karmaşıklık Kuralı

Genel işleri yapmak için her zaman en karmaşık yolu seçin. Örneğin bir sayıyı, dizgeye çevirmek için dizileri kullanacağınıza, aşağıdaki kodu kullanın:
char *p;
switch (n)
{
case 1:
    p = "one";
    if (0)
case 2:
    p = "two";
    if (0)
case 3:
    p = "three";
    printf("%s", p);
    break;
}

Tutarlılık Küçük Beyinlerin Kabusudur

Eğer bir karakter sabitine ihtiyacınız varsa, ' ', 32, 0x20 ve 040 gibi değerler kullanın. Java'da ya da C'de 10 ile 010'un aynı sayı olmadığı gerçeğini fırsat olarak kullanmaya çalışın.

Casting

Tüm verileri void * olarak geçin ve yapılar yerine bayt ofsetleri kullanarak cast yapın. Çok eğleneceksiniz!

İçiçe Geçmiş Switch Yapıları

(bir switch içinde switch) insan beynini çözmek için yapılan en zor içiçe geçmiş yapı girişimlerinden biridir.

Sağ gösterip sol vurun!

Asla bir resim değişkeni (COBOL'da ya da PL/I'de) ya da genel iletişim rutini (C'deki sprintf gibi) kullanmayın. Dizilerde indeks olarak kayan noktalı sayılar, döngü sayaçları olarak karakterler ve sayılar üzerinde sayılarla işlem yapan fonksiyonlar kullandığınızdan emin olun. Tabii tüm bu işlemler iyi tanımlanmış olup, kısa bir özeti sadece kaynak kodunuzda yer almalıdır. Bunları anlamaya çalışan bir bakım programcısı, tüm veri tipi dönüşümlerini ve kod bloğunun tamamını incelemek zorunda kaldığı için size minnettar kalacaktır.

Raw ints

ComboBox'lar kullanırken mümkün olan değerler için sabitler kullanmak yerine, durumları kontrol etmek için sayı değişkenleri kullanın.

Noktalı Virgüller!

Sözdiziminde izin verilen her yerde noktalı virgül kullanın. Aşağıdaki örneğe bakalım:
if(a);
else;
{
int d;
d = c;
}
;

Sekizlik Sistem Kullanın

Sekizlik sayıları aşağıdaki gibi kullanmaya çalışın:
array = new int []
{
111,
120,
013,
121,
};

Dolaylı Yoldan Dönüştürün

Java size dönüşüm yaparken kafa karışıklığı yaratmanız için büyük bir fırsat sunuyor. Basit bir örnekte olduğu gibi, eğer bir double tipli değişkeni bir String'e dönüştürmek isterseniz, direkt Double.toString(d) yazmak yerine dolaylı yoldan gidip new Double(d).toString() yazmalısınız.

İçiçe Geçmiş Yapılar

Olabildiğince içiçe geçmiş yapılar oluşturmaya çalışın. İyi programcılar tek bir satırda 10 seviye ( ) ve tek bir metodda 20 { } yapısıyla başa çıkabilirler. Kod listesinde bir blokun başlangıcını ve sonunu ayrı sayfalarda çıkartmayı başarabilirseniz ekstra Brownie puanı kazanacaksınız!

Nümerik Literaller

Eğer içinde 100 eleman olan bir diziye sahipseniz, literal 100'ü programın olabildiğince fazla yerinde kullanmaya çalışın. 100 sayısı için asla statik isimlendirilmiş bir sabit kullanmayın ya da myArray.length olarak tanımlamayın. Bu sabiti daha da zor anlaşılır hale getirmek için 50 yerine 100/2, 99 yerine 100-1 kullanın. Daha sonra bu 100 rakamını a == 101 yerine a > 100 ya da a > 99 yerine a >= 100 yazarak kontrol edin.

C'nin Ekzantirik Dizi Gösterimi

C derleyicileri myArray[i] gibi bir ifadeyi *(myArray + i)'a çevirir, bu da aslında i[myArray]'ye karşılık gelmektedir. Uzmanlar bunu şüphesiz insanlık yararına yapmışlardır. Eğer bazı şeyleri gerçekten saklamak istiyorsanız, aşağıdaki fonksiyonu benzer bir indeksle yaratın:

int myfunc(int q, int p) { return p%q; }
...
myfunc(6291, 8)[Array];

Ne yazık ki, bu teknikler yalnızca C sınıfları için geçerlidir, Java için değil.

U z u n   S a t ı r l a r

Tek bir satıra, olabildiğince çok şey sığdırın. Böylece yeni satır ve beyaz boşluk karakterlerini eleyerek kaynak kodunun daha kısa olmasını sağlayacaksınız.

İstisnalar

Şimdi sizle pek bilinmeyen bir kodlama sırrını paylaşacağım. İstisnalar aslında tam bir ızdıraptır. Doğru düzgün yazılmış bir kod, asla patlamaz. Bu yüzden istisnalar da gereksizdir, üzerlerinde vakit bile harcamayın. İstisnaları alt sınıflara ayırmak, yazdığı koda güvenemeyenlerin işidir. Bu yüzden programınızı gönül rahatlığı ile herhangi bir sorun çıkarsa System.exit()'i çağıran, tek bir try/catch bloğuna emanet edebilirsiniz.

İstisnaları Ne Zaman Kullanmalı?

İstisnaları istisnasız durumlarda kullanın. Döngüleri ArrayIndexOutOfBoundsException istisnası ile kontrol edin.

Hata Kurtarma Kodunu Gizleyin

Hata kurtarma kodunu gizlemek için içiçe geçmişi yapıları kullanın. Aşağıda 10 ya da 12 seviyeli bir yapı bulunuyor:
if ( function_A() == OK )
{
if ( function_B() == OK )
{
/* Normal completion stuff */
}
else
{
/* some error recovery for Function_B *
}
}
else
{
/* some error recovery for Function_A */
}

Test Etmek

Programlarımı test etmeye ihtiyacım yok. Hata-düzeltici bir modeme sahibim.
- Om I. Baud

Programda hata bırakmak, bakım programcısına ilgilenecek birşeyler sunmak için iyidir. İyi bir hata, ne zaman ya da nerede ortaya çıktığına dair en ufak bir ipucu bırakmamalıdır. Bunu başarabilmenin en tembelce yolu, basitçe kodunuzu hiç test etmemektir.

Asla Test Etmeyin

Kodunuzu hata durumlarına, makina bozukluklarına ya da işletim sisteminin performans düşüklüklerinde asla test etmeyin. İşletim sisteminden dönen kodları asla kontrol etmeyin. Bu kodlar asla çalıştırılmaz ve test zamanlarınızı uzatır. Ayrıca, kodunuzu disk hatalarına, işletim sistemi çökmelerine ve buna benzer şeylere karşı test etmeniz nasıl mümkün olabilir? Modern donanımlar asla bozulmaz, bu yüzden kim sadece test yapmak için kod yazmak ister ki? Hiç de eğlenceli değil. Eğer kullanıcılar yakınıyorsa, suçu işletim sistemi ya da donanıma atın. Gerçeği asla bilmeyecektirler.

Asla Ama Asla Performans Testleri Yapmayın

Hey, eğer kodunuz yeterince hızlı çalışmıyorsa, müşteriye daha hızlı bir makina almasını söyleyin. Eğer performans testi yaparsanız, muhtemelen bir darboğaz bulacak ve bu yüzden algoritma değişikliklerinden, ürünün yeniden dizayn edilmesine kadar uzanan çetrefilli bir yolla karşılaşacaksınız. Bunu kim ister? Ayrıca, müşterinin sitesine peydah olan performans problemleri egzotik bir yerlerde bedava haftasonu gezisi demek! Sadece olduğunuz gibi ilerleyin ve pasaportunuzu el altında bulundurun.

Asla Test Durumları Yazmayın

Asla belirli yollara göre kodunuza performans testi uygulamayın. Otomatikleştirilmiş testler hileciler içindir. Tüm rutinlerinizin %90'unu kapsayan özellikleri tespit edin ve testlerin %90'ını bu yollar için ayırın. Böylece bu teknik ile kaynak kodunuzun muhtemelen yalnızca %60'ını test etmiş ve kendinizi diğer %40 için efor sarfetmekten kurtarmış olursunuz.Bu da size projenizin arkaplanını hesaplamakta yardımcı olur. En büyük ve en ünlü yazılım firmaları kodlarını bu yolla test ederler, o yüzden siz de aynı şekilde davranmalısınız. Eğer herhangi bir sebeple halen buradaysanız, bir sonraki adıma geçin.

Test Ödlekler İçindir

Cesur bir kodçu bu adımı görmezden gelir. Bir çok programcı patronundan, işini kaybetmekten, müşteriden gelen nefret postalarından ve dava edilmekten korkar. Bu korku çalışmayı paralize eder ve üretimi kısırlaştırır. Araştırmalar test aşamasını elemenin, süreci planlamayı kolaylaştırdığını göstermiştir. Korku yok edildiğinde, yeni fikirler ve tecrübe hızla yeşermektedir. Programcının rolü yalnızca kod yazmaktır, hata temizleme yardım masasının ve bakım programcılarının işidir.

Eğer kodlama yeteneğimize tamamen güveniyorsanız, o halde test etmek gereksizdir. Eğer bu mantıkla bakarsak, bir zavallı bile testin problem çözmeye değil, insanlar arasındaki güveni yıkmaya yönelik olduğunu farkeder. Güven konusu dışında, daha efektif bir yol da test olayını tamamen elemek ve tüm programcıları özgüven kurslarına yollamaktır. Eğer programcılara test yaptırmayı tercih edersek o zaamn her program değişiminde bunu tekrarlamak zorunda kalırız, oysa programcıları bir defa özgüven kursuna yolladığımızda problemi kökten halletmiş oluruz. Maaliyetten tasarrufumuz inanılmazdır.

Yalnızca Hata Ayıklama Modunda Çalıştığından Emin Olun

TESTING'i 1 olarak tanımladıysanız
#define TESTING 1
bu size aşağıdaki gibi ayrı kod alanlarına sahip olmak gibi harika bir fırsat yaratır
#if TESTING==1
#endif
ve aşağıdaki gibi elzem eğlencelikler sunar
x = rt_val;
böylece eğer biri TESTING'i 0 yaparsa, program çalışmayacaktır. Bu yaratıcı küçük çalışmamızla, yalnızca mantığın sınırlarını zorlamış olmadık, aynı zamanda derleyiciyi de şaşkına döndürmeyi başardık.

Dil Seçimi

Philosophy is a battle against the bewitchment of our intelligence by means of language.
- Ludwig Wittgenstein

Bilgisayar dilleri gitgide daha zavallılaşmaya başladılar. Görkemli sanatsal dilleri kullanmak hiç de erkekçe değil. Bu yüzden kodlayabildiğiniz en eski dili kullanmak için ısrarcı olun, eğer becerebiliyorsanız sekizlik makina dilini kullanın ve şu makina dilini, şu FORTRAN'ı ya da COBOL'u, şu C'yi ve BASIC'ı ve C++'ı hayal kırıklığına uğratın.

FØRTRAN

Tüm kodlarınızı FORTRAN'dan yazın. Eğer patronunuz sebebini sorarsa, ona FORTRAN'da vakit kaybını önleyecek birçok yararlı kütüphane olduğunu söyleyin. Neyse ki, FORTRAN'da sürdürülebilir kod yazma şansı sıfır olduğundan sürdürülemez kod yazma kılavuzunu takip etmek daha kolay olacak.

Ada Kullanmayın

İncelediğimiz tekniklerin %20'sini Ada'da uygulayamazsınız. Ada kullanmayı reddedin. Eğer yöneticiniz ısrar ederse, artık kimsenin artık bu dili kullanmadığını ve bir çok araç ile uyumsuz olduğunu not düşün.

ASM Kullanın

Tüm genel özellikli fonksiyonlarınızı asm'ye çevirin.

QBASIC Kullanın

Tüm önemli kütüphane fonksiyonlarını QBASIC'e bırakın ve büyük-orta hafıza modelleme haritası için bir asm çeviricileri yazın.

Satıriçi Makina Dili

Sadece eğlence olsun diye, kodunuza bir iki bir makina dili serpiştirin. Nasıl olsa artık kimse makina dilinden anlamıyor. Yalnızca bir kaç satırı bile, bakım programcısının kanını dondurmaya yetecektir.

MASM call C

Eğer C tarafından çağrılan makina dili modüllerine sahipseniz, bir de makina dilinden C'yi çağırmayı deneyin. Aynı zamanda olabildiğince goto, bcc ya da makina dilinin diğer büyüleyici kafa karıştırma metodlarından kullandığınıza emin olun.

İyileştirme Araçlarından Kaçının Avoid Maintainability Tools

Abundance metodunda kodlamadan ya da herhangi bir prensibini kullanmaktan kaçının. Bu metod, bakım programcılarının işini kolaylaştırmaya çalışan bir grup serseri tarafından tasarlanmıştır. Benzer şekilde Eiffel ya da Ada gibi, program ürünleşmeden hataları yakalamak için tasarlanmış dillerden de kaçının.

Diğerleri İle Anlaşmak

Cehennem, diğer insanlardır.
- Jean-Paul Sartre, Çıkış Yok, 1934

Yukarıda, sürdürülemez kod yazmanın altın kurallarını anlatırken, kodu mahvetmenize engel olmaya çalışan patronunuzla nasıl baş edeceğinize ya da insanları kodun nasıl formatlanacağı konusunda nasıl gaza getireceğinize dair ipuçlarına değindik. Şimdi bu ipuçlarını daha da genişletelim.

En İyisini Patronunuz Bilir

Eğer patronunuz 20 yıllık FORTRAN deneyiminin, çağdaş programlama konusunda mükemmel bir kılavuz olacağını düşünüyorsa, hiç düşünmeden onun önerilerini uygulayın. Sonuç olarak, patronunuz size güvenecektir. Bu da şüphesiz kariyerinizdeki basamakları bir kaç adım daha hızlı tırmanmanıza yarayacaktır. Ayrıca program kodunu nasıl karmaşıklaştırabileceğinize dair bir iki yeni metod kapmış olursunuz.

Yardım Masasını Altüst Edin

Kodun hatalarla dolu olmasını sağlamanın diğer bir yolu da, bakım programcılarının bu hatalardan haberdar olmamasıdır. Bu gerçekleştirmenin yolu da yardım masasını sabote etmekten geçer. Asla telefonlara cevap vermeyin. "Yardım hattını aradığınız için teşekkürler. Gerçek bir insana ulaşmak için "1"'e basın ya da bip sesini duyduktan sonra mesaj bırakın." diyen otomatik bir ses kullanabilirsiniz. Aynı şekilde e-postadan gelen yardım istekleri de görmezden gelinmelidir. Bu iş için standart cevap "Hesabınız kilitlendi. Bu durum ile ilgilenecek görevli şu an ulaşılabilir değil." mesajını göndermektir.

Çenenizi Kapalı Tutun

Sonraki Y2K için hiçbir zaman tetikte olmayın. Eğer belirlenmiş bir teslim tarihinde bitirilecek bir ürün için, patlayacak bir nokta keşfettiğiniz zaman sakın kimseye söylemeyin. Asla arkadaşlarınızla, iş arkadaşlarınızla ya da tanıdığınız diğer insanlarla paylaşmayın. Hiçbir koşul altında ipucu olabilecek herhangi bir bilgiyi sızdırmayın, gerekirse iletişimleriniz şifreli yapın.

Baffle 'Em With Bullshit

Kurnazlık harika birşeydir, ama bazen bir tokmak diğer araçlardan daha kurnaz olabilir. Bu yüzden bazen FooFactory gibi sınıflar yaratıp, GoF yaratıcı şablonlarına (sahte UML dizayn belgelerine giden http linkleri ile daha ideal olur) referans vererek yanıltıcı yorumlar yazabilirsiniz. Bakım programcısının hayal gücünün sınırlarıyla dilediğiniz kadar oynamakta özgürsünüz. Daha da kurnazcası, Foo f = Foo.newInstance() gibi korumalı yapıcılar yaratarak yeni örnekler döndürüp yan etkilerini seyredebilirsiniz.

Ayın Kitabı Klübü

Ayın bilgisayar kitabı klüplerinden birine katılın. Özellikle kod örneklerini yazmak için hiç vakti olmayan meşgul yazarları seçin. Yerel kitapçıları gezin ve içinde fazlaca bulut diyagramı olan ve kod örneğinden yoksun kitapları seçin. Bu kitapları bir kaç mektepli lafı öğrenmek için karıştırın, şüphesiz kodunuz bundan etkilenecektir. Eğer insanlar kullandığınız kelimeleri anlamakta güçlük çekerlerse, sizi mutlaka çok akıllı ve algoritmaları çok karmaşık biri olarak göreceklerdir. Algoritma açıklamalarınızda gösterişsiz benzeşimlerden kaçınmaya özen gösterin.

Kendi Kafanıza Göre Hareket Edin

Her zaman sistem seviyesinde kod yazmak istemiştiniz. İşte bu sizin şansınız. Tüm standart kütüphaneleri göz ardı edin ve kendinizinkini yazın. Özgeçmişinizde harika gözükecektir.

Kendi BNF'nizi Yazın

Komut sözdiziminizi her zaman kendinize ait, belgelendirilmemiş, eşsiz BNF gösteriminiz ile yapın. Asla hangi komutların geçerli ya da geçersiz olduğuna dair açıklamalı bir belge yayınlamayın. Asla bir terminal sembolü ile normal bir sembolü ayırdetmek için tipyüzleri, renklendirme, büyük harf gibi görsel ayraçlar kullanmayın. Ne de olsa, sizin yarattığınız BNF'yi anlamayan dangalakların kodunuzla da işi olamaz.

Kendi Bellek Dağıtıcınızı Yaratın

Herkes sizin dinamik belleğinizin karmaşık ve zaman alıcı olduğunu bilir. Her sınıfın bellek kaçağı yapıp yapmadığını kontrol etmek yerine, kendi bellek dağıtıcınızı tasarlayın. Sadece büyük bir arenadan malloc yapması yeterlidir. Belleği boşaltmak yerine, kullanıcıların periyodik olarak heap'i temizlemek için sistemi yeniden başlatmasını sağlayacak bir sistem geliştirin.

Alışılmamış Dillerin Numaraları

Basic'de programlama yapmak beyin hasarına yol açar.
- Edsger Wybe Dijkstra

SQL Takma Adları

Tablo isimlerine bir ya da iki harften oluşan takma adlar verin. Daha da iyisi, tablolarınıza işle alakası olmayan, varolan tablo isimlerinden birini de verebilirsiniz.

SQL Dış Join

Dış join sözdiziminin eşsiz lezzetlerini birleştirerek herkesin nefesini kesin.

JavaScript Faaliyet Alanı

Bir fonksiyonun kendisini çağıranın faaliyet alanındaki tüm yerel değişkenlere erişebilmesi gerçeğini avantaja çevirerek kodu "optimize edin".

Visual Basic Tanımlamaları

Aşağıdaki ifade yerine:
dim Count_num as string
dim Color_var as string
dim counter as integer
bunu kullanın:
Dim Count_num$, Color_var$, counter%

Visual Basic Çılgınlığı

Bir metin dosyasından okuma yapıyorsanız, dizgeye gömmek için ihtiyacınız olandan 15 karakter fazla okuyun.
ReadChars = .ReadChars (29,0)
ReadChar = trim(left(mid(ReadChar,len(ReadChar)-15,len(ReadChar)-5),7))
If ReadChars = "alongsentancewithoutanyspaces"
Mid,14,24 = "withoutanys"
and left,5 = "without"

Delphi/Pascal İçin

Fonksiyon ve prosedürleri kullanmayın. label/goto ifadeleri kullanın ve bakım programcılarını kod içinde ordan oraya atlatmanın zevkini çıkarın. Deli olacaklar!

Perl

Çok uzun satırların sonunda if ve unless'li takipler kullanın.

Lisp

LISP, sürdürülemez kod yazma meraklılarının hayallerindeki dildir. Sadece aşağıdaki parçalara bir göz atın:
(lambda (*<8-]= *<8-[= ) (or *<8-]= *<8-[= ))

(defun :-] (<) (= < 2))

(defun !(!)(if(and(funcall(lambda(!)(if(and '(< 0)(< ! 2))1 nil))(1+ !))
(not(null '(lambda(!)(if(< 1 !)t nil)))))1(* !(!(1- !)))))

• Visual Foxpro

Bu seferki Visual Foxpro'ya özel. Bir değişkene değer atamadıkça tanımsız haldedir ve herhangi bir şekilde kullanılamaz. Bu yüzden bir değişkenin tipini kontrol ettiğinizde aşağıdaki gibi bir sonuçla karşılaşırsınız:
lcx = TYPE('somevariable')
lcx'in değeri 'U' ya da tanımsız olacaktır. Peki ya değerini mantıksal FALSE yapan bir faaliyet alanında iş görürsek?
LOCAL lcx
lcx = TYPE('somevariable')
Şimdi lcx'in değeri 'L' ya da mantıksal oldu. Daha sonraki değeri de FALSE olarak tanımlandı. Bunun sürdürülemez kod yazma sanatında ne gibi bir gücü olduğunun farkında mısınız!
LOCAL lc_one, lc_two, lc_three... , lc_n

IF lc_one
DO some_incredibly_complex_operation_that_will_neverbe_executed WITH
make_sure_to_pass_parameters
ENDIF

IF lc_two
DO some_incredibly_complex_operation_that_will_neverbe_executed WITH
make_sure_to_pass_parameters
ENDIF

PROCEDURE some_incredibly_complex_oper....
* put tons of code here that will never be executed
* why not cut and paste your main procedure!
ENDIF

Çeşitli Teknikler

Eğer birine bir program verirseniz, onu sadece o gün için hayal kırıklığına uğratırsınız; eğer nasıl programlama yapılacağını öğretirseniz, ömür boyu hayal kırıklığına sahip olmasını sağlarsınız.
- Anonim

• Yeniden Derlemeyin

Öncelikle şimdiye kadarki en şeytanca teknik ile başlayalım: çalıştırılabilir bir programın kodunu derleyin. Eğer çalışırsa, kaynak kodunda, her modülde bir iki küçük değişiklik yapın. Ama bunu yeniden derlemekle sakın vakit kaybetmeyin. Bunu daha sonra vaktiniz olduğunda ya da hata ayıklama zamanında yaparsınız. Yıllar sonra talihsiz bakım programcınız bir değişiklik yaptığında ve kodun artık çalışmaz hale geldiğiniz gördüğünde, bu hatanın o an değiştirilen birşeye ait olduğunu sanıp paniğe kapılacaktır. Bu durum kafadan onun bir kaç haftasını yiyeceği için, şimdiden keyiflenebilirsiniz.

• S.I., Amerikan Ölçülerine Karşı

Mühendislik işinde iki tür kodlama yolu vardır. Birinci yolu tüm girdileri S.I. (metrik) ölçüm birimlerine göre yapmak, sonra da hesaplamalar için milli ölçüm birimlerini kullanmaktır. Diğer yol ise çeşitli ölçü birimlerini karıştırıp kullanmaktır. İkinci yolu seçmek her zaman daha etkilidir. Hey, Amerikan yolu bu!

• SVABG

Sabit Ve Asla Bitmeyen Geliştirme. Kodunuzu sık geliştirin ve kullanıcılarınızı sık sık güncelleme yapmaları için zorlayın -ne de olsa, hiçkimse tarihi geçmiş bir versiyonu kullanmak istemez. Hiçkimseye versiyonlar arasında ne gibi farklılıklar olduğunu söylemeyin, zaten eski versiyonda farkedilmeyen hatalar kimin umrunda!

• Hakkında Kutusu

Hakkında Kutusu yalnızca programın ismini, kodçuların adını ve telif haklarını bildiren ibareyi içermelidir. Aynı zamanda eğlenceli bir animasyonlu görsel içerirse daha etkili olur. Buna rağmen, bu kutu asla programın ne işe yaradığını, versiyon numarası ya da en yeni kod revizyonunun tarihini, güncellemelerin elde edilebileceği web adresini ya da yazarın e-posta adresini içermemelidir. Bu yolla tüm kullanıcılar değişik versiyonlar üzerinde çalışacak ve N+1'inci versiyonu yüklemeden önce N+2.ci versiyonu yüklemeye çalışacaktır.

• De De De Değişiklikler!

Versiyonlarınızı gün be gün daha iyi yapmanın yolu, kullanıcılarınızı yıldan yıla hep aynı, eski arayüz ile sıkmamaktan geçer. Tabii bunu yaparken kullanıcılarınıza değişiklikleri çaktırmamaya dikkat etmelisiniz.

• C Prototiplerini Ayrı Dosyalara Yerleştirin

C prototiplerini genel başlık dosyaları yerine ayrı ayrı dosyalara yerleştirin. Bu sayede herhangi bir veri tipini değiştirmek için tüm dosyalarda değişiklik yapmanız gerekir ve derleyici ya da bağlayıcı herhangi bir değişiklikte tip uyuşmazlığı tespit eder. Bu özellikle 32 -> 64 bit platform göçlerinde etkili olur.

• Yeteneğe İhtiyacınız Yok

Sürdürülemez kod yazmak için fazla yeteneğe ihtiyacınız yok. Sadece işe balıklama dalın ve kodlamaya başlayın. Çoğunun sonradan silineceğini bilseniz bile, kalite testlerinin kod satırlarını da hesaba kattığını unutmayın ve ona göre davranın.

• Standardları Kullanın (!)

Projede kullandığınız dil ve ortamın ve binlerce geliştiricinin kullandığı kod standartlarına karşı gelin. Örneğin MFC tabanlı bir uygulamada STL stilinde kodlama standartına uymakta ısrar edin.

• Alışıldık True/False Geleneğini Tersine Çevirin

Alışıldık true ve false tanımlarını tersine çevirin. Çok aşikar gözükebilir, ama oldukça işe yarar bir metodtur. Aşağıdaki tanımları:
#define TRUE 0
#define FALSE 1
kodun kuytu yerlerine saklayarak, koda göz atanların bu numarayı fark etmemelerini sağlarsınız. Artık aşağıdakine benzer karşılaştırmalar yapabilirsiniz:
if ( var == TRUE )
if ( var != FALSE )
someone is bound to "correct" the apparent redundancy, and use var elsewhere in the usual way:
if ( var )
Diğer işe yarayan bir yöntem de TRUE ve FALSE'ı aynı değer yapmaktır.

• Üçüncü Parti Kütüphaneler

Projenize güçlü üçüncü parti kütüphaneler ekleyin, ama bunları asla kullanmayın. Yeterince pratik yaparsanız iyi araçları tamamen görmezden gelebilir ve özgeçmişinizde "Diğer Araçlar" kısmına yazabileceğiniz yeterli sayıda işlevsiz araç biriktirebilirsiniz.

• Kütüphanelerden Uzak Durun

Geliştirme aracınızla beraber direkt eklenen kütüphanelerin hepsini görmezden gelin. Eğer Visual C++'da çalışıyorsanız MFC ya da STL'nin varlığını umursamayın ve tüm karakter dizgelerini ve dizileri elinizle girin; böylece yalnızca işaretçilerin yeteneklerini sınamakla kalmazsınız, aynı zamanda kod için yapılacak herhangi bir geliştirme girişiminin de önüne geçmiş olursunuz.

• Bir Kurulum Sırası Yaratın

Hiçbir bakım programcısının düzeltmelerini derleyemeyeceğini akıllarına iyice sokun. SmartJ denen make betikleri ile uğraşan aracın demode olduğu sırrını bir kenarda saklayın. Aynı şekilde, javac derleyicisinin sınıf olarak da mevcut olduğu bilgisini kimseyle paylaşmayın. Ölüm döşeğinde bile, dosyaları bulmak ve direkt sun.tools.javac.Main derleyici sınıfını çalıştıran küçük bir java programı yazmanın ne kadar kolay olduğunu ağzınızdan kaçırmayın.

• Make ile Daha Fazla Eğlence

Have the makefile-generated-batch-file copy source files from multiple directories with undocumented overrwrite rules. This permits code branching without the need for any fancy source code control system, and stops your successors ever finding out which version of DoUsefulWork() is the one they should edit.

• Kodlama Standartlarını Biriktirin

Kare Kutu Önerileri gibi, sürdürülebilir kod yazmaya dair bulabildiğiniz tüm ipuçlarını ve belgeleri biriktirin, sonra da bu standartları güzelce ihlal edin.

• Ben Değil, IDE!

Tüm kodlarınızı makefile'a koyun, böylece herkes başlık dosyaları yaratan, sonra uygulamayı kuran bir yığın dosyası üreten bir makefile'ı nasıl yaratabildiğinize hayran kalsın. Tabii, sonra bu uygulamayı hiçbir modern IDE'ye göç edemeyeceğiniz için, kullanabileceğiniz en iyi araç, NMAKE gibi bağımlılıklar hakkında uyarı vermekten bile aciz demode bir make aracı olsun.

• Şirketin Kodlama Standartlarını Esgeçmek

Bazı şirketlerin nümerik literallerle ilgili katı kuralları vardır; isimlendirilmiş sabitler kullanmak zorundasınızdır. Örneğin akıllı bir C++ programcısı şöyle yapar:
#define K_ONE 1
#define K_TWO 2
#define K_THOUSAND 999

• Hata Düzeltmelerini Yükseltmelerle Birleştirin

Asla "yalnızca bug-fix" bir sürüm yayınlamayın. Hata düzeltmelerini veritabanı format değişiklikleri, karmaşık kullanıcı arayüzü değişiklikleri ve yönetici arayüzlerinin tamamen yeniden yazılması gibi işlerle birleştirin. Bu yolla, bu hatalarla yaşamaya artık alışmış ve onları özellik olarak görmeye başlamış insanların üst sürüme geçmesini zorlaştırırsınız.

• Ürünün Her Sürümünde Dosya Tiplerini Değiştirin

Müşterileriniz sürümler arasındaki uyumluluğa bayılacaktır, devam edin! Ama geriye dönük uyumluluk olmadığından da emin olun!

• Hataların Bedeli Ödeyin

Koddaki hataların kaynağını bulma hakkında endişelenmeyin. Basitçe kodu daha yüksek seviyedeki rutinlere yerleştirin. Bu teknik, özellikle çoklu-geçiş derleyiciler için işe yarar.

• Mevzun Bozulma

Eğer sisteminiz bir NT aygıt sürücüsü içeriyorsa, uygulamaya malloc G/Ç tamponlarını katın ve herhangi bir iş parçacığı işlem görürken onları bellekte kilitleyin. Sonra da serbest bırakın/kilidi açın. Böylece eğer bir tampon kilitliyse NT'yi çökertecek bir uygulamaya sahip oldunuz. Ama istemci tarafındaki hiçkimse aygıt sürücüsünü değiştiremeyeceği için, görevinizi başarıyla yerine getirmiş oluyorsunuz.

• Özel Betikleme Dili

Çalışma zamanında byte-derlenen bir betikleme komut dilini istemci/sunucu uygulamalarınıza dahil edin.

• Derleyici Bağımlı Kod

Eğer derleyicinizde ya da yorumlayıcınızda bir hata tespit ederseniz, kodunuzu buna göre yeniden düzenleyin. Ne de olsa, ne siz ne de bir başkası farklı bir derleyici kullanmayacak!

• Gerçek Hayattan Bir Örnek

Aşağıda bir usta tarafından yazılmış bir örnek var. Şimdi hepberaber, bu basit C fonksiyonuna gömdüğü değişik teknikleri inceleyelim.
void* Realocate(void*buf, int os, int ns)
{
void*temp;
temp = malloc(os);
memcpy((void*)temp, (void*)buf, os);
free(buf);
buf = malloc(ns);
memset(buf, 0, ns);
memcpy((void*)buf, (void*)temp, ns);
return buf;
}
• Standart kütüphanelerin parçasın olan fonksiyonları yeniden yaratın.
• Realocate kelimesi doğru yazılmamış. Yaratıcı imla düzenlerini asla göz ardı etmeyin.
• Hiçbir geçerli sebep olmaksızın giriş tamponunun geçiçi bir kopyasını oluşturun.
• Hiçbir sebep yokken önünüze gelen herşeyi cast edin. memcpy(), (void*)'i alıyor, bu yüzden işaretçilerimizi zaten (void*) oldukları halde cast edin.
• Geçiçiyi boşaltmaktan asla çekinmeyin. Böylece daha yavaş bir bellek sızmasına neden olur ve programınızı günlerce çalışmadan göstermemiş olursunuz.
• Tampon bellekten ihtiyacınızdan fazlasını kopyalayın. Bu sadece Unix'te çekirdek bir mezbelelik oluşturur, Windows'da değil.
• os ve ns'nin "old size" ve "new size" kelimelerini ifade ettiği de açıktır.

• Kullanılmayan Değişken Hatalarını Nasıl Düzeltirsiniz?

Eğer derleyiciniz "kullanılmamış yerel değişken" uyarıları veriyorsa, sakın bu değişkenlerden kurtulmayı denemeyin. Onun yerine, onları kullanmanın daha zekice bir yolunu bulun. Benim en sevdiğim...
i = i;

• İşlevi Değil, Boyutu Önemli!

Bir fonksiyon ne kadar büyükse, o kadar iyidir; ne kadar jump ve GOTO komutları varsa daha da iyidir. Bu yolla, tek bir değişim bir çok senaryoya göre analiz edilmelidir. Bakım programcısı büyük ihtimalle spagetti kod içinde kafayı yiyecektir ve eğer fonksiyon cidden kocamansa, bakım programcılarına Godzilla gibi gelecektir.

• Bir Resim 1000 Kelime; Bir Fonksiyon 1000 Satırdır

Her metodu olabildiğince uzun yazın -neyse ki siz asla herhangi bir metodu ya da fonksiyonu bin satırdan aşağı yazmazsınız.

• Bir Kayıp Dosya

Bir ya da bir kaç kritik dosyanın kayıp olduğundan emin olun. Bu iş en iyi include'ların include'ları ile yapılabilir. Örneğin ana modülünüzde aşağıdaki şekilde include kullanıyorsunuz:
#include <stdcode.h>
Stdcode.h kullanılabilir durumda. Ama stdcode.h içinde aşağıdakine bir referans bulunmuyor
#include "a:\\refcode.h"
ve refcode.h hiçbir yerde kayıtlı değil.

• Heryere yazın, Hiçbir Yeri Okumayın

En azından bir değişken heryerde tanımlanır ve neredeyse hiçbir yerde kullanılmaz. Ne yazık ki, modern derleyiciler bunun aksini yapmanızı engeller, heryeri okuyun, hiçbir yere yazmayın --ama bunları hala C ya da C++'da yapabilirsiniz.

Philosophy

Sistem sınıflarını ve derleyicileri yazanlar, dilleri tasarlayanlarla aynı insanlardır. Şüphesiz ki işlerini kolaylaştıran ve matematiksel olarak şık tasarımlar yapmaya özen göstermektedirler. Buna rağmen her derleyici yazarına karşılık gelen 10.000 tane bakım programcısı bulunmaktadır. Bakım programcılarının dillerin tasarımına dair söyleyecekleri tek bir söz yoktur. Ancak uğraştıkları kodların yekünü derleyicileri gölgede bırakmaktadır.

Bu sonucun bir örneği JDBC arayüzüdür. Bu arayüz hayatı JDBC için kolaylaştırırken, bir bakım programcısı için kabusa dönüşür.

Bakım programcıları, herhangi birinden danışmanlık talebi aldığında, gereksiz ayrıntıları esgeçip ağaçlar için tüm ormanı görebilmek isterler. Örneğin çok fazla vakit kaybetmemek için tüm kısayolları talep etmek ve tek bir ekranda programa dair daha fazla detay görebilmek tercih edilen bir yoldur.

Konu dışı detayları göz ardı edip, asıl konuya odaklanmanızı sağlama konusunda sarfedilmiş NetRexx, Bali gibi bazı çabalar ve görsel düzenleyiciler mevcuttur.

Ayakkabıcının Ayakkabısı Yok

Ana hesap defterini bir kelime işlemci kullanarak tutmakta ısrar eden bir muhasabeciyi müşteri olarak kabul edelim. Muhtemelen en iyi yolun müşterinizi bu verilerin yapılandırılması gerektiğine ikna etmek olduğunu düşüneceksiniz. Verilerinin çapraz alan kontrolleri ile onaylanması gerektiğinden, verilerin bir veritabanına kaydedildikten sonra işlem yapmak daha kolay olacaktır.

Şimdi de bir yazılım geliştiricisini müşteri olarak ele alalım. Bu müşterinin tüm verilerini (kaynak kodunu) bir metin düzenleyicisi ile yazmakta ısrar ettiğini düşünelim. Metin işleyicinin renk, tip boyutu ya da font özelliklerinden istifade etmediğini farzedelim.

Şimdi kaynak kodunu yapılandırılmış veri olarak tutmaya başladığımızı varsayalım. Aynı kodu pek çok değişik yolla görüntüleyebiliriz, örn. Java'daki gibi, NextRex'deki gibi, bir karar tablosu olarak, bir akış şeması olarak, bir döngü yapısı iskeleti olarak, gereksiz detayların ve yorumların temizlendiği Java'daki gibi ya da değişkenlerin ya da metot çağrımlarının renklendirildiği Java gibi.. Karmaşık aritmetik ifadeleri TeX ve matematikçilerin yaptığı gibi 2 boyutlu olarak ifade edebiliriz. Kodu ek ya da daha az parantezle görebilir ya da parantez kümelerini değişik boyutlarda ve renklerde görüntüleyebilirsiniz.

Modern ekranların sunduğu renklendirme özelliklerini, biliçaltısal ipuçları yakalamak için kullanabilirsiniz. Örneğin her paket/sınıf için renk skalasından belli bir renk verebilir ve referanslar ya da metodlar için pastel gölgeler kullanabilirsiniz. Herhangi bir tanımlayıcı bildirimi için kalın fontlar kullanabilirsiniz.

X tipinin bir nesnesini hangi metodun/yapılandırıcının üreteceğini sorabilirsiniz. Ne tür metodlar X tipine ait bir nesneyi parametre olarak kabul edebilir? Bir metod çağrımında ya da değişken referansında, tanımlamalara ya da verilen metodun hangi versiyonunun çağırılacağına bakarak durumu kavrayabilirsiniz. Verilen metod ya da değişken için tüm referansları ziyaret edebilir ve hangisiyle uğraştığını işaret edebilirsiniz.

Bu önerilerden bazıları işe yaramayabilir. Ama hangilerinin işe yaradığını anlamak için en iyi yol hepsini teker teker denemektir. Temel bir aracınız olduktan sonra, bakım programcılarının hayatını kolaylaştırabilecek yüzlerce yeni fikir üretme ve deneyim etme hakkına sahipsiniz.

Bu konudan SCID öğrenci projesinde de bahsedeceğim.

Bu makalenin eski bir sürümü Java Geliştirici Gazetesi'nde de yayımlandı (Yıl 2 Sayı 6). Aynı zamanda 1997 Kasım'ında Colarado Summit Konferansı'nda bu konu hakkında bir konuşma yaptım. Şüphesiz o zamandan bu zamana, sürdürülemez kod yazma tekniklerimi epey geliştirdim.

Bu makale şakaydı! Bu makaleyi ciddiye alanlar varsa gerçekten özür dilerim. Kanadalılar, şakaları bir :) ile etiketlemenin çok beceriksizce olduğunu düşünüyorlar. Ben özellikle __sürdürülebilir kod nasıl yazılır dediğim halde, insanlar dikkat etmemekte ısrar ettiler. Buna rağmen zamanla, ne kadar saçma şeyler yazarsam insanların o kadar çabuk kabullendiğini gözlemledim. Bu yüzden sürdürülemez kod yazma tasarım modellerini incelemek, daha makul bir yoldu.





---

[Çevirmenin Notu #1]: İspanyol Engizisyonu (The Spanish Inquisition), Monty Python'da da bu konuyla ilgili ilginç bir skeç yer almaktadır.

[Çevirmenin Notu #2]: Esperanto , Klingon ve Hobbitese dilleri en yaygın yapay diller olarak bilinir. Bu dillerin kendilerine ait kısıtlı sayıda (örn: Esperanto'nun yaklaşık 16 adet) kuralları bulunur ve genel yapıları İngilizce'yi andırır.



• Bu makalenin orijinal hali İngilizce'dir ve Roedy Green'ın Mindproducts sitesinde bulunmaktadır.
• Çeviri en son Eylül 2007'de güncellenmiştir. Belgenin en güncel hali için Roedy'nin sayfasını ziyaret edin.
• Bu belgenin tüm hakları Roedy Green'e saklıdır ve Roedy Green'in izni ile çevrilmiştir. Orijinalinin ya da çevirisinin izin almadan yayınlanması yasaktır.