Yazılım Geliştirmede Kodlama Stili ve Gösterimin Önemi

0
maat
Bu yazımızda program yazımında kodlama stilinin öneminden bahsedeceğiz. Geliştirilen yazılımlarda bulunması gereken özelliklerden birisi de "okunabilirlik"tir. İyi bir program sadece yazan kişinin baktığında neyin, nerede nasıl yapıldığını ya da değişkenlerin türlerini anlayabildiği program değil, aksine, kullanılan dilin genel kabul görmüş yazım kurallarına uygun olarak hazırlanmış adeta bakıldığında "şiir gibi okunabilen" programdır. Yazımızın bundan sonraki bölümlerinde kullanılan çeşitli stilleri anlatarak ve örneklerle destekleyerek konumuzu daha da açacağız. Ancak konunun genişliği sebebi ile ancak anahtar noktalara değineceğiz. Anlatılanların daha geniş açıklamaları için kaynaklara bakılabilir.
Gösterim Nedir?

İngilizcesi "notation" olan kavramı Türkçemize gösterim, notasyon olarak çevirmek mümkündür. Biz yazımızda gösterim terimini kullanacağız.Gösterim kavramı fonksiyonların, değişkenlerin isimlendirilmesi ve bu isimlendirmenin de mümkün olduğunca doğru ve fazla bilgi vermesi amaçlanarak hazırlanmış önerilerdir diyebiliriz. Bunlara örnek olarak, bir zamanlar Microsoft'ta şef tasarımcı olarak çalışmış (ve Microsoft Press'e ait bir kitapta Microsoft'un efsanevi programcılarından biri olarak nitelendirilen) Charles SIMONYI tarafından önerilmiş olan Macar Gösterimi (Hungarian Notation) gösterilebilir. Microsoft kendi içinde ve özellikle C kodlamasında bu gösterimi kullanmaktadır. Türkçe'ye "Hatasız Kodlama" olarak çevirilen kitapta da Microsoft'a giren programcılara önce Macar Notasyonu'nun öğretildiği belirtilmiştir.

Kodlama Stili Nedir?
Kodlama stili, herhangi bir dil için yazım ve isimlendirme konusunda genel kabul görmüş kurallardır diyebiliriz. Ancak kurallardır demiş olsak da bunların bir zorlama olmadığı, genel kabul görmüş, deneyimler sonucu elde edilmiş olan bilgi olduğu gözden kaçırılmamalıdır. Örneğin http://wwws.sun.com/software/sundev/whitepapers/java-style.pdf adresinde yer alan ve Sun'ın kendi içinde Java dili ile kodlama konusunda kullandığı standartların yer aldığı belgede, bu belgenin oluşturulabilmesi için yazarın yüzbinlerce satır JDK kodu inceleyip bu belgeyi oluşturduğu "Background" kısmında belirtilmiştir. Tabii ki pek çok farklı kodlama stili bulunmaktadır. Linus TORVALDS tarafından hazırlanan "Linux Kernel Coding Style" ve GNU'ya ait "GNU Coding Standards" gibi standartlar bunlara örnek gösterilebilir.

Ayrıca kodlama stilinin tanımından da anlaşılabileceği gibi bu kavram gösterim kavramını da içermektedir. Çünkü genellikle kodlama stiline ilişkin bilgiler isimlendirme gibi bir başlık altında gösterimi de ele almaktadırlar. Örnek olarak, Linux Kernel Kodlama Stili isimli makalede de böyle bir başlık bulunmaktadır.

Kod Örneklerimiz İçin Uyarı
Her ne kadar makalemizi Türkçe yazıyor olsak da özellikle kod örneklerimizde İngilizce isimleri tercih edeceğiz. Amacımız konuyu orjinal kaynaklara sadık kalarak anlatmaktır. Bu durumun mazur görüleceğini umuyoruz. Durumun Türkçe için uygulaması ise tabii ki okuyucularımıza kalıyor.

