SlideShare a Scribd company logo
1 of 50
Download to read offline
JAVA BY
COMPARISON
SIMON HARRER, J.LENHARD, LINUS DIETZ
HAZIRLAYAN İBRAHIM KÜRCE
1-İLKEL(PRİMİTİF) BOOLEAN KARŞILAŞTIRMA
• İlkel boolean değerleri karşılaştırmalarda kullanmamak gerek
• Kodda bulunan gürültülerdir
• Anti-pattern’dir
• Okumayı zorlaştırır
2-OLUMSUZLUKTAN KAÇININ
• Her zaman pozitif olun. Çünkü anlaması daha kolaydır
• !(değil) işaretini mümkün olduğunca kullanmayın
2.OLUMSUZLUKTAN KAÇININ
• isInorganic() yerine isOrganic() kullandık. If ve else yerleri değişti
• Pozitif anlam oluşturduk
• !(Değil) ifadesini kaldırdık. If ve else yerleri değişti
• Az bir iş gibi görülebilir, proje büyüdükçe çok büyük farklar oluşturur
3.BOOLEAN İFADELERİ DİREK DÖNÜN
• Gereksiz if ifadelerini temizleyin
• Daha fazla karmaşa oluşturur
3.BOOLEAN İFADELERİ DİREK DÖNÜN
• Daha az kod satırı
• Daha az hizalama ve daha az iç-içe ifadeler
• De Morgan Kanunu’nu kullanabiliriz,
• !A && !B == !(A || B) // true
• !A || !B == !(A && B) // true
3.BOOLEAN İFADELERİ DİREK DÖNÜN
• Hatta alt parçalara bölebiliriz,
4.BOOLEAN İFADELERİ BASİTLEŞTİRİN
• Çoklu ifadelerin anlaşılması ve değiştirilmesi zordur
4.BOOLEAN İFADELERİ BASİTLEŞTİRİN
• Gerekirse ekstra metodlar ekleyin
• Metodların anlamlı-güzel isimleri olsun, içeriğine bakma gereği duymayalım
5.KOŞULLU IFADELERDE NULL HATASINA DIKKAT
EDIN
• NullPointerException en çok gördüğümüz hatalardan
• İfadelerin sırasına dikkat edin
5.KOŞULLU IFADELERDE NULL HATASINA DIKKAT
EDIN
• message ve location değişkenleri null kontrolü eklendi
• İfade sırasında null kontrolü ilk sıraya alındı
• Java ve diğer dillerde artık Optional(?) ile null pointer hatası azaltılmaya çalışılıyor
6.SWITCH AKIŞINA DİKKAT EDİN
• Switch ifadesi Java gibi bazı dillerde önceden beri kötü şöhrete sahiptir
• break kullanımına dikkat etmek gerekir
6.SWITCH AKIŞINA DİKKAT EDİN
• Her case sonuna mutlaka break koyun
• Bazı durumlarda switch yerine if kullanmak ve ayrı bloklarda kodları yönetmek
doğru olur
• Burada yetkili ve yetkisiz kullanıcılar aynı yerde yönetiliyor
7.HER ZAMAN SÜSLÜ PARANTEZ{} KULLANIN
• Hizalama bazen yanıltıcı olabilir
• Hatayı ararken saatleriniz heba olmasın
7.HER ZAMAN SÜSLÜ PARANTEZ{} KULLANIN
• Derleyici süslü parantezler eklenmiş gibi kodu yorumlar. Bu da istenmeyen bir
duruma yol açar
• Her zaman daha az kod daha iyi demek değildir
• 2014 yılında Apple geliştiricisi iOS üzerinde SSL/TLS çalışırken bu hatayı yaptı ve
bu yüzden sistemlere saldırılar oldu
• Her zaman süslü parantez eklemek gerekir
• 16
8.KOD SIMETRISINI SAĞLAYIN
• Bütün koşullar ardı sıra devam ediyor
• Biraz daha büyüyünce bulmaca gibi olur, karmaşıklaşır
• Bütün koşullu ifadeler benzer bir amaca mı yönelik?
• Kod simetrisi yok
8.KOD SIMETRISINI SAĞLAYIN
• Yetkili ve yetkisiz kodu ayırmış olduk
• İkinci kısım simetri olmuş oldu
9.SIHIRLI(MAGIC) SAYILARDAN KURTULUN
• Sihirli sayı: Kod içinde bulunan bakınca anlaşılmayan, rastgele sayılar
• Hataya yol açarlar
9.SIHIRLI(MAGIC) SAYILARDAN KURTULUN
• Anlaşılır ve erişebilir değişkenler tanımlayın ve onları kullanın
• Kimse bu sayı(veya string) nedir diye düşünmek zorunda kalmaz
10.SABIT DEĞIŞKENLER YERINE ENUM TERCIH EDIN
• Sabit değişkenler çok artarsa takip edilmesi zorlaşır
• İstenilen durumlar için ayrıca farklı değerler atanma olasılığı var
• Bu seferde metod ekstra kontroller yapması gerekiyor
10.SABIT DEĞIŞKENLER YERINE ENUM TERCIH EDIN
• Enum bize ekstra güvenlik sağladı
• Fazladan kontrollere gerek kalmadı
• Derleme zamanında kontrollerin önüne geçmiş olduk
• İf-else bloklarından bile kurtulduk
11.KLASİK FOR YERİNE FOR-EACH KULLANIN
• Yeniliklere açık olun
• Index için kullanılan i değişken değeri değişebilir ve hata alınabilir
11.KLASİK FOR YERİNE FOR-EACH KULLANIN
• Konuşma diline daha yakın, for each check in checks…
• Index değişkeninden ve hata alma ihtimalinden kurtulduk
• Eski yönteme çok az ihtiyaç duymalısın
12.DÖNGÜ SIRASINDA DEĞIŞIKLIK YAPMA
• Uygulamanın çakılmasına yol açabilir
• ConcurrentModificationException hatası üretir
12.DÖNGÜ SIRASINDA DEĞIŞIKLIK YAPMA
• Iterator liste üzerinde elemanlara işaretçi gibi çalışır
• Liste üzerinde güncelleme işlemleri için tasarlanmıştır
• hasNext ile garantiye almış oluruz
SON

