Memik Yanık RSS

15. BÖLÜM : OBJECT SINIFI

Tue, 12 Jan 2010 04:23:18 GMT

14. BÖLÜM : STRUCT ve ENUM TİPİ HAZIRLAMAK(*)

Wed, 09 Dec 2009 23:21:54 GMT

13. BÖLÜM : METOT HAZIRLAMAK

Thu, 03 Dec 2009 19:00:25 GMT

12. BÖLÜM : CLASS'LAR ve NESNEYE YÖNELİK PROGRAMCILIK

Wed, 25 Nov 2009 20:03:42 GMT

11. BÖLÜM : TARİH ve ZAMAN İŞLEMLERİ

Sat, 21 Nov 2009 08:06:03 GMT

DELPHI PRISM – KONSOL UYGULAMALARI

Sun, 15 Nov 2009 10:46:57 GMT

10. BÖLÜM : STRINGBUILDER SINIFI ve DÜZENLİ İFADELER

Sat, 14 Nov 2009 06:56:57 GMT

İsteğe Bağlı Parametreler

Fri, 13 Nov 2009 05:42:52 GMT

C# 4.0 İle Gelen Yenilikler : İsteğe Bağlı Parametreler

Fri, 13 Nov 2009 00:22:29 GMT

Namespace Kütüphane Midir?

Thu, 12 Nov 2009 20:23:28 GMT

Form Üzerinde Keydown

Wed, 11 Nov 2009 23:25:19 GMT

MD5 İle Kodlanmış Bilgiler

Tue, 10 Nov 2009 22:18:12 GMT

9. BÖLÜM : STRING İŞLEMLERİ VE MATH SINIFI(*)

Tue, 10 Nov 2009 18:59:22 GMT

8. BÖLÜM : BLOK KONTROL DEYİMLERİ

Sun, 08 Nov 2009 01:11:13 GMT

7. BÖLÜM : OPERATÖRLER

Fri, 06 Nov 2009 18:40:44 GMT

6. BÖLÜM : DİZİ DEĞİŞKENLER(*)

Wed, 04 Nov 2009 18:57:21 GMT

5. BÖLÜM : DEĞİŞKEN TANIMLAMAK ve KULLANMAK(*)

Sun, 01 Nov 2009 19:19:15 GMT

Arşivden : Windows 2000 Server Kurmak

Sat, 31 Oct 2009 22:10:22 GMT

Bundan tam 12 yıl önceydi, Novell Netware ve Windows NT Server konulu bir kitap yazmıştım. Kitap alanında ilkti. O günün şartlarında kalitesi iyi olmasa bile kurma aşamalarının fotoğraflarını çekmiş ve kitapta kullanmıştım. Okurlardan ilgi gören bu kitap kısa sayılabilinecek bir sürede tükenmişti ki o günlerde Windows 2000 Server piyasaya verilmişti. Ayrıca Novell Netware’nin kullanım alanı daralmıştı. Bunun üzerine kitabı tekrar bastırmak yerine Windows Server 2000 üzerinde çalışmaya başlamıştım. Sonra zamansızlıktan Windows 2000 Server kitabını tamamlayamadım. Geçen günlerde bir web sitesinde Windows 2000 Server’ın kurulmasıyla ilgili bir yazıyı görünce bundan tam 10 yıl önce yazdığım ve Windows 2000 Server’ın nasıl kurulduğunun anlatıldığı bölümü orijinaline bağlı kalarak birkaç küçük yazım değişiklikleriyle size sunmaya karar verdim. Devamı burada..

4. BÖLÜM : NAMESPACE HAZIRLAMAK ve KULLANMAK(*)

Sat, 31 Oct 2009 08:39:14 GMT

3. BÖLÜM : KONSOL UYGULAMALARI

Thu, 29 Oct 2009 20:19:17 GMT

En Kapsamlı ve En Kolay Okunan C# 3.0 Kitabı Bedava...

Thu, 29 Oct 2009 06:51:35 GMT

2008 yılı sonlarında yayınlanan C# 3.0 kitabım hem az basılıp hem de okurlardan ilgi gördüğü için günümüz şartlarına göre kısa sayılabilecek bir sürede tükendi. Geçtiğimiz günlerde bu kitabın üzerinde çalışıp her kaynakta bulunan birkaç konuyu kitaptan çıkarıp ileri düzey bilgiler içeren 40 yeni sayfa eklemiştim. Kitap alacak kadar parası olmayanları ve kitap alacak kadar parası olanları ise yanlışlıklarla dolu ve daha az bilgi içeren kitaplara mahkûm etmemek için sözünü ettiğim kitabı www.memikyanik.net’te bölümler halinde arkası yarın şeklinde sizlere sunmaya başladım. Web'de yer sorunu olmayacağı için küçük eklemeler yapabileceğim. Bu sayede en kapsamlı Türkçe C# 3.0 kitabı olan bu kitap dünyanın en kapsamlı ve ençok ileri düzey bilgi içeren kitap olma yolunda ilerlemiş olacaktır.

Word belgesi olarak düzenlenip öyle basılan kitap metnini www.memikyanik.net’e aktarmak zaman alacağı için günde ortalama 10 sayfayı sizlerle paylaşmayı düşünüyorum. Çalışmalarıma katkı sağlamak isteyenler veya basılı metni tercih edenler bu kitabın birkaç gün sonra piyasaya çıkacak yeni baskısını www.seckin.com.tr‘den temin edebilirler.

Olur ya değişik nedenlerden dolayı C# 3.0 kitabının içeriğini burada sizinle paylaşmayı yarım bırakmak zorunda kalırsam kimse bana kızmasın. Diğer yandan şimdiye kadar web’de yayınladığım çok sayıda makaleyi isteyen arkadaşların alıp kendi sitelerinde bloglarında yayınlamalarına bir şey demedim. Ancak C# 3.0 kitabının bütünlüğü açısından arkadaşların kitabın bölümlerini kendi sitelerinde yayınlamalarını istemiyorum. Çevrenizde saç baş yolmadan eksiksiz bir kaynaktan kısa sürede C# öğrenmesini istedikleriniz var lütfen onlara bundan söz edin, bloglarınızda duyurun. Bu kitapla ilgili olarak soru, öneri ve görüşlerinizi memikyanik@hotmail.com‘a yazabilirsiniz. Çünkü kitaba küçük eklemeler yapmaktayım.

Kitabın ilk bölümü aşağıda verilen linktedir.

http://www.memikyanik.net/1-bolum-visual-studionun-program-gelistirme-ortami-makalesi/118.aspx

www.memikyanik.net'i her gün izleyip C# kitabının yayınlanan sayfalarını okuyup hem kısa sürede C# uzmanı olun hem de kötü kaleme alınmış ve teknik yanlışlarla dolu kitap almak derdinden kurtulun. Eğer C# ve programcılıkta henüz yolun başında iseniz bu kitabı www.memikyanik.net 'ten okumadan önce aşağıda linkini verilen PDF'yi indirip okumanız önerilir.

http://www.memikyanik.com/download/csharp_e_book.rar

Çünkü bu PDF'yi okuyanların C#'ı ve .NET programcılığını öğrenme hızları artmakta ve C# üzerine çalışmak keyifli hale gelmektedir.

2. BÖLÜM : VISUAL C# İLE PROGRAMCILIĞA GİRİŞ(*)

Wed, 28 Oct 2009 22:06:27 GMT

1. BÖLÜM : VISUAL STUDIO'nun PROGRAM GELİŞTİRME ORTAMI(*)

Wed, 28 Oct 2009 19:16:05 GMT

SQL Server 2008 Express Edition’ı Kurmak(*)

Sat, 10 Oct 2009 12:55:48 GMT

Delphi Prism ile Çalışmaya Başlamak

Sat, 10 Oct 2009 08:25:24 GMT

İyi Bilinen Session Hakkında(*)

Fri, 09 Oct 2009 19:35:10 GMT

Programcılar İçin Yazarlık Dersleri - 3

Fri, 09 Oct 2009 11:40:41 GMT

Hata Yakalama ve Exception Sınıfları’nı Nasıl Anlattım?

Bu makalede programcılık üzerine yazanlara, öğrencilere programcılık öğretenlere ve kendi başına programcılık öğrenenlere hitap etmeye çalışılmaktadır. Bu bölüm okunduktan sonra programcılık üzerine yazılan bazı metinlerin neden zor okunduğunu, neden anlaşılmaz olduğunu fark edeceksiniz. Bu derste hem genel konular üzerine konuşacağız hem de C# 3.0 kitabımdan aldığım Hata Yakalamak ve Exception Sınıfları makalesini Yazarlık Dersleri bağlamında ele alacağız, neyi neden nasıl anlattığımın hesabını vereceğim. Başka bir deyişle C# 3.0 kitabım için hazırlayıp sonra kişisel web sitemde konunun meraklılarıyla paylaştığım 30 sayfalık metni bu bölümde ele alacağım. Programcılık üzerine yazanlar bu metni dikkatlice okuduktan sonra dönüp daha önce yazdıklarına burun kıvıracaklarına, ilk fırsatta yazma ve anlatma stillerinde köklü değişikliklere gideceklerine inanabilirsiniz.

Memik Yanık’ın İlk C# Kitabı

Bu derste asıl konumuz Hata Yakalamak ve Exception Sınıfları bağlamında programcılık kitaplarını nasıl kaleme aldığımı anlatmak olduğundan konudan uzaklaşmamak için kendi C# kitaplarıma dönüyorum. 2004 yılında yayınlanan C# kitabım içerik bakımından ortalama bir kitaptı. Yani C# ve .NET programcılığına henüz başlayanları belli bir düzeye çıkarmayı hedefliyordu. Bu hedefin içinde veritabanı uygulamalarını geliştirebilmek, API fonksiyonlarını kullanabilmek, basit web servisi yazabilmek bile vardı. Başka bir deyişle 900 sayfalık kitapta çok sayıda konuya yer yermeye çalışmıştım. Böyle olunca kitaptaki bazı konular ayrıntı içermiyordu. Örneğin yukarıda sözünü ettiğim makalede anlattığım konu, yani hata yakalama konusu topu topu 7 sayfaydı. Tabii ki 900 sayfalık bu kitap bazı okurlar için gerek duymadığı konuları içerirken bazı okurların asıl gerek duydukları konular yoktu veya yeteri ayrıntıda anlatılmamıştı.