Hangisi Daha Okunabilir?
Aşağıdaki kodlardan ilki üzerinde pek düşünülmeden, sadece kodun çalışıyor olmasının yeterli olduğu düşünülerek hazırlanmıştır, diğeri ise aynı kodun çok katı biçimde uygulanmasa da Macar Gösterimi ile yazılmış eşleniğidir.

Örnek kodumuz C'nin standart fonksiyonu olan malloc yerine kullanılmak üzere tasarlanmıştır. İstenen bellek miktarını parametre olarak almaktadır ve başarılı biçimde tahsisat yapabilmiş ise geri dönmekte aksi takdirde bir uyarı mesajı yazarak programı sonlandırmaktadır. Ne işe yarayabilir böyle bir fonksiyon diyebilirsiniz. İlk olarak şunu söyleyebiliriz. Kodunuzun birçok yerinde malloc ile işlem yapıyorsanız her malloc satırının sonuna bir "if" yerleştirip işlemin başarılı olup olmadığını kontrol etmek istemeyebilirsiniz. Bu fonksiyonu çağırdığınızda eğer işlem başarılı ise geri döneceği için kodun bir çok yerinde "if" ifadelerine gerek kalmayacaktır.

Kod 1.
void* func(unsigned int s)
{
	void* p;

	p = malloc(sizeof(char) * s);
	if (p == NULL)  {
		printf("Cannot allocate memory!");
		exit(1);
	}
	return p;
}
Kod 2.
void* AllocateMemory(DWORD dwSize) 
{
	void* pvMem;

	pvMem = malloc(sizeof(char) * dwSize);
	if (pvMem == NULL) {
		printf("Cannot allocate memory");
		exit(1);
	}
	return pvMem;
}
Macar Gösterimi'nde değişkenlerin isimlerinin başına türlerini gösteren bir önek getirilmesi, değişken ve fonksiyon isimlerinin yapılan işi anlatacak biçimde seçilmesi için bazı öneriler mevcuttur. Örneğin bir pointer için ismi önüne "p", türü void ise "v" eklenmesi, isminin yaptığı işe uygun seçilmesi önerilmektedir. Örnek kodumuzdaki "pvMem(ory)" isimli değişkene bakıldığı zaman değişkenin bildirildiği/tanımlandığı yere bakmadan türünün void pointer olduğunu anlamak mümkündür. Fonksiyon isimleri konusunda da önce yapılan işe dair bir fiil sonra da yapılan işe ilişkin bir nesne isminin kullanılması tavsiye edilmiştir. Kod örneğimizdeki "AllocateMemory" de bu kurala uymaktadır. Bellek tahsisatı yaptığını anlamamak için özel bir çaba sarfetmek gerekli desek yeridir. Tabii Macar Gösterimi'nin de dezavantajları bulunmaktadır. Bunun en başta geleni örnek koddan da farkedilebileceği gibi isimlerin uzun olma eğiliminde olmalarıdır. O sebeple Windows gibi grafik ortamlarda kullanılmasında sorun olmayabilir ama GNU/Linux üzerinde ve 80x25 komut satırında yazılım geliştirirken isimlerin bir satıra sığmaması gibi durumlarla karşılaşmak olasıdır. O sebeple Linus TORVALDS'a ait "Linux Kernel Coding Style" isimli makaleye bakıldığında kısa isimlerin tercih edilmesi gerektiği biçiminde önerilere de rastlanmaktadır. Hangi kodlama stilini seçeceğiniz size kalmıştır. Ancak üzerinde çalıştığınız sistemde genel kabul görmüş stilleri benimsemek hem siz bu stile alıştığınız için aynı sistem için yazılım geliştiren başkalarının kodlarını kolay anlamanızı sağlayacaktır hem de sizin geliştirdiğiniz yazılımlar diğer geliştiriciler tarafından kolaylıkla anlaşılabilecektir. En başta da dediğimiz gibi okunabilirlik geliştirilen yazılımların kodları açısından önemli bir kriterdir ve iyi bir programcı yazdığı kodu yalnızca kendisi anlayan kişi değildir.

