Obsessif Kompulsif Bozukluk ya da Takıntılı kişilik. Olayın adını ne koyarsak koyalım şu an bu yazıyı okuyan programcı olan birçok kişide varolan bir bozukluk var. Bu bozukluk yolda yürürken neden kaldırımların düzgün bir sırada gitmediğine dair sinirlerini bozmakla ve sürekli söylenmekle benzer bir bozukluk. Ya da masasındaki herşeyin aynı hizada durması için büyük bir çaba sarfetmekle benzer bir bozukluk. Bunun adı takıntılı kod yazımı ya da mükemmeliyetçi kod yazım bozukluğu.
Belki çoğunuz nasıl daha iyi kod yazılacağına dair varolan çoğu notationları okumuşsunuzdur. İşte bu dik için ilk harfin büyük olması gerekir, şu dil için fonksiyon isimleri hep küçük harfle yazılmalıdır, fonksiyonlar tanımlandıktan sonra yeni satıra geçilip bir tab içerden başlanmalıdır gibi. Ancak bizim bahsettiğimiz şey bu yönergelerin bahsettiği yeni satır ve tab olayının kullanılması değil, yeni satır ve tabın takıntı haline gelmesi.
Mesela şimdi aşağıdaki koda bakalım :
{ *******************************************************
ACTION : FORM CLOSE
******************************************************* }
procedure TManageProducts.FormClose(Sender: TObject;
var Action: TCloseAction);
begin
JvEdit1.Text := '';
JvEdit2.Text := '';
JvEdit3.Text := '';
JvEdit4.Text := '';
Jvcheckbox1.Checked := False;
.....
mySQLQuery1.Close;
....
Mainform.DBGrid1.Refresh;
end;
Bu kodda gördüğünüz gibi hiçbir arıza yok gibi görünüyor. Bu Delphi koduna bakan bir kişi bir bakışta ne işler yaptığını anlayabilir.
Ancak takıntılı bir kişi için bu kod hiç de uygun bir kod değildir. Düzenlemelere başlar. Önce tablarla koda yeni bir şekil verir :
{ *******************************************************
ACTION : FORM CLOSE
******************************************************* }
procedure TManageProducts.FormClose(Sender: TObject;
var Action: TCloseAction);
begin
JvEdit1.Text := '';
JvEdit2.Text := '';
JvEdit3.Text := '';
JvEdit4.Text := '';
Jvcheckbox1.Checked := False;
.....
mySQLQuery1.Close;
....
Mainform.DBGrid1.Refresh;
end;
Sonra prosedürün iki satıra bölünmüş olmasından huzursuzluk hisseder :
{ *******************************************************
ACTION : FORM CLOSE
******************************************************* }
procedure TManageProducts.FormClose(Sender: TObject;var Action: TCloseAction);
begin
JvEdit1.Text := '';
JvEdit2.Text := '';
JvEdit3.Text := '';
JvEdit4.Text := '';
Jvcheckbox1.Checked := False;
.....
mySQLQuery1.Close;
....
Mainform.DBGrid1.Refresh;
end;
Herşey güzel gibi görünmektedir. Ancak bileşen isimlerinin aynı uzunlukta olmamasından dolayı huzurluk duymaya başlar bu sefer :
{ *******************************************************
ACTION : FORM CLOSE
******************************************************* }
procedure TManageProducts.FormClose(Sender: TObject;var Action: TCloseAction);
begin
Edt1.Text := '';
Edt2.Text := '';
Edt3.Text := '';
Edt4.Text := '';
Chk1.Checked := False;
.....
Qry1.Close;
....
Manf.Grd1.Refresh;
end;
Evet bileşen isimleri aynıdır aynı olmasına da farklı propertilerine erişildiği için karakter uzunlukları farklıdır. Daha düzenli olmalıyım :
{ *******************************************************
ACTION : FORM CLOSE
******************************************************* }
procedure TManageProducts.FormClose(Sender: TObject;var Action: TCloseAction);
begin
CleanFormElements([Edt1,Ed2,Edt3,Edt4,Chk1);
CleanAndCloseQuery([Qry1]);
RefreshListProducers;
end;
Allah kahretsin bu sefer de yazdigim alt fonksiyonların isimleri aynı uzunlukta değil :
{ *******************************************************
ACTION : FORM CLOSE
******************************************************* }
procedure TManageProducts.FormClose(Sender: TObject;var Action: TCloseAction);
begin
CleanFormElementsA([Edt1,Ed2,Edt3,Edt4,Chk1);
CleanAndCloseQuery([Qry1]);
RefreshListPrdcers;
end;
Bu böyle devam eder. Kod üzerinden 45. geçişte fonksiyonlar arasındaki mesafelerin üç satır olmasına karar verirsiniz, 97. geçişte bunun 4 satır olmasının daha eşit olacağına karar versiniz, 127. geçişte fonksiyon isimlerinin hepsinin büyük harf olmasının daha simetrik olduğuna karar verisiniz, 47653. geçişte hala yazdığınız üç yüz satır kodu şekillendirmekle uğraştığınız farkeder ve bu işin asla bitmeyeceğini düşünüp vazgeçersiniz. Ama içiniz rahat etmez. Bundan sonra aklınıza geldikçe kod üzerindeki düzenlemeler devam eder. Taa ki koddaki her bir fonksiyon, değişken, sabit bir harfe ya da hex koduna dönüşene ve siz dahil kimse koddan birşey anlamayana kadar…
Yani siz takıntılarınızla mükemmel bir kod yazımı aramak için çabalarken yazdığınız kod zaman içinde gitgide niteliğini kaybederek bir şifreye dönüşür. Öyle bir şifredir ki takıntı anahtarını verseniz bile kodu kimse çözemez.
Aynı uzunlukta fonksiyon isimleri secmemizin, değişkenleri aynı uzunlukta olmasına gayret etmemizin, tablarla ve yeni satırlarla saatlerce kodu tekrar tekrar düzenlememizin tek sebebi programcılarda oldukça sık göründüğünü düşündüğüm mükemmeliyetçi kod yazım hastalığı.
Kendimde bizzat derin olarak gözlemlediğim (ancak diğer arkadaşlarda da varolan etkilerinden haberdar olarak…) deneyimlere göre bu tarz kişilerin teşhisi oldukça basit. Eğer kişi bir işin gerekli 100 satır kodu üç dakika da yazıyor ama otuz üç dakika kodu düzenlemeyle uğraşıyor ve bunla da yetinmeyip sürekli kodun görüntüsüyle uğraşmaya devam ediyorsa bilin ki bu kişi bir mükemmeliyetçi kod yazım takıntısına sahip.
Bu takıntıdan kurtulmak her ne kadar mümkün değilse de işlerinizi engellemesini sağlamak kısmen mümkün. Bu bahsedeceğim tekniği kendi üzerimde denediğimde başarıya ulaştığımı söyleyebilirim. Teknik şöyle :
1. Kod yazarken hatasız kod yazmaya çalışın. Bu koda tekrar tekrar dönmenizi engelleyecek hem de programlama becerinizi geliştirecektir. Kendimden örnek vermem gerekirse şu an için yazdığım her kod ilk yazdığımda neredeyse yüzde yüz bir çalışma oranına sahip. Bu yolun tek kötü yanı yazarken aklınızın daha çok olasılık hesaplaması açısından kodu daha yavaş yazmanız. Gerçi kodu yavaş yazıp tek seferde çalışır hale getirmekle kodu tekrar tekrar revize etmek durumlarından hangisi daha az zaman alır bunu anca en sonda görmek mümkün.
2. Bir kodla işiniz bittimi onu tekrar incelememek. Bir kod bir işi görüyorsa o kodla işinizin bittiğine inanmalısınız daha doğrusu kendinizi inandırmalısınız. Kodun çalıştığını görün ve pencereleri kapatın.
3. Kodlarınızı birden çok dosyaya ayırın. Çünkü takıntılar sizi asla bırakmaz. Ama gerçek şudur ki bir kod penceresindeki 5000 satır kodu düzenlemek bir kod penceresindeki 45 satır kodu düzenlemekten daha zordur. Bir kodu dosyalara böldüğünüzde bir dosya ile çalışmanız “içiniz rahat bir şekilde” sona erdiğinde o dosyaya tekrar tekrar dönüp bakmadığınızı “denekler” üzerinde yaptığımız çalışmalarla ispatlamış bulunmaktayız.
4. Koda ek gerektiğinde adrenalin salgılayın. Yani biraz heyecanlanın. Bu heyacan öyle bir heyacan olsun ki hemen işinizi bitirip kod penceresini kapatmazsanız kötü birşey olacağına yönelik olsun. Bu sadece değişiklik yapacağınız noktaya odaklanmanızı ve işiniz bitince hemen pencereyi kapatabilmenizi sağlayacaktır. ( En azından kimi zaman! )
Bu tür bir takıntı her kod penceresi açtığınızda aklınıza geleceği için en kolay yol kendinize has bazı teknikler geliştirerek olayı bay-pass etmeye çalışmaktır. Çünkü açıkcası bu olay tüm fonksiyonlarıyla kafanızın içinde varolduğu sürece bir projeyi bitirmeniz destek almadan çok da mümkün olmaz. Yani 10.000 satır kod yazacağınız yerde 300 satır kodu habire düzenlemekle takılır kalırsınız.
Demedi demeyin….
{ Okumaya devam et : Programlama Hastalıkları II : Geniş Düşünmek ve Planlama }
Tags: programlama
Entries (RSS)
code guidelines olayına dalmısız, Allah’a şükür gnu stiline yakın bırseyler tutturdum gıdıorum;)
[...] ki mükemmeliyetçi kod yazımları bir hastalıksa geniş düşünmekte çok sık görülen bir programlama [...]
Programlama Hastalıkları I : Mükemmeliyetçi Kod Yazımı…
Obsessif Kompulsif Bozukluk ya da Takıntılı kişilik. Olayın adını ne koyarsak koyalım şu an bu yazıyı okuyan programcı olan birçok kişide varolan bir bozukluk var….
Kod yazımında belli bir notasyon oluşturup onu benimsemek bana çok daha iyi bir yöntemmiş gibi geliyor bana. Bu durumda hiçbirşeyin uzunluğu ya da büyük/küçük harf olması sizi rahatsız etmez çünkü kurallar bunları gerektirir.
XHTML/CSS yazarken id ve class ısımlerını uc harften ıbaret vermek gıbı bır takıntı olustu.. Sonuc.. Kodu artık okuyamıyorum.. Karısıklıgından degıl, dılım donmuyor.. ort, lst, bnr, zck, dtt, frt.. Kodu anlatırken agzımdan kopukler cıkıyor..
Ama yınede.. Tum class ısımlerının aynı dıkey cızgıyı takıp edıyor olmasının verdıgı keyfe dıyecek yok.. Evet.. Sanırım az bıraz manyadık..
Kaan Arslan; dediğiniz gibi kod yazmak için birçok notasyon var ancak burada bahsettiğim notasyona uymaktan daha farklı. Yani belli bir notasyona uysanız bile pey pey o kodu alıp anlaşılmaz hale getiriyorsunuz.
Mesela bir ornegi de Ertuğurul vermiş, CSS’de ve HTML’de kullanılan class isimlerini yazmak konusunda gene böyle bir durum var. Belki ilk etapta class tanımları #leftcolumn, #centercolumn diye başlıyor ancak git zaman gel zaman #lfc, #rgc gibi hallere geliyor.
Bunun aslında biraz da simetri tarzi bir takintinin sonucunu olduğunu da söylemek mümkün sanırım.