Yazılımcıdan Yazılımcıya İp Uçları, If Statements vs Clean Code & Code Performance

Vakit buldukça yazılım geliştirme, yazılım ekibi yönetme, sistem-platform tasarlama ve geliştirme konularında başımızdan geçen komik ya da trajik komik konular hakkında kısa kısa birşeyler yazacağım. Çok detaylı bir planlamam olmadığından sıklığı ve konuların detayları konusunda net birşey söyleyemeyeceğim. Vakit buldukça kısa kısa bir şeyler paylaşacağım. if/else-if/else ile başlayalım.

Örneğin bugün 2 tane if ve içerisinde toplamda 6 satırlık bir kod yazılmadığı için TR’nin en büyük hosting ve domain firmalarından birine dava açtım. Arkadaşlar .tr domain ön kayıt işlemlerinde öyle bir kod yazmışlar ki bir domaine 10’larca, 100’lerce kez ön kayıt yaptırabiliyorsunuz. Aynı firma üzerinden daha önceki ön kayıtları siz yapsanız bile mükerrer olarak 100’lerce kez ön kayıt yapmanıza izin veriyorlar. Daha önce ön kayıt yapılmış domainlerin parasını da gün içerisinde kredi kartınıza değil kendi sistemlerinde yarattıkları Sanal Karta iade ediyorlar. Sanal Kart istemiyorum diyorsunuz ama dinlemiyorlar, yine de sanal karta yatırıyorlar. Birçok insanın odak noktası iade kelimesinde olup sanal kart tuzağını kaçırdığından iade parası uzun süre onların hesabında kalıyor. Yani adamlar 2 tane if üzerine öyle bir saadeet zinciri kurmuşlar ki son 1 hafta içerisinde en az 100 milyon TL lik bir hacim yaptıklarını düşünüyorum. If deyip geçmeyin 😉 😉 😉

İşin şakası, goygoyu bir tarafa böyle bir seriye çok basit olduğu düşünülen ancak bana göre alengirli bir konu olan if/else-if/else cümlelerinden başlamak istedim. Bugünlerde patlayan AI çılgınlığında 4-5 milyar if cümlesi içeren API/AI’ler görüyoruz. Ancak bu çılgınlığın benim if cümleleri ile başlama motivasyonumla zerrece ilgisi yoktur.

Her kodlayıcının bildiği üzere if/else kodlamada nefes alıp/vermek gibi bişey. İstemsiz bir kas gibi görüldüğünden çok önemsemeyenler olabilir. 20 yıllık ultra senior yazılımcıların nasıl kahrolasıca if/else… yazdıklarını anlatsam sahifeler yetmezdi. Basit bir if deyip geçmeyelim.

1. Kullanabiliyorsanız if/else-if/else yerine switch/case kullanın.
2. Burda senaryo olarak bir auth servisini tarif edeceğim ve bazı gereksiz kontroller yazabilirim. Gereksiz kontroller konuyu daha net irdelemek ve örneklemek içindir.
3. Dil olarak yazması ve testi basit olduğu için JavaScript kullanacağım. Tüm programlama dillerinde benzer akış ve mantık kullanılabilir.
4. JavaScript’ten dolayı her iki örnekte de fazladan ikişer tane kontrol vardır. Java ya da C# gibi type safe dillerde bu kontrollere gerek yoktur. Çok takılmayınız, amaç kontrol mekanizmasının doğru kullanılmasıdır.
5. Buradaki amaç if koşullarına nasıl yaklaştığımızla ilgilidir. Çok daha iyi algoritmalar yazılabilir ancak gerçek hayatta görülebilen kodlara bağlı olarak bilerek hata yapılmaktadır.

Aşağıdaki görseller üzerinden basit bir auth işlemini konuşalım, en altta kodları da bulabilirsiniz.

Aynı fonksiyonun soldaki ve sağdaki yazılışını inceleyelim.

• Soldaki fonksiyon sağdakinden 1 satır fazladır.
• Soldakinde 2 koşul, sağdakinde 3 koşul vardır.
• Soldaki fonksiyonda if’lerdeki koşullar sağlanıyorsa fonksiyon akışı durmakta, fonksiyondan çıkılmaktadır. Yani bir sonraki if ya da işleme geçilmemektedir.
• Sağdaki fonksiyonda ise tüm if’ler kontrol edilmekte yani akış durmamaktadır.
• Soldaki fonksiyon biraz da derli toplu ve anlaşılabilir görünmektedir.

Bu noktada çok ciddi bir kazanç görünmüyor gibi. Aşağıdaki görseli inceleyelim.

Aynı fonksiyonun soldaki ve sağdaki yazılışını inceleyelim.

• Soldakinde 2, sağdakinde 3 koşul vardır.
• Soldakinde koşullar sağlandığında fonksiyon akışı durmakta ve fonksiyondan çıkılmaktadır.
• Sağdakinde ise koşullara bağlı olarak fonksiyon durdurulmamakta ve fonksiyondan çıkılmamaktadır.
• Soldakinde auth.status kontrolü yapılmasına gerek görülmemişken sağdakinde yapılmaktadır. Buradaki if’ler dönüş/return komutuna sahip değillerdir. User login ise login bilgileri için tüm kontroller yapılmalıdır.