Kodlama stilinin isimlendirme kurallarını içerdiğini daha önce de söylemiştik. Bunun dışında tab kullanımı, açıklama satırlarının yerleştirilmesi gibi başlıklar da yine kodlama stiline dahildir. C programlama dilinin kutsal kitabı diyebileceğimiz ve Türkçemize de çevrilen "The C Programming Language" da C dilinin tasarımcıları tarafından tab için dört karakter uzunluğunda boşluğun uygun olduğu, tablamanın kodlama açısından önemi ve özellikle belli bir kodlama stilinin benimsenip kararlı biçimde uygulanmasının gereği vurgulanmıştır. Örneğin; her satıra bir komut yazılması, iki operand alan operatörler için operandları ile kendileri arasında birer boşluk bırakılması, virgül ve noktalı virgülün solunda boşluk bırakılmaması ancak sağında bir boşluk bırakılması gibi uygulamalar adı geçen kitapta ilk anda göze çarpan ve C programcıları arasında yaygın olan bir stildir. Özellikle "tümleşik geliştirme ortamı" (İngilizcesi ile Integrated Development Environment ya da kısaca IDE) diye bilinen yazılımlar sizin için tablama konusunda destek sunmaktadırlar. Microsoft'un Visual Studio ortamı ya da GNU/Linux üzerinde çalışan KDevelop, Anjuta ya da JBuilder gibi tümleşik geliştirme ortamları bu şekilde bir destek sunmaktadırlar. Artık programcıların tablama konusunda, eğer ellerinde bu tip bir ortam varsa, işi editörlerine havale etmeleri de mümkündür.

Yazılan kodların bir süre sonra kodlayan kişi ya da bir başkası tarafından gözden geçirilmesi esnasında açıklama satırlarının da önemi yadsınamaz. O sebeple yazılan fonksiyonların başında ve içinde uygun yerlere açıklama satırlarının da yerleştirilmesi gelecekte karşılaşılacak (hatırlama, anlama vb.) problemleri en aza indirecektir.

Kısaca...
En başta da dediğimiz gibi geliştiricilerin koda baktıkları zaman ne yapılmak istendiğini kısa sürede anlayabilmeleri yazılım geliştirme açısından önemlidir. Bunun olabilmesi için de uygulanabilecek en kestirme yol kullandığımız dil, çalıştığımız platform gibi etkenleri de göz ününe alarak bir kodlama stili benimsemek ve bu stili kararlı biçimde uygulamaktır. Yazımızda çok kısa biçimde değindiğimiz stiller ve daha başkaları yaygın olarak kullanılmaktadır. Bunlardan birinin seçilmesi ve kararlı biçimde uygulanması ile "şiir gibi okunabilen" program kodları yazılması mümkündür.

Mehmet Ali Aksoy Tüysüz
aksoy at bilgi nokta edu nokta tr

Kaynaklar

Görüşler

0
sametc
Bu fazlamesai.net denen site gitgide bilişim universitesi halini alıyor..... dikkat edin yazan bir akademisyen(yanlış bilmiyorsam)
0
dfix
Esasında bunlar iyi şeyler ama karışık algoritmalar geliştirme sürecinde çok sinir bozucu oluyor ve bir yerden sonra artık kendi tarzınızla yazmaya başlıyorsunuz bu elbette gelişi güzel ve tutarsuz oluyor şahsen kod işlevini ön planda tutuğum için buna pek uymuyorum diğer türlü kodlama işlemi neredeyse iki kat hatta üç kat artıyor ve bu yontem kodlamada esnekliği ortadan kaldırıyor akademik anlamda veya belirli bir aşamaya kadar iyi olabilir ama pratikte tüm süreç boyunca kullanmanızı hiç tavsiye etmem
0
roktas

Esasında bunlar iyi şeyler ama karışık algoritmalar geliştirme sürecinde çok sinir bozucu oluyor ve bir yerden sonra artık kendi tarzınızla yazmaya başlıyorsunuz bu elbette gelişi güzel ve tutarsuz oluyor