More Related Content

Java By Comparison

  • 1. JAVA BY COMPARISON SIMON HARRER, J.LENHARD, LINUS DIETZ HAZIRLAYAN İBRAHIM KÜRCE
  • 2.
  • 3. 1-İLKEL(PRİMİTİF) BOOLEAN KARŞILAŞTIRMA • İlkel boolean değerleri karşılaştırmalarda kullanmamak gerek • Kodda bulunan gürültülerdir • Anti-pattern’dir • Okumayı zorlaştırır
  • 4.
  • 5.
  • 6. 2-OLUMSUZLUKTAN KAÇININ • Her zaman pozitif olun. Çünkü anlaması daha kolaydır • !(değil) işaretini mümkün olduğunca kullanmayın
  • 7.
  • 8. 2.OLUMSUZLUKTAN KAÇININ • isInorganic() yerine isOrganic() kullandık. If ve else yerleri değişti • Pozitif anlam oluşturduk • !(Değil) ifadesini kaldırdık. If ve else yerleri değişti • Az bir iş gibi görülebilir, proje büyüdükçe çok büyük farklar oluşturur
  • 9.
  • 10. 3.BOOLEAN İFADELERİ DİREK DÖNÜN • Gereksiz if ifadelerini temizleyin • Daha fazla karmaşa oluşturur
  • 11.
  • 12. 3.BOOLEAN İFADELERİ DİREK DÖNÜN • Daha az kod satırı • Daha az hizalama ve daha az iç-içe ifadeler • De Morgan Kanunu’nu kullanabiliriz, • !A && !B == !(A || B) // true • !A || !B == !(A && B) // true
  • 13. 3.BOOLEAN İFADELERİ DİREK DÖNÜN • Hatta alt parçalara bölebiliriz,
  • 14.
  • 15. 4.BOOLEAN İFADELERİ BASİTLEŞTİRİN • Çoklu ifadelerin anlaşılması ve değiştirilmesi zordur
  • 16.
  • 17. 4.BOOLEAN İFADELERİ BASİTLEŞTİRİN • Gerekirse ekstra metodlar ekleyin • Metodların anlamlı-güzel isimleri olsun, içeriğine bakma gereği duymayalım
  • 18.
  • 19. 5.KOŞULLU IFADELERDE NULL HATASINA DIKKAT EDIN • NullPointerException en çok gördüğümüz hatalardan • İfadelerin sırasına dikkat edin
  • 20.
  • 21. 5.KOŞULLU IFADELERDE NULL HATASINA DIKKAT EDIN • message ve location değişkenleri null kontrolü eklendi • İfade sırasında null kontrolü ilk sıraya alındı • Java ve diğer dillerde artık Optional(?) ile null pointer hatası azaltılmaya çalışılıyor
  • 22.
  • 23. 6.SWITCH AKIŞINA DİKKAT EDİN • Switch ifadesi Java gibi bazı dillerde önceden beri kötü şöhrete sahiptir • break kullanımına dikkat etmek gerekir
  • 24.
  • 25. 6.SWITCH AKIŞINA DİKKAT EDİN • Her case sonuna mutlaka break koyun • Bazı durumlarda switch yerine if kullanmak ve ayrı bloklarda kodları yönetmek doğru olur • Burada yetkili ve yetkisiz kullanıcılar aynı yerde yönetiliyor
  • 26.
  • 27. 7.HER ZAMAN SÜSLÜ PARANTEZ{} KULLANIN • Hizalama bazen yanıltıcı olabilir • Hatayı ararken saatleriniz heba olmasın
  • 28.
  • 29. 7.HER ZAMAN SÜSLÜ PARANTEZ{} KULLANIN • Derleyici süslü parantezler eklenmiş gibi kodu yorumlar. Bu da istenmeyen bir duruma yol açar • Her zaman daha az kod daha iyi demek değildir • 2014 yılında Apple geliştiricisi iOS üzerinde SSL/TLS çalışırken bu hatayı yaptı ve bu yüzden sistemlere saldırılar oldu • Her zaman süslü parantez eklemek gerekir
  • 31. 8.KOD SIMETRISINI SAĞLAYIN • Bütün koşullar ardı sıra devam ediyor • Biraz daha büyüyünce bulmaca gibi olur, karmaşıklaşır • Bütün koşullu ifadeler benzer bir amaca mı yönelik? • Kod simetrisi yok
  • 32.
  • 33. 8.KOD SIMETRISINI SAĞLAYIN • Yetkili ve yetkisiz kodu ayırmış olduk • İkinci kısım simetri olmuş oldu
  • 34.
  • 35. 9.SIHIRLI(MAGIC) SAYILARDAN KURTULUN • Sihirli sayı: Kod içinde bulunan bakınca anlaşılmayan, rastgele sayılar • Hataya yol açarlar
  • 36.
  • 37. 9.SIHIRLI(MAGIC) SAYILARDAN KURTULUN • Anlaşılır ve erişebilir değişkenler tanımlayın ve onları kullanın • Kimse bu sayı(veya string) nedir diye düşünmek zorunda kalmaz
  • 38.
  • 39. 10.SABIT DEĞIŞKENLER YERINE ENUM TERCIH EDIN • Sabit değişkenler çok artarsa takip edilmesi zorlaşır • İstenilen durumlar için ayrıca farklı değerler atanma olasılığı var • Bu seferde metod ekstra kontroller yapması gerekiyor
  • 40.
  • 41. 10.SABIT DEĞIŞKENLER YERINE ENUM TERCIH EDIN • Enum bize ekstra güvenlik sağladı • Fazladan kontrollere gerek kalmadı • Derleme zamanında kontrollerin önüne geçmiş olduk • İf-else bloklarından bile kurtulduk
  • 42.
  • 43. 11.KLASİK FOR YERİNE FOR-EACH KULLANIN • Yeniliklere açık olun • Index için kullanılan i değişken değeri değişebilir ve hata alınabilir
  • 44.
  • 45. 11.KLASİK FOR YERİNE FOR-EACH KULLANIN • Konuşma diline daha yakın, for each check in checks… • Index değişkeninden ve hata alma ihtimalinden kurtulduk • Eski yönteme çok az ihtiyaç duymalısın
  • 46.
  • 47. 12.DÖNGÜ SIRASINDA DEĞIŞIKLIK YAPMA • Uygulamanın çakılmasına yol açabilir • ConcurrentModificationException hatası üretir
  • 48.
  • 49. 12.DÖNGÜ SIRASINDA DEĞIŞIKLIK YAPMA • Iterator liste üzerinde elemanlara işaretçi gibi çalışır • Liste üzerinde güncelleme işlemleri için tasarlanmıştır • hasNext ile garantiye almış oluruz
  • 50. SON