Diese Präsentation wurde erfolgreich gemeldet.

Java By Comparison

1

Teilen

Nächste SlideShare
Bir Alim - Fuat Sezgin
Bir Alim - Fuat Sezgin
Wird geladen in …3
×
1 von 50
1 von 50

Weitere Verwandte Inhalte

Ähnliche Bücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Ähnliche Hörbücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Java By Comparison

  1. 1. JAVA BY COMPARISON SIMON HARRER, J.LENHARD, LINUS DIETZ HAZIRLAYAN İBRAHIM KÜRCE
  2. 2. 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
  3. 3. 2-OLUMSUZLUKTAN KAÇININ • Her zaman pozitif olun. Çünkü anlaması daha kolaydır • !(değil) işaretini mümkün olduğunca kullanmayın
  4. 4. 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
  5. 5. 3.BOOLEAN İFADELERİ DİREK DÖNÜN • Gereksiz if ifadelerini temizleyin • Daha fazla karmaşa oluşturur
  6. 6. 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
  7. 7. 3.BOOLEAN İFADELERİ DİREK DÖNÜN • Hatta alt parçalara bölebiliriz,
  8. 8. 4.BOOLEAN İFADELERİ BASİTLEŞTİRİN • Çoklu ifadelerin anlaşılması ve değiştirilmesi zordur
  9. 9. 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
  10. 10. 5.KOŞULLU IFADELERDE NULL HATASINA DIKKAT EDIN • NullPointerException en çok gördüğümüz hatalardan • İfadelerin sırasına dikkat edin
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 7.HER ZAMAN SÜSLÜ PARANTEZ{} KULLANIN • Hizalama bazen yanıltıcı olabilir • Hatayı ararken saatleriniz heba olmasın
  15. 15. 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. 16. • 16
  17. 17. 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
  18. 18. 8.KOD SIMETRISINI SAĞLAYIN • Yetkili ve yetkisiz kodu ayırmış olduk • İkinci kısım simetri olmuş oldu
  19. 19. 9.SIHIRLI(MAGIC) SAYILARDAN KURTULUN • Sihirli sayı: Kod içinde bulunan bakınca anlaşılmayan, rastgele sayılar • Hataya yol açarlar
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 12.DÖNGÜ SIRASINDA DEĞIŞIKLIK YAPMA • Uygulamanın çakılmasına yol açabilir • ConcurrentModificationException hatası üretir
  26. 26. 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
  27. 27. SON

×