Ben burayı anlayamadım, "kendi tarzınız" dediğiniz şey zaten kodlama stili işte. Proje herşeyiyle size aitse tutarlı olarak "kendi tarzınız"da yazarsınız. Zor olan tutarlılığı sağlamak mı, katıldığınız bir projenin kodlama stiline uyma gereği mi? Her ikisinin de bir ölçüde sağlanması zor şartlar olduğunu, kodlamayı yavaşlattığını kabul edebilirim, ama "gereksizliğini" kabul edemem. İlk durum için "tutarlılık" şartını da aşan, aşağıda açmaya çalıştığım hususlar var. Diğeri ise, şayet proje stili beğeninize uymamışsa, en azından "sosyal bir zorunluluk"tur.

Genel kural şu: düzgün yürütülen her eylemde bir parça "ritüel", bir parça "estetik" duygusu hakim olmak zorundadır. Bol müşterisi olan bir dönerci seçip, döner ustasını gözleyin; bıçağı düzenli aralıklarla bileylemesi, döneri kesmesi, ekmeğin içine yerleştirmesi ve paketlemesi vesaire. Peki bu "ritüel" ve "estetik" zorunluluğu nereden gelir? Eminim ki felsefenin "estetik" ve kısmen "ahlâk" şubelerinde bu mevzu hakkında yeryüzünün en cins kafaları görüş serdetmiştir. Kendimce değerlendirdiğimde bulduğum bir cevapta, bahse konu eylemin düzgün yürütülmesi için kişinin kendi öznesine ve yaptığı eyleme "değer vermesi ve özen göstermesi" zorunluluğunu görüyorum. Estetik ve ritüel unsurlar da bu zorunluluğu sağlayan araçlar. Aksi halde o dönerci, ekmek parası için bile olsa, o işi gözlenen şekilde yapamazdı.