Sözünü ettiğim kitapta 7 sayfa boyunca anlattığım Hata Yakalamak adlı bölümde sıfıra bölme hatasından söz etmiştim. Çünkü sıfıra bölme programcılık derslerinin mutlaka anlatılan klasik hatalarından birisidir. Yoksa serileştirme yapılırken karşılaşılan hatalardan söz edecek değildim. Çünkü serileştirme işlemi iyice anlatılmadan serileştirmeyle ilgili hataları veya Application Domain’e assembly yüklerken karşılaşılan hataları yakalayıp anlatmak anlamsız olurdu. Aslında bazılarınız “madem her kitapta sıfıra bölme hatasından söz ediliyor siz de başka hatalardan söz edin” diyebilirler.

Bu uyarıyı yapan arkadaşlara cevabım hazır: Yukarıda sözünü ettiğim ilk C# kitabım yayınlandıktan çok sonra birileri çıkıp “ey memik yanık sen sıfıra bölme hatasını biliyor olamazsın” demesin mi? Yani 1994 yılından bu yana sayısız programcılık kitabına imza atan memik yanık sıfıra bölme hatasından bi haberdir diye düşünenler varken sizler kalkıp bu konu gereksizdir, C#’la ilgilenen herkes zaten sıfıra bölme hatasını biliyordur diyorsunuz. Otoritelerin(!) "Memik Yanık sıfıra bölme hatasını bilemez" görüşünden yola çıkarak C# 3.0 kitabımda hata yakalama konusuna torpil geçip(tabi başka konuların sayfalarından kısarak) şimdiye kadar Türkçe yayınlanmış C# kitapları bağlamında bu kitabımın “Hata Yakalamak” konusunun en kapsamlı anlatıldığı kitap olmasını hedefledim.

Şimdi birileri çıkıp “ey memik yanık hata yakalamak konusunda “en” kapsamlı bölümü yazmış olman yazdıklarını bildiğine delalet olmaz, hata yakalamak konusunda bilgi verirken hazırladığın 3-5 satırlık kodlarda kullandığın değişkenlere veya metotlara ad seçerken başka yerli yazarların kitaplarından “izinsiz” esinlenmediğini nereden bileceğiz” diye soru yöneltirlerse? Tam bu sırada ortaokul 3. sınıfta okurken tarih hocam aklıma geldi. Tarih dersinde pek iyi değildim. Baktım tarihten kalacağım, oturup biraz çalıştım. Son yazılı sınavda soruların hepsine cevap verip çıktım. Ertesi gün hocam beni tahtaya çıkarmıştı ve yazılıda sorduğu soruları bir de tahtada cevaplamamı istemişti. Benzer cevapları tahtada da verince bana tam puan vermişti ve kopya çekmediğime inanmıştı. Şimdi benzer çalışmayı yukarıda sözünü ettiğim Hata Yakalamak ve Exception Sınıfları makalesi için yapacağım. Başka bir deyişle bu makalede veya C# kitabımda yazdıklarımı bildiğimi kanıtlamaya, verdiğim örneklerde kullandığım değişkenlere, metotlara çalıntı yapmadan ad bulabilme becerisine sahip olduğuma, 2 sayıyı bir birine bölen C# kodu yazabildiğime sizleri inandırmaya çalışacağım. Tabii bunu yaparken konuları nasıl anlattığımı, hangi örneği neden verdiğimi vs tek tek anlatacağım.

Hata Yakalamak mı Hata Ayıklamak mı?

Her ne kadar C# 3.0 kitabımda Hata Yakalamak ve Hata Ayıklamak konularını ayrı birer bölüm olarak düzenlemiş olsam bile bu sitede sizlerle paylaştığım makalede hataları ayıklamaktan ve projeleri çalıştırmaktan kısaca söz ettim. Çünkü Visual Studio kullanan bir çok programcı adayı uygulamaların Debug ve Release modlarından çok sonra haberdar olabilmektedir. Entegre hata ayıklayıcısı ile ilgili olarak yapılmış ayarlamalardan Debug veya Release moduna göre Exception sınıflarının verdikleri tepkiler değiştiği için kısaca olsa bile Debug nedir, Release modu nedir sorularına cevap vermeye çalıştım. Bu düşünce ile bölümde bir sayfa boyunca dedikodu yaptıktan sonra “Projeleri Çalıştırmak” adında bir başlığa yer verdim.

Bazılarınız hemen “ey memik yanık bizlere projelerin nasıl çalıştırıldığını anlatmak için mi bu kadar hikâye okuttun?” diye tepki gösterebilirler. Bu soruyu soran arkadaşlara Visual Studio’nun menülerini tek tek dolaşıp Start veya Run adında bir komutun olup olmadığını araştırmalarını önermek isterim. Bir iki dakikalık araştırmadan çıkacak sonuç şu olabilir: Debug menüsünde Start Debugging adında bir komut var ve Standard araç çubuğunda bu komutu temsil eden bir düğme bulunmaktadır.

Hemen sorumuzu soralım: Programcı üzerinde çalıştığı uygulamayı neden çalıştırmak ister? Cevap basittir ve nettir: Uygulamayı test etmek, varsa hataları ayıklamak için. İşte bu ihtiyaçtan yola çıkan Microsoft’un programcıları Visual Studio’nun menü çubuğunda Debug adında bir menüye yer verip bu menüde Start Debugging komutunun olmasına karar vermişlerdir. Makalede Debug ve Release modlarından söz ederken aşağıda verdiğim ekran görüntüsünü kullandım.

Bu ekran görüntüsünü kullanmamın nedeni üzerinde çalışılan uygulama Start Debugging komutu ile çalıştırıldığı zaman geri planda nelerin olduğunu, hazırlanan EXE dosyanın nereye konulduğunu okura göstermektir. Şimdi bazı arkadaşlar bu ekran görüntüsü makale veya kitapta fuzuli yer işgal etmez mi, bu ekran görüntüsünü kitapta kullanmakla kitabı şişirmiş olmuyor musun diye sorabilirler. Elbette bu ekran görüntüsü verilmese bile Visual Studio ile C# uygulaması geliştirmek isteyen kişi bir süre sonra Debug klasörüne konulan EXE dosyayı bir şekilde fark eder. Ancak bu fark etmenin anlamlı olması için aynı zamanda Bin klasörünün altında hazırlanan Release klasöründen de haberdar olması gerekir. Ötesi EXE dosyanın ne zaman Debug klasörüne, ne zaman Release klasörünü yerleştirildiğini bilmesi gerek.

Bu ekran görüntüsünü kullanmanın amacı Visual Studio tarafından hazırlanan EXE dosyanın yerini göstermekten öte okurun konu üzerinde düşünmesini sağlamaktadır. İşini ciddiye alan yazar okurunun kafasından geçmesi muhtemel soruları öngörüp tam zamanında bu soruları cevaplar. Eğer yazar okurunun neyi bilip neyi bilmediği konusunda çok sık yanılırsa kitabı bazı okurlar için anlaşılmaz ve eksik olarak değerlendirilirken bazı okurlar için “bu kitabın düzeyi bana göre değilmiş” yorumu yapılır. Yine konu gelip hedef okur grubunu doğru seçip kitabın içeriğini ve anlatım tarazını ona göre seçmeye dayanıyor.

Daha açık anlatımla Hata Yakalama veya Exception sınıflarını anlattığınız kişinin Release veya Debug modu nedir, Visual Studio’nun Configure Manager diyalog kutusunda neler ayarlanır, bu ayarların etkileri ve işlevleri nelerdir sorularına cevap verebiliyor olması gerekir. Bu konuların anlatıldığı kişi veya okur bu sorulara cevap veremiyorsa Exception sınıfları ilgili olarak anlatılanlardan “hiç bir şey anlamaz” denilemez ama kafasında oluşan bazı sorular cevaplanmamış olur.

Okurun kafasında daha sonra cevaplanmak üzere(belki de hiç cevaplanmayacak) ertelenen soruların sayısı arttıkça yazılan metni okumak zorlaşır. Elbette kitabın ilk sayfasında sözünü ettiğiniz bir kavramı hemen orada anlatın demiyorum ama anlatmayacağınız veya çok sonra anlatacağınız kavramlardan mümkün mertebe söz etmemek gerekir. Örneğin birçok yerli yabancı yazar kitaplarının daha ilk sayfalarında Assembly, Application Domain, Process, Unmanaged Code vs.. daha birçok kavramın adını anarlar, birer cümle ile anlatmaya çalışırlar. Bana sorarsanız C# ve .NET Framework konusunda henüz yolun başında olan(zaten yolun başında olduğu için gidip kitap alıyor) okur için Application Domain veya Assembly’den birer cümle ile söz etmenin hiçbir yararı yoktur. Bırakınız yararı bazı temel kavramların 2-3 cümle ile anlatılması okurun kafasını karıştırıyor. Çünkü Assembly ve Application Domain gibi kavramlar hem ilk öğrenilmesi gereken konular değildir hem de en azından 15-20 sayfa boyunca anlatılması gereken konulardır. Yazar arkadaşlara bu konuda önerim şudur: Kitabınızın veya makalenizin hemen başında 2 cümle ile anlatmaya çalıştığınız kavram mutlaka bilinmeli midir? Bu soruya cevabınız evetse okurun o konuyu anlaması için ne gerekiyorsa hemen orada yapın. Okurun söz konusu kavram veya konuyu hemen öğrenmesi gerekmiyorsa ondan söz etmeyin. Ne zaman ki o konuyu ayrıntılı inceleyeceksiniz o zaman söz edin.

Try-Catch Blokları

Projeleri çalıştırmaktan ve hataları ayıklamadan kısaca söz ettikten sonra sıra geldi kullanıcının çalışma anında yapması muhtemel hataları öngörüp tedbir almaya. Aslında benzer konuyu birçok kaynakta bulmak mümkündür. Zaten anlatılanlara fazla yabancı olmayan okur metni şöyle bir tarayıp verilen kod örneklerine bakar ve 3-5 satırlık kodlar kendisine yabancı değilse metni okumayı bırakır. Bu nedenle programcılıkla ilgili herhangi bir konu anlatılırken okurun o konudan bi haber olduğunu ve bilgisinin kitabınızın önceki sayfalarında yazılanlarla sınırlı olduğunu varsaymak zorunluluğu vardır.

Ötesi okura bilmediği bir konuyu anlatılırken bilmediği başka bir konuya gönderme yapmamak gerekir. Örneğin C# kitabımda ve sözünü ettiğim makalede kullanıcı kaynaklı hataların yakalanması işleminin try-catch-finally blokları ile nasıl yapıldığını kısaca işaret ettikten sonra aşağıdaki gibi 2 cümle yazıp kısa bir kod verdim. C# 3.0 kitabımın Hata Yakalamak ve Exception Sınıfları adlı bölümünden yaptığım alıntıları italik yaptım.

