4'yi yasal tuttum.Çünkü tersten yazdırmak isteyen adam özellikle bir sayı girer ama yine de ters için 'r'(reverse) düz için 'n'(normal) karakteriyle kontrol edebilirim.

assert leri daha tam öğrenemedim ama öğreneceğim.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

github için bir ipucu vereyim. Mesela birden fazla sorunu çözmemiz lazım veya farklı kısımlara kod yazmamız lazım, bir sorunu gideren yamayı hazırladınız bitti. Bu yamayı push etmeyin, sadece commit edip bırakın. Daha sonra 2.,3. ve daha sonraki sorunları çözün ve toptan push edin. Böylece pull requestlerde de kolaylık olur, eklediğiniz commit mesajlarını ayırt etmesi de daha kolay olur. Mesela deneme.d dosyasında bir sorunu çözdünüz. commit -m "yazdırma sorunu çözüldü" gibi o dosyada yaptığınız değişikliği commit edin, daha sonra diğerlerini. Çok uzattım ama kısacası her commit işleminden sonra push etmek zorunda değilsiniz :)

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (acehreli):

Pull request gönderdiktek sonra diğer commitler de bu pull requestte görünür. Ama dediğiniz gibi küçük parçalarda commit edildiği zaman pull requestlerde de daha rahat çalışılıyor.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Bu düzen işlemeye başladı yani... :)

İlk yamayı bir çalışma zamanı hatasını giderdiği için ve ilk request olduğu için kabul ettim; ama bundan sonrası için dikkat etmemiz gereken noktaları hatırlatmak istiyorum:

(1) Yamaları olabildiğince küçük tutmaya çalışalım: çalışma zamanı hatasını gideren yama yalnızca onunla ilgili olsun

Git bu işi çok kolaylaştırıyor. Git'i kullanan arkadaşlara yeni soru: Yamaları küçük tutmak için şu adımlar uygun mu?

'1) yerel olarak dallayın
2) çalışma hatasını o dalda giderin
3) bu dala commit edin
4) github'daki kendi deponuza push edin
5) github'daki deponuzdan pull request gönderin

Sonra başka değişiklikler için başka dala geçin.'

(2) Kodlama standardımıza uymuyoruz; uyalım! :) Özellikle şu maddelerde anlaşamıyoruz:

http://ddili.org/wiki/index.php?title=Kodlama_Standard%C4%B1#Bo.C5.9Fluklar

http://ddili.org/wiki/index.php?title=Kodlama_Standard%C4%B1#Ayra.C3.A7lar

http://ddili.org/wiki/index.php?title=Kodlama_Standard%C4%B1#Birim_Testler

Eğer o standartlarda uygunsuz bulduğunuz maddeler varsa belirtin; yol yakınken düzeltelim.

Birim testleri çok önemli. Örneğin şu satırda açık bir hata var:

return "<bo dir=\"ltr\">"~text~"</bdo>\n"

Böyle hataların hepsini insanların yakalaması çok zordur. Bugün düzeltiriz, koda yarın dokunduğumuzda başka tarafından patlar...

Ayrıca birim testlerinin kodu denetlemelerini bekliyoruz. Yani ekrana yazılan metine bakarak karar veremeyiz. Aslında birim testlerini kendim yazacağımı söylemiştim ama günümüzde birim testi olmayan program artık kabul edilmemeli. Bence her programcı öncelikle birim testlerini düşünerek programlamalı.

Örneğin yukarıdaki kodu yazmadan önce şöyle bir test yazılmış olması çok yararlı olurdu:

   assert(help.bidirectional(42, "merhaba") ==
          "<bdo dir=\"ltr\">merhaba</bdo>\n");

(Not: 42 yasal bir değer mi? ;))

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (Kadir Can):

Bu gibi durumlarda enum'lar daha iyi oluyor: hata yapması daha güç ve ne anlama geldiği açık oluyor:

enum Yön { sol, sağ };

D'nin C ve C++'da bulunmayan güzel bir olanağı 'final switch'... Bütün değerleri kullanılan enum'larda çok yararlı oluyor: hiçbir değerin unutulmadığını garanti ediyor; o yüzden default kullanmak da yasak:

import std.stdio;

enum Yön { sol, sağ };

void foo(Yön yön)
{
   final switch (yön) {
   case Yön.sol:
       writeln("Sola gitmemi istediniz");
       break;

   case Yön.sağ:
       writeln("Sağa gitmemi istediniz");
       break;
   }
}

void main()
{
   foo(Yön.sol);
}

Alıntı:

Neden daha önce sormadın! :) Yükte hafif, pahada ağır, son derece yararlı bir olanak. Öğrenmesi şu kadar basit: "assert'e verilen mantıksal ifadenin doğru çıkmasını bekliyoruz." Öyle olmazsa bir hata var demek. Burada anlatacağım. :)

Kendisine verilen string'leri aralarında tire karakteri ile birleştiren bir işlev:

import std.stdio;

string tireyleBirleştir(string[] parçalar ...)
{
   string sonuç = parçalar[0];

   foreach (parça; parçalar[1 .. $]) {
       sonuç ~= '-' ~ parça;
   }

   return sonuç;
}

void main()
{
   writeln(tireyleBirleştir("abc", "xyz"));
}

O programı çalıştırabilir ve ekrandaki çıktısına bakabiliriz. Ama bu çok yetersiz olur çünkü program değiştikçe çıktı bozulmuş olabilir; örneğin "abc-xyz-" haline gelmiş olabilir. assert, bu beklentimizi denetleyebilir. Örneğin bir unittest bloğuna şöyle yazabiliriz:

unittest
{
   assert(tireyleBirleştir("abc", "xyz") == "abc-xyz");
   assert(tireyleBirleştir("abc", "xyz", "123") == "abc-xyz-123");
}

Çok kolay: yaptığımız tek şey, işlevin döndürdüğü değerin neye eşit olması gerektiğini düşündüğümüzü belirtmek oldu ('==' işleci ile).

Neler olabileceğine bakalım:

1. Daha sonradan bir programcı gelip parçalar[0]'a neden özel olarak davranıldığını anlamadan işlevi şöyle değiştirebilir:

string tireyleBirleştir(string[] parçalar ...)
{
   string sonuç;

   foreach (parça; parçalar) {
       sonuç ~= '-' ~ parça;
   }

   return sonuç;
}

Ve yaptığı yanlışı birim testler tarafından hemen yakalanır:

'core.exception.AssertError@deneme(28464): unittest failure'

2. Veya başka bir programcı gelip tireyleBirleştir()'in gereksizce yazıldığını düşünüp onun std.array.join çağrılarak da yazılabileceğini düşünebilir:

import std.array;
// ...
string tireyleBirleştir(string[] parçalar ...)
{
   return join(parçalar, "-");
}

Ve tamamen emin bir şekilde olay yerinden ayrılır. :) Çünkü birim testleri geçerler. Yani işlev istendiği gibi işlemiş ve iki örnek çağrı için doğru sonucu üretmiştir.

Öte yandan, birim testi olmayan koda dokunulamaz ve sonuçta kod çürür (code rot).

İşte assert bu kadar basit ve bu kadar kullanışlıdır. :) Programın başka yerlerine de yazılabilir ama şimdilik bu kadarı yeterli.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Ben de öyle anlıyorum ama 'pull request'in kabul edilmesini beklerken bir yandan da çalışmaya devam etmek istendiğinde kişinin github'daki kendi deposuna 'push' etmesi gerekiyor, değil mi?

Küçük parçalarla uğraşmak daha kolay olduğu için bana daha kolay geliyor.

Ali

Not: Aslında ev bilgisayarlarımız arasında bağlantı kurmuş olsak github'daki kişisel depolarımıza da gerek yok. Ama bunun sorunlarıyla uğraşmak yerine github'a teşekkür ediyor ve onlardan yararlanıyoruz. :)

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Ali bey;
assert anlatımı için teşekkür ederim.Yarın unittest kısmını assertlerle dolduracağım.

enumlar güzel.İlk defa kullanacağım.İnşallah hatasız olur.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

İkinci pull request atıldı.

assert ve enum olayını hallettim.

Kod assert'leri sorunsuz geçiyor.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Teşekkürler Ali bey,

Şu kodlama düzenine dikkat edeceğim.Kod çok güzel görünüyor. :D

Sizin commitlediğiniz kodu çekemedim.Nasıl yapabilirim?

Bİr şey sormak istiyorum.Şu anda kodun durumu sizce nasıl?İyiye gidiyor mu?

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Ben de onun üzerine bir kod temizliği yaptım:

• boşluklar

• küme parantezleri

• enum türünün ismini büyük harfle başlattım

• satır uzunluklarını 80'le sınırladım

• vs.

Soru: benim değişikliklerimden sizin haberiniz oluyor, değil mi? Ayrıca bilgi vermeme gerek yok herhalde.

Aynı şekilde sizin de pull request'leri burada bildirmenize gerek olmuyor; bana e-mail olarak geliyor.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]