Kodlama soyut bir eylem, orada bazı şeyleri somutlaştırmaya ihtiyaç var. Dua ederken (İslâm rütelinde) ellerin aldığı biçim gibi. Fikirlerin, algoritmaların zerafetine, estetiğine inanırım. Ama kodlanmış o fikirlerin (implementasyon: gerçekleme) VIM sentaks renklendirmesiyle aldığı düzgün ve ışıl ışıl görüntü o zerafet kadar önemlidir veya o zerafeti cismanileştirir. Bu hislerden bigane bir ruh haliyle geliştirilmiş bir yazılımda (anlatmaya çalıştığım türde bir şeyin varlığını kabul etmek, ama "tarif edememek" geçerli bir cevaptır) çok eminim ki önemli şeyler eksik kalmıştır :-)
0
dfix
Biraz anlaşılması güç ve garib bir yazı yazdığımı kabul ediyorum. Uykusuzluğumun hat saffada olduğu bir zamanda yazdığım için böyle olmuş kusura bakmayın ama temelde fikirlerimin arkasındayım Şu an yine uykusuzum tekrar saçmalamadan yazıyı bitirsem iyi olur...
0
ahmetaa
Hos bir yazi.
Kod stili onemli bir konu. Ozellikle takim calismasinda farkli kisilerin farkli stil kullanmasi belli bir dereceden sonra kabul edilemez. Neyseki kullnadigimiz java IDE'leri bu konuda buyuk yardimci. kurallari bir defa tanimladiktan sonra ne kadar karisik yazilirsa yazilsin tum kodu sekillendirmek Ctrl+Alt+L (ya da Eclipse icin CTRL+Shift+F ) 'ye basmaktan ibaret :). Ancak gelistiricilerin bir stilde (bosluk, { isaretlerinin yeri vs.) anlasmasi sart. Degisken, sinif, dosya adi gibi kavramlarda ise standart Java kodlama stilini takip etmek en iyisi.
Görüş belirtmek için giriş yapın...

İlgili Yazılar

HTML 5 Yenilikleri ve JavaScript ile Canvas elementini Kullanan Yılan Oyunu

kulker

HTML 5, Web 2.0 teknolojisinin bize sunduğu en büyük nimetlerden biri. Canvas,video ve audio gibi 3 önemli elementle daha gelişmiş web uygulamaları geliştirmek mümkün.

Ne vahimdir ki MSIE desteklemediği için kullanım oranının az olduğunu görüyoruz. Buna rağmen Firefox, Opera ve Google chrome HTML5 i desteklediği için bu güzelim teknolojiyi test edip kullanmaya başlamak fazla zaman kayıp etmemek lazım.

Egzotik Programlama Araçları Yaygınlaşıyor

FZ

TDK sözlüğüne göre "egzotik" kelimesinin anlamı: "Uzak, yabancı ülkelerle ilgili, bu ülkelerden getirilmiş, yabancıl." Bir çoğumuz için yapay sinir ağları, genetik programlama, Common Lisp, PROLOG gibi güçlü teknolojiler "günlük" programlama deneyimlerinin ötesindeki karanlık ve gizemli alanlar, uzak diyarlar. eWeek'e göre ise bu durum hızla değişiyor.

Kiril’den Latin’e Anında Özenli Çeviri

FZ

Takip ettiğim e-posta listelerinden biri olan Yazılım İhracatı listesinde bugün gördüğüm bir e-postayı FM camiası ile paylaşmak istedim...

Hazırlanan bir bilgisayar programı sayesinde artık 20 Türk lehçesindeki Kiril alfabesinde yazılan metinler anında Latin alfabesine çevrilebilecek.

Kırıkkale / AA

2 Ocak 2005 — Kültür ve Turizm Bakanlığı’nın sitesinde hizmete sunulan programı Kırıkkale Üniversitesi’nden Doç. Dr. Mehmet Kara, 3 yıllık bir çaba sonucu hazırladı.

Türk Cumhuriyetleri için önemli bir sorun olan Kiril alfabesinden Latin alfabesine çeviri yapan bir bilgisayar programına ömrünü Türk dünyasının dil birliğine adayan ‘Gaspıralı İsmail’in adı verildi.

20 Türk lehçesinde Kiril alfabesi ile yazılı metinleri otomatik olarak Latin alfabesine çeviren programın yazılımı da Damla BilgisayarA.Ş. tarafından gerçekleştirildi.

Genişletilebilir Programlama Dilleri: 21. yy. İçin Tahminler

FZ

ACM tarafından yayınlanan QUEUE dergisinin son sayısının konusu programlama dilleri. Toronto Üniversitesi'nden Dr. Gregory V. Wilson'ın dergiye gönderdiği Extensible Programming for the 21st Century (21. yüzyıl için genişletilebilir programlama) yazısı Internet'teki değişik platformlarda ışık hızı ile yayıldı ve bitmek bilmez tartışmalara bir yenisi eklendi. FM olarak sonsuz+1 mantalitesine uyup sevgili okurlarımızı bundan haberdar etmemek ve bir başka teknik (sosyolojik, psikolojik, politik, kısaca bilgisayar dünyası ile ilgili) tartışmaya yol açmamak düşünülemezdi!

BinarySearch ve MergeSort kullandıysanız kodunuzu kontrol edin!

FZ

Algoritmalar mükemmel olabilir ama uygulamaları her zaman öyle olmayabiliyor!

Google'dan Joshua Bloch, yeni günlük girdilerinden birinde Extra, Extra - Read All About It: Nearly All Binary Searches and Mergesorts are Broken diye konuya girip Java standart kütüphanesinde kendi yazdığı BinarySearch fonksiyonunun nasıl bir hata barındırdığını anlatıyor.

Sun Microsystems'e 11 Mayıs 2004 yılında gönderilen hata raporunun yorum kısmı ise epey eğlenceli: "Should be fixed in the next release. Not for Tiger. xxxxx@xxxxx 2004-05-11 Finally fixing for Mustang. Can't even compute average of two ints is pretty embarrassing."

3 Haziran 2006 Cumartesi günü yollanan yorumlara göre ise, benzer problemden ötürü Solaris'teki look komutu yaklaşık 1 GB'den büyük dosyalar için düzgün çalışmıyor.