Kullanıcıdan bir işlem için tarih istediğinizi varsayalım. Kullanıcı TextBox’a tarih olarak değerlendirilemeyecek bilgi girerse programın çalışması kırılabilir. Aşağıda verilen metot işletildiğinde TextBox’ın içeriği dönüştürülüp DateTime tipindeki değişkene aktarılır.

privatevoid textBox1_Leave(object sender, EventArgs e)
{
   DateTime Tarih;
   Tarih = Convert.ToDateTime(textBox1.Text);
}

Kullanıcı TextBox’a tarih veya zaman olarak değerlendirilebilinecek bilgi girdiği sürece bu kod hatasızca çalışır. Ne zamanki kullanıcı tarihsel tipe dönüştürülemeyecek bilgiyi TextBox’a girip başka nesnenin üzerine giderse bu kod hata verir ve program çalışması kırılır.

Tabii ki bu kod son derece basittir ve okur her şartta DataTime’ın bir veritipi olduğunu fark eder. Ötesi ToDataTime() metodunu ilk kez gören birisi bile bu metodun işlevini yazarın desteği olmadan da anlar. En ideali madem hata yakalama işlemini anlatıyoruz ve okurun kitabı ilk sayfadan itibaren okuduğunu varsayıyoruz, bu kısacak kod verilmeden çok önce okurun DateTime yapısı hakkında bilgi sahibi olması gerekir. Başka bir deyişle Hata Yakalama bölümünden önce kitapta tarih ve zaman bilgileri üzerinde yapılabilinen işlemlerin anlatılmış olması gerekir.

Ya C#’ta hata yakalama işleminin try-catch blokları ile yapıldığını söyledikten hemen sonra veritabanlarına özel bir hatadan söz etmiş olsaydım? Kitapta hata yakalama konusu veritabanı işlemlerinin anlatıldığı bölümden sonra olsaydı bu tercih bir soruna neden olmazdı. Bu nedenle kitaplarda yeni bir konuya geçildiğinde yazılanların kolay anlaşılmasını sağlamak için örnekler herkes tarafından bilinen bir konu veya işlemden yola çıkılarak hazırlanır. Bazı kitap ve makalelerde öyle karmaşık örnekler veriliyor ki okur anlatılan konuyu anlamaktan öte verilen örneğe kafa yormak zorunda kalıyor.

Madem hata yakalamayla ilgili olarak verdiğimiz kısa açıklama ve 2 satırlık kod 3-5 saniyede okunup anlaşılacak basitliktedir hemen bu koda try-catch bloğunu monte edebiliriz. Tekrarlamak gerekirse aşağıda verilen kodun benzerini her yerde bulmanız mümkündür. Arada bir fark varsa o da catch anahtar kelimesinin kullanıldığı satıra burada bir şey yazılmamış olmasıdır. Dolayısıyla bu 3 satırlık kodu birileri sahiplenirse, birileri çıkıp fikrimi çalmışsın derse ona gülümsemeyi ihmal etmeyin.

privatevoid textBox1_Leave(object sender, EventArgs e)
{
   DateTime Tarih;
   try
    {
      Tarih = Convert.ToDateTime(textBox1.Text);
    }
   catch
    {
      MessageBox.Show("Girdiğiniz tarih veya saat yanlış");
      textBox1.Focus();
    }
}

Konu hakkında az çok bilgisi olanların tahmin edeceği gibi bu kod işletilip ilk TextBox’a uygun tarih girilmeyip ikinci TextBox’ın üzerine gidilirse FormatException denilen yani string bilginin DateTime tipine dönüştürülememesi hatası ile karşılaşılır. Ancak başlangıçta okura meydana gelmesi muhtemel hatanın C# derleyicisinin nazarında hangisi olduğunu anlatmayı tercih etmedim. Başka bir deyişle ilk başta amacım try-catch bloğunun nasıl işlediğini göstermek olduğu için bir çok yazarın aksine catch deyiminin kullanıldığı satıra başka bir şey yazmadım. Çünkü aynı anda hem Exception sınıflarını hem de try-catch bloğunun işleyiş şeklini anlatmak istemedim. Çünkü amacım konuları birbirinden yalıtıp okurun ilk okumada yazılanları anlamasını sağlamaktır. Bir çok yazar arkadaşın kolay okunma bağlamında yaptıkları en büyük yanlış, okurun bilmediği birden fazla konudan veya işlemden aynı anda söz etmeleridir.

Yukarıda verdiğim kısacak kod hakkında ek bir cümle etmek istiyorum: Kullanıcı çalışma anında ilk TextBox’a ister bir şey yazmadan, isterse de tuttuğu futbol takımının adını yazıp öyle 2. TextBox’a geçsin aynı hata, yani FormatException hatası meydana gelir.

Exception Sınıfları

Okura böylelikle try-catch bloklarının nasıl işletildiğini işaret ettikten sonra Exception Sınıfları kavramına geçilebilir. Ancak ben tercihimi başka türlü yaptım. Konunun başına dönüyorum ve yukarıda verdiğim koddaki try-catch deyimlerini silip hata meydana geldiği zaman projenin çalışmasının sona erdirilmesini sağlayacağım

Bazı kaynaklarda konu try-catch olduğunda release ve debug modları hakkında bir iki cümle yazılmış olsa bile kimse okurun merakını gidermeyi tercih etmiyor. Eğer kurduğunuz cümleyi okuyan veya verdiğiniz örneği inceleyen okurun kafasında neler geçer, neleri merak eder vs gibi soruları kendisinize sorup bu sorulara kendinizce cevaplar vermiyorsanız yazdığınız metin Microsoft’un MSDN’deki metinlerden bir farkı olmaz. Başka bir deyişle yazdıklarınızda help metni tadı olur.

Kullanıcı yukarıda verdiğim kısa koddaki try-catch bloklarını kaldırıp(yani hata yakalayan satırları kaldırırsa) projeyi entegre debugger’dan bağımsız çalıştırırsa ne olur? Başka bir deyişle Start Debugging veya Build menüsündeki komutlar sayesinde hazırlanan EXE dosyayı Visual Studio’dan bağımsız çalıştırmak isterse ne olur?

Tabii ki okur projesini Visual Studio’nun Start Debugging komutu ile çalıştırıp formdaki ilk TextBox’a geçerli bir tarih bilgisini girmeden bir sonraki TextBox’ın üzerine giderse Debugger projenin çalışmasını durdurur. Ancak programcı hiçbir tedbir almadan formdaki ilk TextBox’ın Leave olayını temsil etmesi için aşağıdaki gibi bir metot hazırlayıp sonra projesini Visual Studio ile gelen entegre debugger’dan bağımsız çalıştırırsa ne olur?

privatevoid textBox1_Leave(object sender, EventArgs e)
{
   DateTime Tarih;
   Tarih = Convert.ToDateTime(textBox1.Text);
}

Bu konuyu neden mi uzattım: Cevap açık, henüz yolun başında olan programcı projesini hazırlayıp kullanıcıya teslim ettiğinde Visual Studio ile gelen entegre debugger’ın olmayacağını ve hatalar karşısında programının farklı tepkiler verebileceğini bilmesi gereklidir. Bu nedenledir C# kitabımın bu bölümünde aşağıda verilen 2 paragrafa ve 2 ekran görüntüsüne yer verdim.

Build menüsünden Build komutunu verip üzerinde çalıştığım projeyi derledim. Daha önceki konulardan bildiğiniz gibi Build menüsünden komut verilip üzerinde çalışılan proje derlendiğinde Debug modunda iken hazırlanan EXE dosya “\bin\debug” klasörüne, Release modunda iken derleme yapıldığında ise EXE dosya “\bin\release” klasörüne konulmaktadır. Derleme işlemini yaparken Release modunda olduğum için derleme sonucu hazırlanan EXE dosya “\bin\Release” klasörüne yerleştirildi.

Bu klasördeki EXE dosya çift tıklanıp proje çalıştırılıp TextBox’a girilen bilginin tarihsel bilgiye dönüştürülmesi sırasında hata meydana gelmesi sağlanırsa ekrana aşağıda verdiğim diyalog kutusu gelir. Kullanıcı bu diyalog kutusundaki Continue düğmesini tıklayıp hatanın atlanılıp göz ardı edilmesini sağlayabilir veya Quit düğmesini tıklayıp uygulamanın çalışmasını sona erdirebilir. Meydana gelen hata hakkında ayrıntılı bilgi edinilmek istendiğinde ise Details düğmesi tıklanır.

Davrandığı hatırlatıldıktan sonra sıra hata yakalama sınıflarını anlatmaya geldi .NET Framework ile gelen hata yakalama sınıfları konusunun değişik boyutları olduğu için hata üretmesi muhtemel farklı kodlar yazıp aynı konuyu tekrarlama yoluna gittim. Bu düşünce ile forma bir ListBox yerleştirip aşağıda verdiğim kodu yazdım.

string[] takimlar = new string[5];
int adet = listBox1.Items.Count;
for (int i=0; i<adet; i++)
   takimlar[i]=listBox1.Items[i].ToString();

Bu kodun anlaşılmaz bir yanı yoktur. Tabi bu değerlendirmeyi bu kitabın hata yakalama konusunun anlatıldığı sayfalardan öncesini okumuş olanlar için yapıyorum. Bu kodda önce 5 elemanlı string bir değişken tanımlanıp devamında for döngüsü ile mevcut ListBox’ın mevcut elemanları bu dizi değişkene aktarılmaktadır.

Yukarıda okurun karşılaşmasını istediğim FormatException hatasından başka programcıların sık yaptıkları hatalardan bir diğeri dizi değişkenlerde ve indeksleyicisi olan sınıflarda yapılan IndexOutOfRangeException hatasıdır. Madem bu hata sık yapılıyor üzerinde durmak gerekiyor. Kitabımda hataya neden olması muhtemel bu kodu aşağıdaki gibi try-catch bloğuna aldım.

privatevoid Form1_Click(object sender, EventArgs e)
{
   string[] takimlar = new string[5];
   int adet = listBox1.Items.Count;
   try
    {
      for (int i = 0; i < adet; i++)
        takimlar[i] = listBox1.Items[i].ToString();
    }
   catch
    {
      MessageBox.Show("Dizi Değişkenin sınırı aşıldı\n"+
           "Yalnızca ilk 5 eleman diziye aktarıldı");
    }
}

