Selamlar bu yaptığım yeni bir seri. En son nodejs ile backend serisi yapıyorduk oraya @DarkS0LDIER js serisini yapıp içerisine bir şeyler ekliyordu. Süreçte boş durmayıp o seriye devam etmeden önce temiz kod nasıl yazılır serisini başlayıp bitirelim. Bu seride Robert C.Martin'den ve nice birçok isimden faydalanacağız.
Bu seriye başlamak için gereksinimler:
- Temel düzeyde oop programlama bilgisi
Bilmiyorum ne yapacağım?
JavaScript öğrenebilirsin bu serimizden:
JavaScripti sevmedim başka bir şey yok mu? var:
Dart dilini öğrenebilirsin! Bu serimizden:
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #1
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #2
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #3
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #4
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #5
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #6
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #7
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #8
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #9
Bunları öğrenmiş olursun. Bunları da beğenmediysen bu konumuzu inceleyebilirsin:
Resim0 - Python
Neden Python
"Ya zaten öğrenmek için bunu seçtik, neden bir daha neden seçmemiz gerektiğimizi yazıyorsun ki? dediğinizi duyar
gibiyim. Ama anlatmadan geçilmemesi gereken bir nokta bu.
İlk olarak son derece hamarattır. Bir çok alanda çalışabilir ve oldukça hızlıdır.
Ayrıca özgür / açık kaynak kodludur.
Onun sevilen bir diğer tarafı da öğrenmesi kolay!
Hadi yavaştan devam edelim...
Python Tarihi
Geliştirilmeye 1990 yılında Guido van...
Devam edelim.
İÇERİK:
Merhaba bu konuda temiz kod yazmayı anlatacağım. Kod yazarken kodun kalitesini ölçmek için buDaNe?/dakika formülüyle hesaplayabiliyoruz. Bu öylesine okuyup geçebileceğiniz bir konu değil. Bunu tamamen okuyup anlamanız için baya bir kod okumanız gerekecek. Çok fazla kod okumanız gerekecek. Tabi buna değecektir. Üç kısma ayırıyoruz aslında prensipler patternler ve pratikler. Konunun her kısmına özen gösterirseniz temiz kod yazmakla ilgili farklı farklı dolu kaynak aramanıza gerek kalmaz. Kodlamada soyutlama tarafı gittikçe artıyor ilerde de artacak gibi domain spesifik diller daha yüksek seviyede diller olacak. Yapay zeka yazılımcıları bitirdiciler için kötü haber şu ki kodlama bitmiyor yani bu noktadan sonra hep kötü kod ve iyi kod zaten olacak. Hızlıca markete sürülmeye çalışılıp sonradan özellik ekleye ekleye artık bir noktadan sonra yönetilemeyen ve şirketi bile batıran öyle kodlar var ki. Genelde bunlar iyi iş çıkartmak için doğru düzgün ayarlanmayan deadlinelar yüzünden oluyor. Berbat yazılan projeyi kurtarmak için yeni yeni adamlar ekliyorlar daha sonra bu gelenler projenin yapısı atılırken bulunmadığı için daha sonra onlar da bu karmaşıklık içinde kalıyorlar sonra onların da verimliliğini artırmak için başka başka şeyler ekleniyor ve aslında verimlilik sıfıra iniyor. Daha sonra artık ekip diyor ki bu kod baseiyle devam edemeyeceğiz yeniden yazalım. Managementın da umrunda değil işine gelmiyor zaten ama mecbur kalıyorlar. Bjarne Stroustrup'a göre kodlar basit ve efektif olmalı. Sözleri güzel bir şiir gibi olmalıymış. Adam diyor ki çok fazla şeyi yapmayı amaçlayan kod parçaları kötü kodlardır. Özetle kod parçasının hedefi basit anlaşılabilir olmalı. Kuduz köpek gibi her yere saldıran her şeyi yapmaya çalışan kod parçaları olmamalı. Grady Booch da aynı şekilde düşünüyor. Ron Jeffries de benzer şekilde. O da en çok kodlarında tekrarlama olup olmadığına dikkat ediyordu çünkü olmaması gerek. Onun dışında ufak soyutlamalar olması gerektiğinden bahsetmişti. Bu arada programlama dilinin de bununla alakası yok. Yazan kişi dilin temiz gözükmesine etki ediyor. Dilin syntaxindan bağımsız konuşmak lazım bu konuyu. Kod yazan herkes kendisinin bir yazar olduğunu unutmamalı. Yani kendine yazma sadece. Çünkü öyle bir noktaya gelir ki sadece sen anlarsın bu da projenin geleceği için iyi olmaz.
İsimler her şeydir. Değikenlere fonksiyonlarımıza argümanlarımıza sınıflarımıza packagelara her şeye isim veriyoruz. İsim verirken niyetimiz çok önemli. İsimler niyetlere göredir. İyi isim seçmek zaman alıyor örneğin ben nick seçemiyorum sürekli değiştiriyorum kötü kod yazdığım buradan belli oluyor. İsimleriniz soruları cevaplamalı.
int d; // geçen gün sayısı
d hiçbir anlam ifade etmiyor. Doğru düzgün isim koyun.
int gecenGunSayisi;
tabi ingilizce yazın ben anlaşılsın diye böyle yapıyorum. Türkçeyi salın. Türkçemiz daha iyi ama İngilizce yazmak şart. Bu tarz anlaşılabilir isimler seçmek kodun okunabilirliğini çokça artırıyor.
theList: Hangi liste olduğu belli değil.
list1: Listenin neyi temsil ettiği belli değil.
x: Hücreyi temsil ediyor, ancak ismi anlamsız.
x[0] == 4: 0. indeksteki değerin 4 olup olmadığını kontrol ediyor, ancak bu değerin ne anlama geldiği belli değil.
Doğru düzgün isimlendirilse böyle olmazdı.
Bu daha anlaşılır mesela.
gameBoard: Listenin bir oyun tahtasını temsil ettiği belli.
flaggedCells: Listenin işaretlenmiş hücreleri tuttuğu belli.
cell: Hücreyi temsil ediyor, ismi anlamlı.
STATUS_INDEX ve FLAGGED ile kodun ne yaptığı daha net anlaşılıyor.
Şimdi biraz daha anlaşılır nasıl olurdu:
public List<Cell> getFlaggedCells(){
List<Cell> flaggedCells = new ArrayList<Cell>();
for (Cell cell : gameBoard)
if(cell.isFlagged())
flaggedCells.add(cell);
return flaggedCells;
}
bir gameBoard (oyun tahtası) üzerindeki hücreleri (Cell) kontrol ediyor. Eğer bir hücre "işaretlenmişse" (isFlagged() metodu true dönerse), bu hücreyi flaggedCells listesine ekliyor. Sonunda, işaretlenmiş hücrelerin listesini döndürüyor. Cell adında bir sınıf kullanılıyor int yerine. isFlagged() metodu, hücrenin işaretlenip işaretlenmediğini kontrol ediyor böyle daha da iyi.
İsimlendirme yaparken fwnin kendisinde kullanılabilecek olan yani platformun kendisinde kullanılabilecek olan isimlerden kaçınmamız lazım. hp, aix, sco gibi isimlendirmelerden kaçının misal ortama göre. Eğer bir şey List değilse ona falancaList şeklinde isimlendirme yapmayın. Gerçekten List ise o şekilde isimlendirin. O sebeple hesaplarList eğer hesapların bulunduğu gerçekten bir List değilse böyle isimlendirmek yerine ona hesaplarGroup falan yazsanız daha iyi. Çok da uzun yazmayın isimleri cümle gibi olmamalı.
Bir de örneğin
aktifKullanicilariGetir();
aktifKullanicilar();
aktifKullaniciBilgileri();
yukarıdaki üç isim de bir projede var diyelim bu metodlar var daha sonra okuyan adam için berbat. O sebeple isimler ayrıştırılabilir olmalı.
Seslendirilebilir olmalı. Ne alaka? şöyle:
zatenksyajksa;
modynakjasajk;
pszaqintj;
örneğin bu isimleri seslendirmek vs. zor iletişim sıkıntısı yaşatır. Bunlardan kaçının.
Aranılabilir isimler kullanın. Örneğin int e diye isim verirseniz e yi arattığınızda sonradan bulmak istediğinizde zor bulursunuz her yerde geçiyor. Bu gibi tek harfli değişkenler oluşturacaksanız lokal değişken olarak kullanın kısa metodların içinde. Ancak öyle iş görür.
bkz:
yerine
daha iyidir.
Örnek:
yerine
mental mappingten kaçınmak da şöyle yani kendi kafanın içinde r'nin url anlamına geldiğini bilip değişkene r ismini verme. Daha iyi özetlenemezdi bence. Bir de başka bir konu olarak classlara yani sınıflara isim verirken bildiğimiz Türkçedeki "isim" olduğundan emin olalım ve fiilleri class ismi olarak vermeyelim. Musteri ornegin iyi bir sınıf ismi. Hesap, Account, Customer vb. isimler. metod isimlerine gelecek olursak işte burada fiilleri kullanın. odemeSil(); mesela. postPayment, deletePage, save falan gibi olmalı.
static factory metodların da kullanımı önemli. Örneğin
yazmak
yazmaktan iyidir genelde.
Zekice isimler falan vermeyin bir yerlere gönderme yaparak. Örneğin benimle ilgili bir fonksiyon yazıyorsanız
KırPidesi();
diye fonksiyon ismi verirseniz çoğu kişi anlamaz. Anlayanların bir kısmı güler bir kısmı da sizi ömür boyu unutmayacağınız derecede rezil eder ama haklıdır. @Znéa
değişken veya fonksiyon isimlerini seçerken bağlamdan kopuk, anlamsız kelimeler kullanmak yerine kodun ne yaptığı hakkında daha fazla bilgi veren isimler kullanmamız lazım dedik. Eğer bir değişken fonksiyon veya sınıf tek başına anlam ifade etmiyorsa onu daha açık hale getirecek CONTEXT eklemeliyiz.
Gereksiz CONTEXT de eklemeyin abartmaya gerek yok. örnek:
Konu bu kadardır bölüm 4 bitti.
Bir sonraki konuda görüşmek üzere.
Bu seriye başlamak için gereksinimler:
- Temel düzeyde oop programlama bilgisi
Bilmiyorum ne yapacağım?
JavaScript öğrenebilirsin bu serimizden:
Sıfırdan İleri Seviye Javascript #1 Veri Türleri
Sıfırdan İleriye Javascript #2 Booleanlar, Operatörler ve Tarih
Sıfırdan İleriye Javascript #3 Koşullar
Sıfırdan İleriye Javascript #4 Örnek Alıştırmalar
Sıfırdan İleriye Javascript #5 Diziler
Sıfırdan İleriye Javascript #6 Döngüler
Sıfırdan İleriye Javascript #7 Fonksiyonlar
Sıfırdan İleriye Javascript #8 4-7 Konularının Örnekleri
Sıfırdan İleriye Javascript #9 Scope Kavramı ve Objeler
Sıfırdan İleriye Javascript #10 Yüksek Dereceli Fonksiyonlar
Sıfırdan İleriye Javascript #11 Set ve Map Metodları
Sıfırdan İleriye Javascript #12 Örnekler
Sıfırdan İleriye Javascript #13 Spreading ve Destructuring
Sıfırdan İleriye Javascript #14 Konsol Metodları
Sıfırdan İleriye Javascript #15 Error Handling
Sıfırdan İleriye Javascript #16 Class (Sınıflar)
JavaScripti sevmedim başka bir şey yok mu? var:
Dart dilini öğrenebilirsin! Bu serimizden:
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #1
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #2
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #3
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #4
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #5
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #6
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #7
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #8
0'dan İleri Seviyeye Mobil Uygulama Geliştirme Eğitimi Veriyorum #9
Bunları öğrenmiş olursun. Bunları da beğenmediysen bu konumuzu inceleyebilirsin:
Resim0 - Python
Neden Python
"Ya zaten öğrenmek için bunu seçtik, neden bir daha neden seçmemiz gerektiğimizi yazıyorsun ki? dediğinizi duyar
gibiyim. Ama anlatmadan geçilmemesi gereken bir nokta bu.
İlk olarak son derece hamarattır. Bir çok alanda çalışabilir ve oldukça hızlıdır.
Ayrıca özgür / açık kaynak kodludur.
Onun sevilen bir diğer tarafı da öğrenmesi kolay!
Hadi yavaştan devam edelim...
Python Tarihi
Geliştirilmeye 1990 yılında Guido van...
Devam edelim.
İÇERİK:
| BÖLÜM 1: TEMİZ KOD kötü kod, yığın kodun zararı, sektörde bilgi sahibi kişilerin görüşleri, yazar olduğunu anlamak | BÖLÜM 2: ANLAMLI İSİMLER giriş, bilinçli yapılan isimlendirmeler, anlamlı ayrımlar, pronounce edilebilen isimler, aranabilir tahmin edilebilir isimler, encodingten kaçmak, mental mapping hakkında, sınıf isimleri, fonksiyon isimleri, contextten konuşalım | BÖLÜM 3: FONKSİYONLAR tek şey, soyutlama hakkında, stepdown kuralı, switchler hakkında, doğru düzgün isimler, argümanlar hakkında, query separation, try catchler hakkında, kendini tekrar etme | BÖLÜM 4: YORUMLAR kendini açıklamak, güzel yorumlar, kötü yorumlar |
| BÖLÜM 5: FORMATLAMA formatın amacı, vertical formatting, horizontal formatting | BÖLÜM 6: NESNELER, YAPILAR data abstraction, Demeter Yasası | BÖLÜM 7: ERROR HANDLING exceptionları return yerine kullanmak, try catch finally yazmak, kontrol edilmemiş exceptionlar, context hakkında, null döndürmemek, null geçmemek | BÖLÜM 8: SINIRLAR 3.taraf kodlar hakkında, sınırları keşfetmek |
| BÖLÜM 9: UNIT TESTLER TDD yasaları, temiz testler, F.I.R.S.T. | BÖLÜM 10: SINIFLAR sınıfları organize etmek, | BÖLÜM 11: SİSTEMLER şehir oluşturmak, ayıklama, scale etme, karar vermek | BÖLÜM 12: TEKRAR ETMEMEK minimal sınıflar ve metodlar, tekrar etmeme, design rulelar hakkında |
| BÖLÜM 13: CONCURRENCY bazı prensipler, kütüphaneni bilmek, senkronize metodlar hakkında | BÖLÜM 14: İYİLEŞTİRME | BÖLÜM 15: JUnit INTERNALS ek şeyler | BÖLÜM 16: EK KISIM |
| BÖLÜM 17: DİĞERLERİ yorumlar, çevre, argümanlar, fonksiyonlar, genel bazı şeyler, algoritmayı anlamak, uzun import listelerinden kurtulma, constantlar vs enumlar, isim seçmeceler, testler | BÖLÜM 18: İLERİYE client server ilişkisi, pathler, deadlock, multithreaded kodu test etmece, bazı sağlam örnekler | BÖLÜM 19: ORG.JFREE.DATE.SERIALDATE | BÖLÜM 20: SON Temiz kod serisinin özetleri ve Îmam-ı Gazzâlî'den sana öğütler |
BÖLÜM 1: TEMİZ KOD
Merhaba bu konuda temiz kod yazmayı anlatacağım. Kod yazarken kodun kalitesini ölçmek için buDaNe?/dakika formülüyle hesaplayabiliyoruz. Bu öylesine okuyup geçebileceğiniz bir konu değil. Bunu tamamen okuyup anlamanız için baya bir kod okumanız gerekecek. Çok fazla kod okumanız gerekecek. Tabi buna değecektir. Üç kısma ayırıyoruz aslında prensipler patternler ve pratikler. Konunun her kısmına özen gösterirseniz temiz kod yazmakla ilgili farklı farklı dolu kaynak aramanıza gerek kalmaz. Kodlamada soyutlama tarafı gittikçe artıyor ilerde de artacak gibi domain spesifik diller daha yüksek seviyede diller olacak. Yapay zeka yazılımcıları bitirdiciler için kötü haber şu ki kodlama bitmiyor yani bu noktadan sonra hep kötü kod ve iyi kod zaten olacak. Hızlıca markete sürülmeye çalışılıp sonradan özellik ekleye ekleye artık bir noktadan sonra yönetilemeyen ve şirketi bile batıran öyle kodlar var ki. Genelde bunlar iyi iş çıkartmak için doğru düzgün ayarlanmayan deadlinelar yüzünden oluyor. Berbat yazılan projeyi kurtarmak için yeni yeni adamlar ekliyorlar daha sonra bu gelenler projenin yapısı atılırken bulunmadığı için daha sonra onlar da bu karmaşıklık içinde kalıyorlar sonra onların da verimliliğini artırmak için başka başka şeyler ekleniyor ve aslında verimlilik sıfıra iniyor. Daha sonra artık ekip diyor ki bu kod baseiyle devam edemeyeceğiz yeniden yazalım. Managementın da umrunda değil işine gelmiyor zaten ama mecbur kalıyorlar. Bjarne Stroustrup'a göre kodlar basit ve efektif olmalı. Sözleri güzel bir şiir gibi olmalıymış. Adam diyor ki çok fazla şeyi yapmayı amaçlayan kod parçaları kötü kodlardır. Özetle kod parçasının hedefi basit anlaşılabilir olmalı. Kuduz köpek gibi her yere saldıran her şeyi yapmaya çalışan kod parçaları olmamalı. Grady Booch da aynı şekilde düşünüyor. Ron Jeffries de benzer şekilde. O da en çok kodlarında tekrarlama olup olmadığına dikkat ediyordu çünkü olmaması gerek. Onun dışında ufak soyutlamalar olması gerektiğinden bahsetmişti. Bu arada programlama dilinin de bununla alakası yok. Yazan kişi dilin temiz gözükmesine etki ediyor. Dilin syntaxindan bağımsız konuşmak lazım bu konuyu. Kod yazan herkes kendisinin bir yazar olduğunu unutmamalı. Yani kendine yazma sadece. Çünkü öyle bir noktaya gelir ki sadece sen anlarsın bu da projenin geleceği için iyi olmaz.
BÖLÜM 2: ANLAMLI İSİMLER
İsimler her şeydir. Değikenlere fonksiyonlarımıza argümanlarımıza sınıflarımıza packagelara her şeye isim veriyoruz. İsim verirken niyetimiz çok önemli. İsimler niyetlere göredir. İyi isim seçmek zaman alıyor örneğin ben nick seçemiyorum sürekli değiştiriyorum kötü kod yazdığım buradan belli oluyor. İsimleriniz soruları cevaplamalı.
int d; // geçen gün sayısı
d hiçbir anlam ifade etmiyor. Doğru düzgün isim koyun.
int gecenGunSayisi;
tabi ingilizce yazın ben anlaşılsın diye böyle yapıyorum. Türkçeyi salın. Türkçemiz daha iyi ama İngilizce yazmak şart. Bu tarz anlaşılabilir isimler seçmek kodun okunabilirliğini çokça artırıyor.
Kod:
public List<int[]> getThem() {
List<int[]> list1= new ArrayList<int[]>();
for (int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
}theList: Hangi liste olduğu belli değil.
list1: Listenin neyi temsil ettiği belli değil.
x: Hücreyi temsil ediyor, ancak ismi anlamsız.
x[0] == 4: 0. indeksteki değerin 4 olup olmadığını kontrol ediyor, ancak bu değerin ne anlama geldiği belli değil.
Doğru düzgün isimlendirilse böyle olmazdı.
Kod:
public List<int[]> getFlaggedCells() {
List<int[]> flaggedCells = new ArrayList<int[]>();
for (int[] cell : gameBoard)
if (cell[STATUS_INDEX] == FLAGGED)
flaggedCells.add(cell);
return flaggedCells;
}Bu daha anlaşılır mesela.
gameBoard: Listenin bir oyun tahtasını temsil ettiği belli.
flaggedCells: Listenin işaretlenmiş hücreleri tuttuğu belli.
cell: Hücreyi temsil ediyor, ismi anlamlı.
STATUS_INDEX ve FLAGGED ile kodun ne yaptığı daha net anlaşılıyor.
Şimdi biraz daha anlaşılır nasıl olurdu:
public List<Cell> getFlaggedCells(){
List<Cell> flaggedCells = new ArrayList<Cell>();
for (Cell cell : gameBoard)
if(cell.isFlagged())
flaggedCells.add(cell);
return flaggedCells;
}
bir gameBoard (oyun tahtası) üzerindeki hücreleri (Cell) kontrol ediyor. Eğer bir hücre "işaretlenmişse" (isFlagged() metodu true dönerse), bu hücreyi flaggedCells listesine ekliyor. Sonunda, işaretlenmiş hücrelerin listesini döndürüyor. Cell adında bir sınıf kullanılıyor int yerine. isFlagged() metodu, hücrenin işaretlenip işaretlenmediğini kontrol ediyor böyle daha da iyi.
İsimlendirme yaparken fwnin kendisinde kullanılabilecek olan yani platformun kendisinde kullanılabilecek olan isimlerden kaçınmamız lazım. hp, aix, sco gibi isimlendirmelerden kaçının misal ortama göre. Eğer bir şey List değilse ona falancaList şeklinde isimlendirme yapmayın. Gerçekten List ise o şekilde isimlendirin. O sebeple hesaplarList eğer hesapların bulunduğu gerçekten bir List değilse böyle isimlendirmek yerine ona hesaplarGroup falan yazsanız daha iyi. Çok da uzun yazmayın isimleri cümle gibi olmamalı.
Bir de örneğin
aktifKullanicilariGetir();
aktifKullanicilar();
aktifKullaniciBilgileri();
yukarıdaki üç isim de bir projede var diyelim bu metodlar var daha sonra okuyan adam için berbat. O sebeple isimler ayrıştırılabilir olmalı.
Seslendirilebilir olmalı. Ne alaka? şöyle:
zatenksyajksa;
modynakjasajk;
pszaqintj;
örneğin bu isimleri seslendirmek vs. zor iletişim sıkıntısı yaşatır. Bunlardan kaçının.
Aranılabilir isimler kullanın. Örneğin int e diye isim verirseniz e yi arattığınızda sonradan bulmak istediğinizde zor bulursunuz her yerde geçiyor. Bu gibi tek harfli değişkenler oluşturacaksanız lokal değişken olarak kullanın kısa metodların içinde. Ancak öyle iş görür.
bkz:
Kod:
for (int j=0; j<34; j++){
s += (t[j]*4)/5;
}yerine
Kod:
int totalEffectiveStudyTime = 0; // Toplam etkili çalışma süresi
int[] dailyStudyHours = new int[34]; // Günlük çalışma saatleri
for (int day = 0; day < 34; day++) {
totalEffectiveStudyTime += (dailyStudyHours[day] * 4) / 5;
}daha iyidir.
Örnek:
Kod:
String userType = "A"; // A: Admin, M: Moderator, U: User
if (userType == "A") {
grantAdminAccess();
}yerine
Kod:
enum UserType { admin, moderator, user }
UserType userType = UserType.admin;
if (userType == UserType.admin) {
grantAdminAccess();
}mental mappingten kaçınmak da şöyle yani kendi kafanın içinde r'nin url anlamına geldiğini bilip değişkene r ismini verme. Daha iyi özetlenemezdi bence. Bir de başka bir konu olarak classlara yani sınıflara isim verirken bildiğimiz Türkçedeki "isim" olduğundan emin olalım ve fiilleri class ismi olarak vermeyelim. Musteri ornegin iyi bir sınıf ismi. Hesap, Account, Customer vb. isimler. metod isimlerine gelecek olursak işte burada fiilleri kullanın. odemeSil(); mesela. postPayment, deletePage, save falan gibi olmalı.
static factory metodların da kullanımı önemli. Örneğin
Kod:
Complex fulcrumPoint = Complex.FromRealNumber(23.0);
Kod:
Complex fulcrumPoint = new Complex(23.0);Zekice isimler falan vermeyin bir yerlere gönderme yaparak. Örneğin benimle ilgili bir fonksiyon yazıyorsanız
KırPidesi();
diye fonksiyon ismi verirseniz çoğu kişi anlamaz. Anlayanların bir kısmı güler bir kısmı da sizi ömür boyu unutmayacağınız derecede rezil eder ama haklıdır. @Znéa
değişken veya fonksiyon isimlerini seçerken bağlamdan kopuk, anlamsız kelimeler kullanmak yerine kodun ne yaptığı hakkında daha fazla bilgi veren isimler kullanmamız lazım dedik. Eğer bir değişken fonksiyon veya sınıf tek başına anlam ifade etmiyorsa onu daha açık hale getirecek CONTEXT eklemeliyiz.
Kod:
List<String> names = ["Ali", "Ayşe", "Mehmet"];
void printList() {
for (var name in names) {
print(name);
}
}
//yukarıdaki yerine aşağıdaki daha iyi
List<String> customerNames = ["Ali", "Ayşe", "Mehmet"];
void printCustomerNames() {
for (var name in customerNames) {
print(name);
}
}Gereksiz CONTEXT de eklemeyin abartmaya gerek yok. örnek:
Kod:
class ProductInfo {
String productName;
double productPrice;
ProductInfo(this.productName, this.productPrice);
}
//yerine
class Product {
String name;
double price;
Product(this.name, this.price);
}
//bunu kullanınKonu bu kadardır bölüm 4 bitti.
Bir sonraki konuda görüşmek üzere.
Seri bitti, tüm bölümlere aşağıdaki tablodan ulaşabilirsiniz;
Şuan ki ilerleme oranımız 400/ 400
Şuan ki ilerleme oranımız 400/ 400