İşleri biraz daha kızıştıralım. Biraz dikkatli gözler sağdaki kod’ta gözleri sulandıran bir eksik görüyorlardır. Eksiği düzeltmesek de biraz kaşıyacağız.

Aynı fonksiyonun soldaki ve sağdaki yazılışını inceleyelim.

• Soldakinde koşullardan biri sağlandığında akış durdurulmakta ve fonksiyondan çıkılmaktadır.
• Sağdakinde ise fonksiyon sonuna kadar çalıştırılmaktadır.
• auth.status === “logged” olduğu koşulda sağdakinde gözleri kanatan bir hata bulunmaktadır.
  • auth.status === “logged” ise auth.status !== “logouted” koşulu da sağlanmaktadır. Bu durumda result değişmekte user’ı unauthenticated’e dönmektedir.
    • === yerine !== hatasını yapmak çok kolaydır.
    • ya da kodlamanın bir döneminde === yazdığınız bir koşulu bir başka zamanda !== çevirebilir ve bu değişimin yan etkilerini gözünüzden kaçırmış olabilirsiniz.

Buradan hareketle…

1. Makale başında ifade ettiğim gibi mümkün olduğunda if/else-if/else yerine break’li switch/case kullanınız. Break çokomelli.
2. Çok fazla koşulun olduğu if/else-if/else akışlarında çok dikkatli olmalısınız. Buradaki gibi === yerine !== hatasını yapmak çok kolaydır.
3. Çok fazla koşulun olduğu if/else-if/else akışlarını kodlarken kodlamanın bir döneminde === yazdığınız bir koşulu bir başka zamanda !== çevirebilir ve bu değişimin yan etkileri gözünüzden kaçabilir.
   1. Yanlışlıkla girilen bir koşulun içerisinde DB’de milyon satırlık bir data çekip işlem yaptığınızı, bu hatayı farketmeden milyonlarca kişiye açtığınızı düşünün.
4. Çok fazla koşulun olduğu if/else-if/else akışlarının testleri her zaman sıkıcı ve zor olmuştur.
5. Çok fazla koşulun olduğu if/else-if/else akışlarında doğru koşul bulununcaya kadar çok fazla zaman harcayabilir, kaynak tüketebilirsiniz.
6. Burdaki en kritik noktalardan bir tanesi else koşulundaki belirsizlik ve else koşuluna kadar akışı çalıştırmanın verdiği dayanılmaz ağırlık.

Yani if/else-if/else yerine break’li switch/case kullanamıyorsanız ya da sadece birkaç tane koşulu kontrol edecekseniz. Return’e sahip if koşulları yaratmanız ve bunu alışkanlık haline getirmeniz oldukça yararlı olacaktır.

1. Koşul sağlandığı anda akış kesilir, işlemler durdurulur. Böylece ciddi zaman, kaynak ve performans kazancı sağlanır.
   1. if/else-if/else içerisinde de return çalıştırılabilir ancak çok fazla koşul olduğunda çarşı biraz karışır.
2. Koşul sağlandığı anda akış kesilir, akış yanlış yerde kesildiğinde yan etkilerini anında görürsünüz. Yani test etmesi oldukça kolaydır.

Peşrevi bırakıp sizlere söylemek istediğim tek cümleye geleyim.

Bir fonksiyon yazarken ya da test ederken o fonksiyonun hangi değerleri kesinlikle döndüreceğine ya da döndürmeyeceğine ve bu değerler için nelere kesinlikle sahip olmamız, neleri kontrol etmemiz gerektiğine net olarak karar vermeliyiz. Fonksiyon içerisinde ilermek için gerekli bu bilgilere sahip değilsek, o noktadan öteye gitmemize gerek yok.

Bizim örneğimizde “token” yoksa ilerlemenin bir anlamı yok. Token yoksa token’dan ötesine gitmeye gerek yoktu, soldaki fonksiyonda gitmedik. Böylesine bir mantalite için de sağdaki if/else-if/else akışlarınn yerine soldaki tekil if koşullarını bir alışkanlık haline getirmemiz çok önemlidir.

Bu örnekte bir auth için 3 fonksiyon yarattık. Çoğu “delikanlı” bunları tek fonksiyon olarak yazar. Bunları if/else-if/else ile tek fonksiyonda yazıp bu örnek ile bir karşılaştırın. Ben yazamayacağım, düşüncesi bile yordu. Ancak biz bir cloud platform ve game engine yazıyoruz. Bir engine için gereken kod satırını az çok hayal edebilirsiniz. Tüm platform ve engine içerisinde else kelimesi 1000 defa’dan az geçmektedir. O da sadece if/else olarak, if/else-if/else sanıyorum hiç yok.

Bundan bir tık iyisi benim sevdiğim yaklaşım, beğenmediğim yere gelince error fırlatmak. Vakit bulunca aynı örneği bir de error fırlatarak ele alalım.

Sevgiler,

Alper