Koda dikkat edilirse catch deyiminin kullanıldığı satırda catch’den başka bir şey yoktur. Bu catch örneğinden sonra okurun çalışma anında hataya neden olabilecek satırları nasıl catch bloğuna alması gerektiğini kavradığına inanabilirsiniz. Burada da hataya neden olması muhtemel satırlarda okurun yabancısı olmadığı bir tek işleme yer verdim. Ötesi şimdiye kadar try-catch bloklarıyla ilgili olarak yalnızca şunu yazdım:Çalışma anında try bloğundaki herhangi bir satır hataya neden olursa programın işletimi hemen catch bloğuna geçer ve programın çalışması kırılmaz.

Artık herhangi bir hata meydana geldiğinde programın işletimi try bloğundan catch bloğuna geçtiğinde neler oluyor sorularına cevaplar verebiliriz. Bu düşünce ile yukarıda verdiğim kodu aşağıdaki gibi değiştirdim.

private void Form1_Click(object sender, EventArgs e)
{
string[] takimlar = new string[5];
int adet = listBox1.Items.Count;
try
   {
    for (int i = 0; i < adet; i++)
      takimlar[i] = listBox1.Items[i].ToString();
    }
catch(IndexOutOfRangeException Hata)
{
    MessageBox.Show("Meydana gelen hatanın mesajı:\n"+ Hata.Message);
}
}

Bazı okurlar muhtemelen itiraz edip diyeceklerdir ki, böyle adım adım anlatmak, okuru ikna etmeden başka konuya geçmemek sayfa sayısını arttırmaz mı? Elbette sayfa sayısı artar. Hem okuru konuya hazırlayacaksınız, hem kafasında oluşması muhtemel soruları öngörüp tek tek cevap vereceksiniz, hem okur saçını başını yolmadan yazılanları kolayca okuyacak, hem okur yazılanları ikinci kez okumak zorunda kalmasın diyeceksiniz hem de metin kısacık olacak. Tabii bu mümkün değildir. Yani yazar arkadaşımız tercihini yapacak: Ya anlatmak istediği konunun bütün boyutlarını içeren bir örnek verip onun üzerinde birkaç cümle yazıp başka hemen konuya geçecektir ya da anlatmak istediği konuyu alt konulara bölüp her seferinde okura bu alt konulardan birisini anlatacaktır.

Tam bu noktada catch(IndexOutOfRangeException Hata) satırı üzerinde biraz durmak ve tek başına catch yazılan satırdan farkını anlatmak gerekir. Kitabımda bu amaçla şu cümleye yer vermiştim: try bloğundaki satırlarda çalışma anında dizi değişkenlerle ilgili bir hata meydana geldiğinde IndexOfRangeException sınıfının örneği hazırlanıp catch bloğuna gönderilir. Demek ki try bloğunda nasıl bir hata meydana gelirse o hatayla ilgili sınıfın örneği alınıp catch bloğuna gönderiliyor. Eğer catch bloğunun ilk satırında catch deyiminden sonra parantezlerin içinde söz konusu sınıf tipinde bir değişken tanımlanmışsa o hata yakalanıyor. Daha doğrusu meydana gelen hatayı temsil eden sınıfın örneği catch deyiminin olduğu satırda tanımlanan değişkene aktarılıyor. Zaten verdiğim kodda bilerek bu nesnenin Message özelliğinin içeriğine baktım. Konunun hemen devamında okurun ilgili sınıfın örneğinin alınıp catch bloğuna gönderilmesi işlemini hemen kavramaması ihtimali yüksek olduğu için daha önce sizlerle paylaştığım Hata Yakalamak ve Exception Sınıfları adlı makaleye aşağıda verdiğim 2 paragrafı ve kısa kodu ekledim.

try bloğunda meydana gelen hatadan dolayı catch bloğuna gönderilen bütün nesneler System’de bulunan Exception sınıfından türetilen sınıfların örnekleridir. Bu kodda dizi değişkenin olmayan bir elemanı üzerinde işlem yapılmak istendiği için catch bloğuna IndexOutOfRangeException tipinde bir nesne gönderilir. Konu üzerinde düşünmenizi sağlamak için yukarıdaki sayfalanda verdiğim örneği aşağıdaki gibi düzenledim. Değişken adı çalma suçumu(!) hafifletmek için DateTime tipindeki değişkene “Tarih” yerine “History” adını verdim.

private void textBox1_Leave(object sender, EventArgs e)
{
   DateTime History;
   try
    {
     History = Convert.ToDateTime(textBox1.Text);
    }
   catch(IndexOutOfRangeException Hata)
    {
      MessageBox.Show("Girdiğiniz tarih veya saat yanlış");
      textBox1.Focus();
    }
}

Bu şartlarda TextBox’a DateTime tipine dönüştürülemeyecek bilgi girilip TextBox’tan ayrılıp Leave olayı meydana getirildiğinde try bloğundaki satırlar hataya neden olur ve programın işletimi catch bloğunda geçer. Ne var ki catch bloğunda dönüştürme işlemi sonucu meydana gelen hata yakalanamaz. Çünkü catch deyimine ait parantezin içinde IndexOutOfRangeException tipinde değişken tanımlandığı için catch bloğundaki satırlar işletilmeyip meydana gelen hatadan dolayı programın çalışması kırılır.

Bu açıklamadan sonra artık okura birden fazla catch bloğundan söz edilebilir. Bu düşünce ile birden fazla hataya neden olabilecek basit bir kod hazırladım. Aşağıda verdiğim kodda TextBox1 ve TextBox2’nin içeriğini Convert sınıfının ToByte() metodu ile dönüştürüp Number1 ve Number2 adını verdiğim byte tipindeki değişkenlere aktardım. Tanımladığım bu değişkenker Byte tipinde olduğu için bu TextBox’lara girilen bilgi 255’ten büyük olduğunda OverflowException hatası ile karşılaşılır. Normalde bu değişkenlere alışkanlıklarım gereği Sayi1, Sayi2 gibi adlar verirdim. Değişken adı benzerliği kabahatini tekrar işlememek için “Sayi” yerine Number’ı tercih ettim.

private void Hesapla_Click(object sender, EventArgs e)
{
   byte Number1 = Convert.ToByte(textBox1.Text);
   byte Number2 = Convert.ToByte(textBox2.Text);
   float Number3 = Number1 / Number;
   textBox3.Text = Number3.ToString();
}

Benzer şekilde bu 2 TextBox’a ToByte() metodu ile Byte tipine dönüştürülemeyecek bilgi girilirse FormatException hatası meydana gelir. Tabi kodun devamında Byte tipindeki bu 2 değişkenin içeriği birbirine bölündükleri için sıfıra bölme yani DivideByZeroException hatası meydana gelebilir. Bu kısacak kodda 3 hatanın meydana gelmesi muhtemel olduğu için okura Exception sınıfları hakkında bilgi vermek artık kolaylaşmıştır. Bazı yazarlar benzer bir işlemi, bir metodu veya sınıfı anlatırken örnek verirken özenli davranmazlar. Dolayısıyla verdikleri örnekle ilgili olarak okurun kafasında beliren soruları öngörmeye çalışmazlar. Bu nedenledir ki bazı arkadaşlar yukarıda verdiğim basit kodu küçümserler. Sanki karışık örnek verdiklerinde okurların kendilerine saygısı artacakmış…

Yukarıdaki sayfalarda amaç try-catch blokları hakkında bilgi vermekti. Tabi bu yapılırken ister istemez birkaç Exception sınıfından söz etmek gerekiyordu. Madem Exception sınıflarının nasıl kullanıldığından söz ettik artık .NET Framework ile hazır olarak gelen ve sık kullanılan bazı Exception sınıflarından söz edebiliriz. Tabi .NET Framework ile birlikte çok sayıda Exception sınıfı hazır olarak geldiği için hepsini anlatmak, hepsinden söz edip örnek vermek mümkün değildir. Ötesi bazı Exception sınıfları ancak ilgili oldukları konu ile paralel anlatıldığı zaman anlaşılmaktadır. Örneğin henüz Thread’ler hakkında bilgi sahibi olmayan okura Thread’lerle ilgili Exception sınıfından söz etmek anlamlı değildir. Gelin InvalidCastException ve NullReferenceExceptionsınıfından nasıl söz ettiğimi birlikte inceleyelim:

Tip dönüştürme işlemleri sırasında hata meydana geldiğinde InvalidCastException hatası meydana gelmektedir. InvalidCastException sınıfını anlatmak için aşağıda verdiğim kodu hazırladım. Bu kodda “Nesne” adı verilen object tipindeki değişkenin içeriği rakamlardan meydana geldiği için Unboxing işlemi yapılıp sorunsuz bir şekilde int tipindeki değişkene aktarılır.

object Nesne = 2008;
try
{
   int Yil = (int)Nesne; // Tehlikeli bir değişken adı
   this.Text = Yil.ToString();
}
catch (System.InvalidCastException Hataspor)
{
   MessageBox.Show("Dönüştürme hatası meydana geldi" + n\r" + Hataspor.Message);
}

object tipindeki değişkenin içeriği int tipindeki değişkene aktarılırken Unboxing işlemi başarısız olsaydı InvalidCastException hatası ile karşılaşılırdı. Başka bir deyişle object tipindeki değişken int tipindeki değişkene aktarılamayacak bilgi içeriyor olsaydı dönüştürme işlemi başarısız olurdu.

null yapılmış bir nesnenin özelliklerini kullanmak isterseniz NullReferenceException hatası ile karşılaşılır. Bu hata ile nasıl karşılaşıldığını göstermek için bir Bitmap nesnesi hazırladım. Ardından bu nesneyi null yapıp Width ve Height özelliklerini kullanmayı denedim. Aşağıda verdiğim kodda “i” ve “j” başka yerli yazarlar tarafından daha önce register edilmiş(!) değişken adları oldukları için alışkanlıklarımı bir tarafa bırakıp çift “ii” ve çift “jj” tercih ettim.

System.Drawing.Bitmap Resim;
openFileDialog1.ShowDialog();
string Dosya = openFileDialog1.FileName;
try
{
   Resim = new System.Drawing.Bitmap(Dosya);
   Resim = null;
   int ii = Resim.Width;
   int jj = Resim.Height;
}
catch(NullReferenceException)
{
   MessageBox.Show("Nesne null yapılmış");
}

Şimdi bazı okurlar diyecekler ki bu 2 sınıfı anlatmak için verdiğin kısacak örneklerde ne var? Gerçekte bu 2 örnekte orijinal bir şey yok. Madem bu kısa örnekler bu 2 sınıfın işlevini göstermek için verildiğinde okur bir sayfalık bu metni okuduğunda InvalidCastException ve NullReferenceExceptionsınıfları hakkında ilk okumada bilgi sahibi olur mu olmaz mı ona bakmak gerekir. Ötesi bu Exception sınıflarıyla ilgili olarak verilen örneklerde anlaşılmaz bir yan yoktur diyorsanız sorun yoktur.

Finally Bloğunu Nasıl Anlattım

Yukarıda anlatılan şekilde try-catch bloğunun işleyişi hakkında okuru bilgilendirdikten sonra finally bloğundan kısaca söz ettim. Neden mi finally bloğundan çok sonra söz ettim? Nedeni son derece basit : Okura yabancısı olduğu birden fazla konuyu aynı anda anlatmama kaygısı bu tercihimde etkili oldu. Yoksa bir örnekte try-catch-finally blokları bir seferde anlatılır. Tabi bu durumda henüz yolun başında olan, daha doğrusu hata yakalama ve Exception sınıfları hakkında yeterli bilgisi olmadığı için kitap edinen, makale okuyan okur yazılanları anlamakta zorluk çekecekti, belki yazılanları sonuna kadar okumayacaktı. Finally bloğu hakkında bilgi verirken aşağıdaki gibi basit bir örnek hazırladım.

private void Resim_sec_Click(object sender, EventArgs e)
{
   openFileDialog1.ShowDialog();
   string kutuk = openFileDialog1.FileName;
   Bitmap Resim = new System.Drawing.Bitmap(kutuk);
   pictureBox1.Image = (Bitmap)Resim;
   Resim = null;
}

Dikkat edilirse bu kısacak kodda ne try-catch ne de finally bloğu var. Niye mi her 3 bloğu bir seferde hazırlayıp vermedim? Amaç konuyu adım adım anlatıp ilk okumada anlaşılmasını sağlamaktır. Ötesi okurun bildiği bir konudan hareketle yeni bir konu anlatılmak istenmektedir. Eğer finally bloğunun işlevini henüz kavramamış okura finally bloğu ile Dispose işleminin yakınlığından söz etmiş olsaydım Dispose() metodu ve Dispose işlemi hakkında yeterince bilgisi olmayanların kafasını karıştırıp finally bloğunu anlatabilme şansını zora sokardım. Ötesi dispose işlemi hakkında ayrıntılı bilgisi olan okur zaten finally bloğunun ne işe yaradığını biliyordur. Bu kodu verdikten sonra kitapta aşağıda verdiğim 2 paragrafa ve koda yer verdim.

Kullanıcı OpenFileDialog nesnesi sayesinde ekrana getirilen diyalog kutusunu dosya seçmeden kapatır veya uygun olmayan bir dosyayı seçerse hata meydana gelir. Kullanıcının yanlış yaptığı veya yapmadığı dosya seçiminden dolayı meydana gelecek hata konusunda kendisine bilgi vermek için yukarıda verdiğim kodu aşağıdaki gibi düzenledim.

private void Resim_sec_Click(object sender, EventArgs e)
{
   System.Drawing.Bitmap Resim;
   openFileDialog1.ShowDialog();
   string kutuk = openFileDialog1.FileName;
   try
    {
      Resim = new System.Drawing.Bitmap(kutuk);
      pictureBox1.Image = (Bitmap)Resim;
      Resim = null;
    }
catch
   {
     MessageBox.Show("Uygun dosya seçmediniz");
   }
}

Kullanıcı “Aç” diyalog kutusunda resim dosyası seçmezse veya uygun olmayan bir dosyayı seçerse catch bloğundaki satır işletilip kullanıcıya bilgi verilir. Ancak bu durumda Bitmap tipindeki nesne bellekte yaşamaya devam eder. Çünkü “Resim” adını vermiş olduğum Bitmap nesnesini null yapan satırı try bloğuna yazmıştım.Hata meydana gelsin veya gelmesin mutlaka işletilmesini istediğiniz satırlar varsa bu satırları finally bloğuna yazmalısınız. finally bloğunun nasıl kullanıldığını anlatmak için yukarıda verdiğim kodu aşağıdaki gibi değiştirdim. Burada Bitmap tipindeki değişkeni blok içinde tanımladığım için Garbage Collector zaten bir süre sonra devreye girip bu nesneyi bellekten temizler ama buradaki amacımız deneysel.

private void Resim_sec_Click(object sender, EventArgs e)
{
   System.Drawing.Bitmap Resim;
   openFileDialog1.ShowDialog();
   string Dosya = openFileDialog1.FileName;
   try
    {
      Resim = new System.Drawing.Bitmap(Dosya);
      pictureBox1.Image = (Bitmap)Resim;
    }
catch
    {
   MessageBox.Show("Uygun dosya seçmediniz");
    }
finally
     {
        Resim = null;
     }
   }

Bu anlatılanlara göre ister hata meydana gelsin ister gelmesin finally bloğuna her şartta işletilmesi istenen satırlar yazılmalıdır. Her ne kadar konuyu adım adım anlatmış ve bazılarına göre uzatmış olsam bile finally bloğu hakkında yazılanları okumak fazla zaman almaz. Okur kısa sürede finally bloğunun işlevi hakkında bilgi sahibi olur. Tabi buradaki asıl amaç finally bloğunun ne zaman ve nasıl işletildiğini anlatmaktır. Yoksa finally bloğunda yapılabilinecek işlemleri tek tek saymak değildir.

Delphi Prism İle Tanışmak

Fri, 09 Oct 2009 10:36:54 GMT

Resim Dosyalarını Yazdırmak

Fri, 09 Oct 2009 02:36:23 GMT

MD5 Algoritması İle Şifreleme Yapmak

Thu, 08 Oct 2009 08:03:16 GMT

Programcılar İçin Yazarlık Dersleri - 2 (*)

Thu, 08 Oct 2009 00:30:22 GMT

Film yönetmenleri kendilerine gelen hikayeyi veya senaryoyu nasıl anlatacaklarına, hangi noktalara vurgu yapacaklarına, olayları nasıl sıralayacaklarına karar vermeden önce uzun çalışmalar yaparlar. Ne var ki benzer çalışmayı programcılık üzerine yazanlar yapmıyorlar. Bildikleri konuları bir baştan başlıyorlar anlatmaya. Tabi neyi nasıl anlatmak gerek sorusu üzerinde yeterinde kafa yormamış yazarların konuları anlatış şeklinin ve sırasının akıbeti çoğunlukla şans eseri kabul edilebilir olgunlukta oluyor. Bir önceki makaleyi okunabilir boyutta tutmak için 10. sayfada kesmiştim.

Yazar Okurun İhtiyaç Duyduğu Tekniklere Mi Odaklanmalı?

Konu programcılık veya bir programlama dili üzerine yazmak olduğunda yazar temelde 2 kaygından etkilenir. Birinci kaygı; okurun muhtemel ihtiyaçlarını gözetip bilgi vermek ve çok kullanılan tekniklerden söz etmektir. Örneğin ADO.NET konulu bir kitap yazıyorsanız veya bir eğitim merkezinde hocalık yapıyorsanız okurların ve öğrencilerin hazırladıkları SQL Server veritabanını başka bilgisayara götürme ihtiyaçlarını öngörüp ona göre okuru ya da öğrencileri bilgilendirmeyi hedeflersiniz. Tabii okurların veya öğrencilerin konu programcılık olduğunda ileri ki günlerdeki muhtemel ihtiyaçlarının hepsini baştan öngörüp kitabın içeriğini oluşturmak mümkün olmadığına göre yazar kendince bazı seçimler yapar.

Yazarın veya hocanın programcılık anlatırken etkisinde kaldığı ikinci kaygı ise bazı kavramları veya işlemleri anlaşılabilir yapmak, okurun bu kavramları anlayabilmesidir. Eğer birincil amacınız programcılıkla ilgili bir kavramı, bir işlemi okurun veya öğrencinin anlaması ise, konuyu işlerken veya örnek verirken pratik değer aramaz, vereceğiniz örneğe okurun ileriki günlerde ihtiyacı olur mu olmaz mı bakmazsınız. Örneğin .NET uyumlu programlama dillerinde Application sınıfı ile hiç ilgilenmeden profesyonel kalitede programlar yazmak mümkündür. Bu nedenledir ki birçok yerli yabancı kaynakta ya Application sınıfından hiç söz edilmez ya da birkaç cümle ile geçiştirilir. Tabii Application sınıfının sık gerek duyulan bir kaç metodundan söz edilir ama bu söz etmede Application sınıfına vurgu yapılmaz. Örneğin uygulamanın çalışması sona erdirilirken gerek duyulan Exit() metodundan bir cümle ile söz edilir. Okurunuzu Application sınıfı hakkında mutlaka bilgilendirmek istiyorsanız belki de okurların hiçbir zaman kullanmaya gerek duymayacakları bazı işlemlerden söz edeceksiniz. Örneğin sanki Application sınıfı .NET Framework ile gelmiyormuş gibi davranıp, başka bir deyişle C++ programcıları gibi mesaj kuyruğu hazırlamak isteyebilirsiniz.

Gelelim bu derslerde sık sık atıfta bulunduğum C# 3.0 kitabıma: Bu kitapta zaman zaman anlattığım konunun kolay kavranmasını sağlamak için yaptığım veya anlattığım işlemlerin pratik değeri var mı yok mu göz ardı ettim. Örneğin Application sınıfı hakkında bilgi verilen bölümde birincil amaç Application sınıfı hakkında yazılanların anlaşılmasını sağlamak olduğundan zaman zaman pratik değeri olmayan işlemler yapılıp üzerinde konuşuldu. Örneğin .NET uygulamalarında Application sınıfının Run() metodu çok özel durumlar hariç yalnızca bir kez kullanılır. Run() metodunun işlevinin kavranması için henüz Application sonlanmamış iken Run() metodunu ikinci kez kullanılıp hata meydana gelmesine neden olup okurun konu üzerinde düşünmesi sağladım. Bu bağlamda yazarlara önerim şudur: Anlattığınız konu kolay anlaşılan ve arka planını bilmek gerekmeyen bir konu ise mümkünse verilen örneklerde pratik değer aranmalıdır. Anlatılan konu zor anlaşılan bir konu ise pratik değer kaygısı başlangıçta bir tarafa bırakılabilinir.

Ekran Görüntüleri Hangi Büyüklükte Olmalıdır?

1992 yılında dergilerde yayınlanan ilk yazılarımda ve 1994 yılında yayınlanan ilk kitabımda o günlerin kitaplarından farklı olarak ekran görüntülerine yer vermiştim. Memik Yanık’a hücum etmek isteyenlerin ilk enstrümanı şuydu:“Memik Yanık’ın kitaplarında ekran görüntülerinden başka bir şey yoktur”. Şimdilerde bakıyorum da bırakınız ekran görüntüsüz programcılık kitabı bulmayı makale bulmak bile zordur. Asıl sorun da tam burada başlıyor:Kitap metni içinde veya makalede ne sıklıkta ekran görüntüsü kullanılmalı, ekran görüntüleri hangi büyüklükteki olmalı, ekran görüntüsü sayfanın neresine konulmalıdır, okurun ekran görüntüsünü yazının parçasıymış gibi görmesi için neler yapılmalıdır? Bu gibi sorulardan “bi haber” olanların kitaplarında veya makalelerinde ekran görüntülerini işlevsel kullanabilmeleri şansa veya tesadüfe kalmıştır. İncelediğim birçok yerli ve yabancı kaynakta yazar ekran görüntülerini alıp kitaba konulmasını sağlamış. Ekran görüntüsünü alırken öyle özensiz davranıyorlar ki dikkatli incelerseniz şaşırırsınız. Örneğin yazarın birisi kitabında Visual Studio’nun ilk karşılaşılan penceresini okuruna göstermek için şöyle bir ekran görüntüsünü alıp kitabında kullanıyor.

Tabi bu ekran görüntüsünün orijinal genişliği çok fazla olduğu için ancak %50-60 oranında küçültüldüğü zaman kitaba sığabiliyor. Bu durumda ekran görüntüsünün üzerindeki yazıları ve pencere başlıklarını çıplak gözle okuyabilmek mümkün olamıyor. Memik Yanık tarafından kaleme alınan kitaplarda ise bu ekran görüntüsü aşağıdaki gibi olmaktadır. Tabi bu ekran görüntüsü kitapta fazla yer kaplamasın diye belli bir oradan küçültülüp öyle kullanılırdı.

Gerçekte yazdığım kitaplarda bu tip ekran görüntüleri daha küçüktür. Sanırım ne demek istediğim anlaşıldı. Ekran görüntüleriyle ilgili olarak yapılan bir başka yanlış ise şudur. Yazarımızın(yerli veya yabancı) MessageBox sınıfının Show() metodundan söz ettiğini varsayalım. Yazarımız kitabında muhtemelen aşağıdaki gibi bir ekran görüntüsü kullanır.

Dikkat edilirse bu ekran görüntüsü çok büyük değildir ve kitapta fazla yer kaplamaz. Birçoklarınıza bu normal gelir. Hal bu ki yukarıda verilen ekran görüntüsü %50-60 küçültülürken bu ekran görüntüsü olduğu gibi bırakılmış ve orijinal büyüklüğüyle kullanılmıştır. Yani ne büyütülmüş ne de küçültülmüştür. Bu ekran görüntüsü Memik Yanık tarafından yazılan bir kitapta kullanılsaydı aşağıdaki gibi olurdu. Çünkü Memik Yanık kitaplarında kullandığı bütün ekran görüntülerini %30 ile 35 arasında değişen oranlarda küçültüp öyle kullanmaktadır. Çünkü Memik Yanık için en önemli parametre ekran görüntülerinin üzerindeki yazıların çıplak gözle ve gözlerinde bozukluk olmayanlar tarafından kolaylıkla okunabilmesidir.

Belki en doğrusu ekran görüntülerinin boyutları hakkında bilgi verirken yerli yabancı birkaç kitapta kullanılan ekran görüntülerini buraya alıp üzerinde konuşmak olurdu. Ancak bu tercih Memik Yanık’ın suçlanmasına neden olurdu:Yazarlık dersi adı altında başka yazarların eksikliklerini bize anlatıyorsun derlerdi. Tam bu noktada bir yıl önce karşılaştığım trajik komik durumu size anlatacağım. Programcılık konulu bir forumda üyenin birisi bir programcılık kitabı hakkında bilgi istiyordu. Başka bir deyişle ilgilendiği kitabı satın almadan önce forumun diğer üyelerinin görüşlerini almak istemişti. Konu dallanıp budaklanınca “söz konusu kitap elime geçince ciddi bir incelemeden geçirip fikirlerimi sizlerle paylaşırım” demiştim. Aradan henüz yarım saat geçmemişken bir mail aldım: Maili gönderen söz konusu kitabı yayınlayan firmanın avukatıydı. Kitap hakkında konuşursam beni dava edeceklerini beyan ediyordu. Yani henüz görmediğim, içeriğinden haberdar olmadığım bir kitabın tanımadığım yazarı kitabı hakkında ileri ki günlerde bir şeyler yazmamı istemiyordu avukat bey. İşin garip tarafı bu mail bana ulaştıktan sonra birkaç ay sonra kitabı inceleme imkanım oldu. Baktım yazar konuya hakim ama bazı anlatım ve konuları sıralama sorunları var. Eğer o kitap hakkında yazsaydım adım gibi eminim ki yazar kitabının ikinci baskısında büyük değişikliklere giderdi.

Şimdi ise 2. bir olayı anlatacağım. Bir gün bir yayınevinde oturuyordum. İçeriye kendisini tanımayıp ancak C üzerinde yazdığı kitaptan dolayı adını bildiğim bir yazar geldi. Tanışma faslından hemen sonra yazar arkadaş gitti kitabının örneğini alıp geldi. Çünkü yakın bir zamanda kitabının yeni basımını hazırlamak istiyordu. Kitabında yapacağı ekleme veya çıkarmalar konusunda fikirlerimi almak istiyordu. Yarım saat içinde kitabının bazı sayfalarını inceledim kendisine önerilerde bulundum. Oldukça tecrübeli yazarımız bu önerileri tek tek not alıp gitti. Yarım saat içinde kitapta görebildiğim eksikleri, aksaklıkları saymıştım. Çünkü yazar arkadaşın amacı kitabını daha iyi yapmaktı, amacı övgü duymak değildi.

Ekran Görüntüleri Nasıl Kullanılmalıdır?

Kitap metni içinde kullanılan ekran görüntülerinin büyüklüklerinden biraz söz ettikten sonra şimdi sırada ekran görüntülerini kullanma sıklığı ve işlevinin üzerinde biraz durmak gerekecek. 1995 yılında DOS ve Windows 3.1 ağırlıklı Herkes İçin Bilgisayar kitabımı yayınladığım günlerde bilgisayar ve programcılık kitaplarında ekran görüntüsü kullanımı pek yaygın değildi. Çünkü DOS ortamında ekran görüntüsü almak zahmetliydi. O zamanlarda kitaplarda ekran görüntülerine yer vermeme kimse bir şey dememişti. Bırakın itiraz edilmesini bu kitaplar okurlardan yoğun ilgi görmüştü. Ne zaman ki kitaplarımın sayısı fazlalaştı saldırılar başladı. Bazıları çeviri yaptığımı söylerken bazıları “kitaplarında ekran görüntüsünden başka bir şey yok” diyorlardı. Tabii bunları söyleyenler genelde Memik Yanık kitabı okumamış ve Memik Yanık kitaplarına ihtiyaç duymayan kişilerdi. Memik Yanık’a kızıyorlardı, programcılık gibi teknik bir konunun bu kadar kolay öğrenilebilir olması insanları şaşırtıyordu. Neden Memik Yanık kitapları diğer yazarların kitaplarından daha kolay okunuyor, kolay anlaşılıyordu? Bu sorunun en kestirme cevabı; okuru ikna etmeye çalışırken karışık cümlelerden kaçınmak, yer yer ekran görüntülerini kullanmak, küçük tekrarlar yapmaktır.

Şimdi gelelim asıl konumuza. Yani ekran görüntüleri nerede nasıl kullanılmalıdır sorusuna cevap arayalım. Konumuz Delphi'de kod yazarak nesneleri ilk yerleştirildikleri formdan başka bir forma taşımak olsun. Amacınız okurun hayal gücünü geliştirmek değilse yapmak istediğiniz işlemi veya amacımızı bir iki cümle ile ortaya koyduktan sonra 2 forma sahip bir Delphi projesi hazırlarsınız. Tabii kitabınızı şişirmeme gibi bir kaygınız varsa veya ekran görüntüleri konusunda özenli davranmayı ilke edinmişseniz kitap metni içinde ekran görüntüsü olarak kullanacağınız formların boyutlarına dikkat edersiniz.

Bazıları çıkıp diyecekler ki yukarıda bold yapılan cümle yeterince açık değil mi? Okurunuz tıpkı üniversite seçme sınavındaki gibi konuya odaklanmışsa bu cümlenin yeterince açık ve anlaşılır olduğu söylenebilir. Daha doğrusu kolay okunma diye bir kaygınız yoksa veya hemen anlaşılma, hızlı okunma amaçlarınız yoksa yukarıdaki cümleden sonra formdan forma nesne taşıyan Delphi kodunu verirsininiz olur biter. Bu durumda yazılanların programlama dilinin help metinlerinden bir farkı olmaz. Aşağıda verilen metni kendi cümlelerimle yazmış olmakla birlikte kaleme alırken başka yazarları taklit etmeye çalıştım. Konunun devamında ekran görüntülerini kullanıp kendi tarzımda anlatacağım.

Tam noktada Delphi ile ilgisi olmayan yazarlar ve yazar adayları için 2 cümle yazmam gerekiyor: Aşağıda hiç ilgilenmediğiniz, belki de bundan sonra hiç ilgilenmeyeceğiniz bir programla dili hakkında son derece teknik bir işlem hakkında bilgi verilmektedir. Bazı arkadaşlar tam bu noktada Delphi ile ilgili sayfaları atlayacaklardır. Nasıl ki lisede verilen matematik derslerinde ikide bir söylenip “türevin integralin gerçek hayatta bana ne faydası olacak, hangi işlemi yaparken kullanacağım?” diye fikirlerini beyan edenler bilim üretebilme becerisine sahip kişiler değillerse Delphi konulu bu metni okuma zahmetine katlanamayacak olanların iyi yazar olabilmeleri şüphelidir. Yazar olmak istiyorsanız, yazdıklarınız anlaşılsın istiyorsanız öncelikle yabancısı olduğun konuları okuyabilme sabrını göstermeniz gerekir. Üzerinde konuşacağım örnek metni italik yaptım.

Delphi'de bir formdaki nesneleri veya kontrolleri başka bir forma taşırken RemoveComponent ve InsertComponent metotları kullanılmaktadır. Form1'deki Edit1 ve Edit2’nin Parent özelliklerinde değişiklik yapılırsa Form2’nin üzerinde görüntülenirler.

procedure TForm1.AktarClick(Sender: TObject);
begin
Edit1.Parent := Form2;
Edit2.Parent := Form2;
end;

Şimdi ise Form2’de görüntülenen bu 2 nesnenin For1’den silinmesini sağlayacağım.

procedure TForm1.SilClick(Sender: TObject);
begin
Form1.Components[1].Free;
Form1.Components[0].Free;
end;

Bu 2 satır sayesinde Form1’deki ilk 2 kontrol silinir. Koda dikkat ederseniz Edit1 ve Edit2 nesneleri Form2’nin üzerinde görünürken bu kontroller henüz Form1’e aittir veya Edit1 ile Edit2’nin sahibi Form1’dir. Bu nedenle Free metodu ile silme işlemini yaparken Form2 yerine Form1’ın adını yazdım. Şimdi RemoveComponent ve InsertComponent metotlarını bir yordama alıp öyle işleteceğim.

procedure TForm1.Uzaklastir(Bilesen: TComponent; Sahip: TComponent);
begin
  Bilesen.Owner.RemoveComponent(Bilesen);
  Sahip.InsertComponent(Bilesen);
end;

“Uzaklastir” adını verdiğim yordamı bu şekilde hazırladıktan sonra aşağıdaki gibi hazırlık yaptım. Bu kod sayesinde Form1’deki 2 Edit Form2’ye aktarılır.

procedure TForm1.AktarClick(Sender: TObject);
begin
Form1.Edit1.Parent := Form2;
Form1.Edit2.Parent := Form2;
Uzaklastir(Edit1, Form2);
Uzaklastir(Edit2, Form2);
end;

Aslında bu metin Delphi konusunda ortalama bilgiye sahip olanlar için son derece anlaşılırdır. Ne var ki Delphi uzmanları dönüp bu metne bakmazlar bile. Onların burada yazılanları anlamaları için metindeki kod satırlarına uzaktan bir kaç saniye bakmaları yeterlidir. Biz yazarlar uzmanlar için kitap yazmadığımız için, başka bir deyişle yazdıklarımızla hiç ilgilenmeyecekleri baştan belli olanları gözeterek konuları kaleme almadığımız için uzmanların böyle bir metin karşısındaki yaklaşımlarını ölçü almayız. Hemen söyleyeyim ki yukarıda verilen kısacak metin ve birkaç satırlık kod Delphi'nin bileşen kavramının temelini oluşturuyor. Bu nedenle oldukça önemlidir. Önemli olduğu için de okurun yazılanları kavraması için ek açıklamalar yapılmalıdır. Üstelik bu ek açıklamalar pat diye yapılmamalıdır. Okur öncelikle olası sorunlarla yüz yüze getirilmelidir. Okur formlar arası nesne taşıma konusunda karşılaşacağı sorunlar hakkında bilgi sahibi yapıldıktan sonra çözümden söz edilmelidir.

Bu metni okuyan kişi Delphi uzmanı değilse(ki Delphi uzmanı zaten böyle bir metne dönüp bakmaz) yapılan işlemlerin geri planını merak eder. Belki de işin içinden çıkamaz. Bu konu bu şekilde anlatıldığı zaman anlaşılmama olasılığına karşı, başka bir deyişle anlaşılmayı garanti etmek için bu konuyu aşağıdaki gibi anlatmayı tercih ettim. Bu şekilde düzenlenen metni hızlıca bir kez okursunuz. İkna olup zaman kaybetmeden konuyu kavramış halde başka konuya geçersiniz.

Delphi hakkında ortalamanın üzerinde bilgisi olan birisi bu metni gördüğünde büyük bir ihtimalle “yazar kitabı şişirmiş, sayfaları ekran görüntüleri ile doldurmuş” diyecektir. Programcılığı meslek olarak seçmiş olanların ve programcılık üzerine yazanların gözden kaçırdıkları önemli bir nokta var: Programcılar hayal güçleri olağanüstü kişiler değildir. Bu nedenle zaman zaman ekran görüntülerine yer verip konudan kopmalarının önüne geçmek gerekir.

Nesneleri Bir Formdan Diğerine Taşımak

Delphi projelerinde bir formdaki kontrolleri başka bir forma taşırken RemoveComponent ve InsertComponent metotları kullanılmaktadır. Bu 2 metodun nasıl kullanıldığını anlatmak için 2 forma sahip bir proje hazırladım.

Bu ekran görüntüsü kitap veya makale metni içinde yaklaşık 5 satırlık yer kaplamaktadır. Başka bir deyişle kitapta bu büyüklükte bir ekran görüntüsüne yer verildiği zaman kitap metni 5 satırlık bir paragraf kadar artmış olur. Yazarın bu ekran görüntüsünü 2 satırda tarif edeceğini düşünürsek kitapta bu ekran görüntüsüne yer verilmekle gerçekte kitap metni 3 satır kadar artmış oluyor. Çünkü yukarıda verdiğim metne bakarsanız “2 forma sahip proje hazırladım” demekle yetindim. Eğer ekran görüntüsüne yer vermeseydim okurun hayal gücüne yaslanıp ekran görüntüsü verilen 2 formu uzun uzun tarif etmem gerekecekti. Tabi bazı yazarlar özensiz davranıp sanki artı bir faydası olacakmış gibi ekran görüntülerini kocaman alıyorlar sonra da küçültüyorlar. Bu durumda ekran görüntüsündeki yazıları okumak için büyütece gerek duyuluyor.

Çalışma anında ilk formdaki “Göster” düğmesi tıklandığında “Form2” ekrana getirilecek. Bu amaçla Unit2’yi Uses bloğunda Unit1’e dahil ettikten sonra “Goster” düğmesi için aşağıda verdiğim kodu yazdım.

procedure TForm1.GosterClick(Sender: TObject);
begin
   Form2.Show;
end;

Çalışma anında “Aktar” düğmesi tıklandığında ise Edit1 ve Edit2’nin Parent özelliklerinde değişiklik yapılıp Form2’nin üzerinde görüntülenmesini sağlayacağım.

procedure TForm1.AktarClick(Sender: TObject);
begin
Edit1.Parent := Form2;
Edit2.Parent := Form2;
end;

Aşağıda verilen ekran görüntüsünü önce “Göster”, sonra “Aktar” düğmelerini tıkladıktan sonra aldım. Bu sırada Edit1 ve Edit2 projedeki 2. formun üzerinde görünüyor olsalar bile bu 2 nesnenin sahibi henüz Form1’dir.

Gerçekte tam bu noktada Delphi programcıları için önemli bir konu var: Edit nesneleri Form2’nin üzerinde görünürken sahibi henüz Form1’dir. Bu ekran görüntüsü sayesinde okurun bu önemli noktaya dikkati çekilmektedir. Bu ekran görüntüsü kullanılmasaydı okur belki aynı metni 2 kez okumak zorunda kalacaktı.

Çalışma anında “Sil” düğmesi tıklandığında Form2’de görüntülenen ilk 2 nesnenin Form1’den silinmesini sağlayacağım. Bu amaçla ilk formdaki “Sil” düğmesinin Click olayıyla ilgili metodu aşağıdaki gibi düzenledim.

procedure TForm1.SilClick(Sender: TObject);
begin
Form1.Components[1].Free;
Form1.Components[0].Free;
end;

“Sil” düğmesinin Click olayını temsil eden metoda yazılan bu 2 satır sayesinde Form1’deki ilk 2 kontrol silinir. Koda dikkat ederseniz Edit1 ve Edit2 nesneleri Form2’nin üzerinde görünürken bu kontroller henüz Form1’e aittir veya Edit1 ile Edit2’nin sahibi Form1’dir. Bu nedenle Free metodu ile silme işlemini yaparken Form2 yerine Form1’ın adını yazdım. Burada yapılması gereken Parent özelliği ile nesnenin görüntülenmesinden sorumlu olacak formu(yani sınıfı) değiştirdikten sonra Owner özelliğini de değiştirmektir. Bu işlemi yapmak için aşağıda verdiğim kodu yazdım.

procedure TForm1.AktarClick(Sender: TObject);
begin
Form1.Edit1.Parent := Form2;
Form1.Edit1.Owner.RemoveComponent(Edit1);
Form2.InsertComponent(Edit1);
Form1.Edit2.Parent := Form2;
Form1.Edit2.Owner.RemoveComponent(Edit2);
Form2.InsertComponent(Edit2);
end;

Bu kod hakkında bilgi vermeden bu kodun hataya neden olacağını söylemeliyim. Bu kodda önce Form1’deki “Edit1” nesnesi RemoveComponent metodu ile Form1’den uzaklaştırılıp InsertComponent metodu ile Form2’ye eklenmektedir. Ancak Edit’ler ve diğer nesneler RemoveComponent metodu ile Form1’den uzaklaştırıldığı anda bellekten silinmiş olmaktadır. Dolayısıyla olmayan bir nesneyi InsertComponent metoduna parametre olarak vermek hataya neden olur.

Bu sorunu gidermek için ilk akla gelen yöntem bu işlemi yapacak bir procedure hazırlamaktadır. Daha önce Türkiye’de yayınlanan bir kitapta bu yöntem anlatıldığı için öncelikle söz konusu Edit nesnesini RemoveComponent metodu ile Form1’den uzaklaştırmadan önce bir değişkene aktamayı tercih ettim.

procedure TForm1.AktarClick(Sender: TObject);
Var
   E :TEdit;
begin
   Form1.Edit1.Parent := Form2;
   E := Form1.Edit1;
   Form1.Edit1.Owner.RemoveComponent(Edit1);
   Form2.InsertComponent(E);
   Form1.Edit2.Parent := Form2;
   E := Form1.Edit2;
   Form1.Edit2.Owner.RemoveComponent(Edit2);
   Form2.InsertComponent(E);
end;

Bu kod sayesinde Edit1 ve Edit2’nin Form1 sınıfıyla bir ilişkisi kalmaz. Bu kod işletildikten sonra Edit1 ile Edit2’nin hem Owner’ı hem de Parent’ı Form2 olur. Bu şartlarda, yani Form2’de yalnızca 2 nesne varken “Sil” düğmesi için yazılan kodda önce Edit2 silinmelidir yoksa hata meydana gelir.

procedure TForm1.SilClick(Sender: TObject);
begin
  Form2.Components[1].Free;
Form2.Components[0].Free;
end;

Şimdi ise RemoveComponent ve InsertComponent metotlarını bir metoda alıp öyle işleteceğim. Hazırlayacağım metot TComponent tipinde 2 parametreye sahip olacaktır.

procedure TForm1.Uzaklastir(Bilesen:TComponent;Sahip:TComponent);
begin
  Bilesen.Owner.RemoveComponent(Bilesen);
  Sahip.InsertComponent(Bilesen);
end;

“Uzaklastir” adını verdiğim metodu bu şekilde hazırladıktan sonra “Aktar” düğmesinin Click olayını temsil eden metodu aşağıdaki gibi düzenledim. Bu kod sayesinde Form1’deki 2 Edit nesnesi Form2’ye aktarılır.

procedure TForm1.AktarClick(Sender: TObject);
begin
Form1.Edit1.Parent := Form2;
Form1.Edit2.Parent := Form2;
Uzaklastir(Edit1, Form2);
Uzaklastir(Edit2, Form2);
end;

Birinci anlatım daha kısa oldu. Delphi konusunda belli bir düzeye gelmiş kişilere, daha doğrusu artık kitap almayıp, Memik Yanık veya başka bir yazar tarafından kaleme alınmış metinlere dönüp bakmayanlara göre kısa olanı tercih etmek gerekir. Nasıl olsa onların bu konuyu öğrenme gibi bir dertleri yoktur. Yazar arkadaşım fazladan yazılan her kelime her cümle okur için zaman kaybıdır, kitabınızdan alınacak faydanın azalmasıdır. Ne var ki vur deyince öldürmemek gerekir, metin kısa olacak diye okunması zor, okunsa bile söylenenler anlamak zahmetli oluyorsa durup düşünüp metni yeniden kaleme almak gerekir.

Kod İçinde Açıklama Metni Kullanmak

Bazı yerli ve yabancı yazarlar makalelerinde ve kitaplarında kullandıkları 15-20 satırlık yani yarım sayfalık kodun içine uzun uzun açıklamalar yerleştirerek söz konusu kodun 1,5-2 sayfa kadar uzamasını tercih ediyorlar. Kodun arasına uzun açıklamalar ekleyerek kolay anlaşılmak veya kodda kullanılan her satırın işlevinin okur tarafından hemen fark edilmesini istiyorlar. İlk bakışta sanki doğru bir terciymiş gibi görülür bu. Böyle bir tercih ile hazırlanan metni okumak bir bakıma dublajı bilmediğiniz bir dilde yapılmış olup bol konuşmalı alt yazılı bir filmi izlemeye benzer. Hele hele filmdeki karakterler hızlı konuşuyorlarsa bazen de aynı anda birden fazla kişi konuşuyorlarsa bütün alt yazıları okuyup filmi anlamak ağır bir işte çalışmak gibi yorucudur. Yani yazarlarımız kodun içine bol bol açıklama metni koyarken sanıyorlar ki okur konuyu daha kolay anlıyor, kodda yapılan işlemleri bir bakışta kavrıyor.

Yıllardır yüz binlerce programcılık konulu sayfa okumuş birisi olarak söylemek isterim ki kodun içinde uzun açıklamalar yapmak kadar metni zor okunur yapan başka bir teknik yoktur. Elbette kodun içine açıklama metni yazılır, elbette dozunda tutulmuş açıklama metninin okura katkısı olur. Burada dikkat edilmesi gereken açıklama metinlerin kısa olması ve sayılarının fazla olmamasıdır.

Yazarın birisi daha önce hakkında hiç söz etmediği bir kavram veya anahtar kelime hakkında kodun içinde 3 satırlık yani neredeyse bir paragraflık açıklama metnine yer veriyor. Devamında bir sonraki kod satırı için tekrar açıklama metni kullanıyor. Başka bir deyişle kod satırları, kod satırlarını açıklayan metinlerin içinde kayboluyor.

Açıkçası hazırladığınız 10 satırlık kodun 5-6 satırı için kod içinde açıklama metni hazırlıyorsanız okurunuzu o kod için hazırlamamışsınız, okurunuz o kodda kullanılan sınıflardan, metotlardan ve anahtar kelimelerden henüz habersizdir demektir. Yapılması gereken; kodda kullanılan sınıflar, anahtar kelimeler hakkında önceden okura bilgi verip ondan sonra kod hazırlamaktır. Kod içinde kullanılmasına rağmen daha önce söz edilmeyin veya okurun unutmuş olabilme ihtimali yüksek bir iki metot hakkında en fazla 3-4 kelimelik açıklama metinleri yararlı olabilir.

*Bu metni yaklaşık 1 yıl önce yazıpilk kez memikyanik.com'da yayınlamıştım. Bütün teknik makaleleri memikyanik.net'e almak istediğim için gözden geçirip birkaç yazım hatasını düzeltip buraya aldım. Bu sayede daha önce memikyanik.com'da rastlamayanların istifadesine sunmuş olduk.

DataAdapter DataSet İlişkisi

Mon, 05 Oct 2009 20:36:07 GMT

NetworkInformation Sınıfı

Sun, 04 Oct 2009 00:15:27 GMT

Kod Yazarak ListView Nesnesi Hazırlamak

Sat, 03 Oct 2009 15:07:58 GMT

ArrayList Sınıfının FixedSize ve ReadOnly Metotları

Sat, 03 Oct 2009 14:58:16 GMT

Delphi : 6. Ders : Adım Adım Class Hazırlamak(*)

Sat, 03 Oct 2009 14:26:38 GMT

Kod Yazarak Formların İkonunu Değiştirmek

Sat, 03 Oct 2009 14:01:47 GMT

DES Algoritması İle Şifreleme Yapmak

Wed, 30 Sep 2009 19:25:14 GMT

WindowsFormsApplicationBase Sınıfı(*)

Wed, 30 Sep 2009 10:00:23 GMT

Bu makalede kısaca sözü edilen Microsoft.VisualBasic.ApplicationServices’deki WindowsFormsApplicationBase sınıfından yararlanarak C# uygulamasının başlangıç ve açılış formuyla ilgili bazı işlemleri kolayca yapmak mümkündür. Bu sınıf daha çok Visual Basic programcıları tarafından kullanılan bir sınıftır.

Gelin Suç İşleyip C# Uygulamamıza Excel Desteğini Verelim(*)

Thu, 17 Sep 2009 22:35:19 GMT

C++ 1. Ders - Derleyici Seçmek ve Kurmak

Thu, 06 Aug 2009 02:47:23 GMT

Görsel Dersler Hazırlamaya Başladım..

Wed, 05 Aug 2009 09:18:49 GMT

ASP.NET'te Cookie'ler(*)

Tue, 04 Aug 2009 19:26:10 GMT

C# Uygulamalarında Thread'ler(*)

Wed, 29 Jul 2009 08:50:45 GMT

Delphi : 5. Ders; Class'lar Hakkında Önbilgi

Mon, 27 Jul 2009 19:04:23 GMT

Konsol Uygulamasında Form Hazırlamak

Mon, 20 Jul 2009 21:10:44 GMT

Delphi : 4. Ders; VCL Form Application

Sat, 18 Jul 2009 18:53:37 GMT

Visual Basic 7. Ders : Temel Veritabanı İşlemleri

Wed, 08 Jul 2009 07:24:05 GMT

C#'a Başlangıç Kitabının Genişletilmiş 2. Edisyonu Hazır

Tue, 07 Jul 2009 20:29:31 GMT

Bildiğiniz gibi C# ve programcılığa henüz başlayanlar için şimdiye kadar toplam 7 makale hazırlayıp burada yayınladım. Sonra bu makaleleri bir PFD'de bir araya getirdim. Aradan geçen 6 aylık sürede gelen talepler doğrultusunda PDF'yi elden geçirip eklemeler yaptım. Bu PDF'nin yeni halini buradan indirebilirsiniz. Bu PDF'nin önsözü aşağıdadır.

Önsöz

Son yazdığım C# kitabımda başlangıç düzeyi konuların ağırlığını azaltmayı tercih ettiğim için C# konusunda henüz yolun başında olanlar zorluk çekmesin diye birkaç makale hazırlayıp kişisel sitemde yayınladım. Sonra bu makaleleri elden geçirip e-book haline getirdim. E-book’larda sayfa sınırlaması olmadığı için metni az sayfaya sığdırma gibi bir kaygım olmadı. Başka bir deyişle bu e-book’u yakın zamanda yayınlanan C# 3.0 kitabıma yardımcı veya hazırlayıcı bir kitap olarak değerlendirmek mümkündür.

Bu e-book’u inceleyenlerin fark edeceklerini sandığım bir diğer konu ise C# gibi bir programlama dilinin nasıl kolay anlatıldığını görmeleri olacaktır. Başka bir deyişle bu metin için rahatlıkla “dünyanın e kolay okunan C# kitabı” denilebilir. Yıllardır Memik Yanık’ı hep başlangıç düzeyi kitaplar yazmakla suçlayanlar bakalım bu e-book’u gördüklerinde neler söyleyecekler?

Yıllardır kendisini bilen bilmeyen birçok kişi Memik Yanık’ı çeviri yapmakla suçluyor. Memik Yanık’ın İngilizcesinin çeviri yapmaya yetmediği gerçeğini bir tarafa bırakalım ve şu soruyu sorayım: Madem Memik Yanık Türkçeye bu kadar hakim ve yazdıkları kolay okunuyor hangi akla hizmet yabancı bir yazarın kitabında çeviri yapar? Hem Memik Yanık İngilizceyi anadili gibi bilse bile hangi mantıkla kendine özel cümle kurmak yerine gidip başka bir yazarın cümlelerini alır?

Bu e-book’ta kenar boşlukları normal basılı kitaplara göre daha azdır, fontu ise daha büyüktür. Dolayısıyla bu metni normal kitap olarak değerlendirmek istemiş olsaydım sayfa sayısı aşağı yukarı aynı olurdu. E-book’un sonunda C# 3.0 kitabım hakkında yazdığım bir yazı ve C# 3.0 kitabımdan alınma bir bölüm bulunmaktadır.

2. Edisyon İçin Ek

Bu PDF’yi ilk yayınladığım günden bu yana aradan geçen 6 aylık süre içinde bana gelen talepler doğrultusunda bu e-book’a veritabanı işlemleri hakkında bilgi içeren bir bölüm eklemeye karar verdim. Bu amaçla oturup Temel Veritabanı İşlemleri adlı bir bölüm hazırlayıp PDF’ye ekledim ve bazı küçük değişiklikler yaptım. Bu hali ile bu E-Book programcılığa C# ile başlayanlar için daha işlevsel olmaya başladı.

Assembly'deki Gömülü Kaynakları Okumak

Tue, 07 Jul 2009 08:32:04 GMT