Genel olarak yapilabilecek gelistirmeler

Selamlar,

Kodun tumunu inceleyemedim ama genel olarak asagidakileri yaparsaniz bence %20-30 gibi iyilestirme yapmis olursunuz. Sebepleriyle yazarsam biraz daha ikna edici olmus olurum.

Turkce isimlendirme

Genel olarak herkes Ingilizce'ye alistigi icin tamamen Ingilizce olan ve guzel yazilan bir kodu, isimlendirmeleri Turkce yapacak sekilde degistirirseniz, buyuk ihtimal ilk tepki koda bakmadan bu nasil kod olmus olur. Turkce yapilamaz mi? Tabi ki yapilir ama bence genel olarak evrensel bir dil kullanmakta yarar var, cunku diger turlu yari Turkce, yari Ingilizce oluyor ve daha kotu bir sonuc ortaya cikiyor. Bir de yazilim dili evrensel bir dil, yani herkesin anlayabilecegi birseyler yaparsaniz, sadece Turkiye'deki insanlar degil, herkese hitap etmis olursunuz. Open source amaciniza daha iyi ulasirsiniz. Turkce olmayinca anlasilmayan kisimlar icin bence workshop falan duzenleyebilirsiniz, ezberleyebilirsiniz ama sonuc olarak bunu yapmaniz lazim bence.

Bir diger sebep de, herkesin alistigi bir dil var diyelim, genel olarak bu insanlarin size yardim etmesi icin ayni dilde konusmak gerekiyor, Turkce olunca acikcasi biraz motive kaybi oluyor. (Bu Turkce'ye ozgu degil, Ingilizce olmayan her dil icin mevzu ayni). O yuzden projeyi en cekici halde yazmak her zaman avantajli. Cince comment'leri olan, almanca isimlendirmeleri olan projeleri hatirliyorum, inanilmaz derecede motive kaybi yasiyor insan.

Paket isimleri

Her dilin belli kurallari var. Nasil ki Turkce'de "de" yi ayri yazmayinca ya da baska bir gramere uymayinca kotu gozukuyorsa, ama hala kullanisli oluyorsa, burda da durum ayni. Paket isimleri genel olarak her zaman kucuk karakterlerle yazilir, bunun en temel sebeplerinden biri de Class/Interface ile karistirilmamasi icin. Ornegin Activity diye bir paket adi var, ama Activity diye bir sinif da var. Bunu engellemek icin boyle bir kural koymuslar. Daha farkli sebepleri de olabilir mi bilmiyorum acikcasi ama ben baska sebep goremedim. Genel olarak herkes buna alistigindan bu kurali uygulamak projenize destek icin buyuk yardimci olur. Bununla ilgili birkac link var altta. Google style guide'ini genel olarak kullanabilirsiniz hersey icin, okumanizi ve uygulamanizi kesinlikle tavsiye ederim.

https://google.github.io/styleguide/javaguide.html#s5.2.1-package-names https://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html

Bosluk, indent (paragraf basi) vs

Kodlarin bazi yerleri sanki yazayim da bitsin gibi, ornegin alttaki kod, soyle bir 10 sn elinizi klavyeden cektiginizde burda yanlislik var demeniz lazim. Kodu yazmaya ne kadar ozen gosterirseniz bence o kadar daha guzel isler yaparsiniz, gereksiz bosluklar ve yanlis isimlendirmeler herkesi rahatsiz eden bir konu. Kodun diger kisimlarinda da buna benzer yanlisliklar var, indentation hatalari cok fazla. IDE'ler size bu konuda yardimci olur. Yapmaniz gereken reformat yapmak, en kisa yoldan android studio'da paketin uzerine sag tiklayin, orada Reformat Code var, tiklayin ona, kodu bir duzgun hale getirsin, daha sonradan tek tek gereksiz bosluklari silin. Reformat Code'un hemen altinda da Optimize Imports var, bununla da gereksiz tum import'lari kaldirmis olursunuz. Bu olaylari sinif icin de yapabilirsiniz, kisayollari mutlaka ezberleyip aliskanlik haline getirin, ben de refleks gibi artik, surekli yapiyorum bir kac kod blogu yazdiktan sonra

                try {
                            Log.d("TAG", "onResponse: " + tempKisi.getKullaniciAvatarUrl());

                                kisiList.add(tempKisi);

                        }
                    } catch (JSONException e) {
                        e.printStackTrace();
                        Log.d("TAG",e.toString());
                    }

Bunu otomotize etmek istiyorsaniz, checkstyle denen statik kod analizi yapan bir plugin var, tabi daha detayli konu, sonradan ogrenince onu da ekleyebilirsiniz, boylece otomatik olarak tum kodunuzu surekli inceler.

Access modifiers

Turkcesini yazmak istedim ama aklima gelmedi acikcasi. Erisim denetleyicileriymis. Simdi ben erisim denetleyicileri diye birsey yazsam var olan tum chat'lerde, buyuk ihtimal kimse anlamayacak, o yuzden aliskanlik olmasi acisindan "access modifier" diye bahsedecegim.

Genel olarak java'da var olan 4 tane modifier var,

public (heryerden erisilebilir)
package private (default hicbirsey yazmadiginizda varsayilan) (sadece ayni package da olanlar erisebilir)
protected (sadece sub-class'lar ve kendisi erisebilir)
private (sadece kendi sinifi icinde olanlar erisebilir)

https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html

Belli basli basit kurallari kesinlikle takip etmek lazim ilk basta. Kodun bazi yerlerinde public, bir sonraki satir private sonraki satir package-private. Genel kural her zaman en guvenilir olandan sona dogru gitmek de yarar var, ornegin private olabiliyorsa mutlaka private, en kotu ihtimal public yapabilirsiniz. Bunun icin altin kural yok aslinda, cok farkli degisik yaklasimlar var, test icin package-private kullanimi vs, ama ilk basta bunu bu sekilde uygulayabilirsiniz. Hangisinin ne oldugunu tam olarak yazmadim, arastirirsaniz bir sure kaynak var, genel olarak package-private'in ne ise yaradigini cogu insan bilmiyor olabiliyor universitedeyken (ben universite bittikten sonra ogrendim acikcasi :) )

README

Genel yapilan hatalardan bir tanesi de bence README.md yi duzgun yazmamak. Insanlarin ilk gordukleri sayfa bu. Bu kisimda mumkun oldugu kadar bilgi vermekte yarar var, ornegin bu projeyi nicin yaptiniz, nasil bir surec yasadiniz, insanlardan, open source'dan beklentileriniz neler, ne gibi ihtiyaclariniz var, contribute etmek isteyenler neler yapmali. Bu proje tam olarak ne yapiyor? Birkac screen shot koyabilirsiniz, play store'da varsa onun linkini koyabilirsiniz. Ne gibi ozellikleri var, onlari anlatabilirsiniz. Bunlari detayli ve guzel sekilde yazmak cok onemli. Aslinda biraz yazmaya calismissiniz ama diger kisimlar bu kismi kapatiyor. Hangi IDE yi kullandiginiz, hangi kutuphaneleri kullandiginizi belirtmek evet guzel, ama olmasa da olur bilgiler aslinda (lisans vs icin neleri kullandiginiz belirtmek onemli, kodun icinde de bunu yapabilirsiniz), ama onlari da kucuk puntolarla, detay olacak sekilde en alta koyabilirsiniz. Ama oncelik mutlaka projenin amaci, nasil olustugu, ne yaptigi vs olmali, Buraya bakanlarin cogu sizleri tanimiyor, turkcell ismini gorunce de bu projenin turkcell tarafindan yapildigini dusunuyor, bu da beklentiyi degistiriyor. Boyle basit hatalari engellemek icin mutlaka o kisimlari duzeltin. Kimlerin katkida bulundugunu vs yazmak da cok onemli. Kendinizi bir bakima tanitabilirsiniz bu sekilde.

Yazim hatasi

Cogu insan belki onemsemeyebilir gibi gozukuyor ama insani inceden en cok rahatsiz eden seylerden biri de bu. O yuzden yazdiklarinizi mutlaka kontrol edin, review yaptirin mutlaka. Biri mutlaka soyle 10sn de olsa 1dk da olsa baksin kodunuza ve aynisini tabi ki siz de yapin, yazdiginiz kod bittikten sonra soyle bir goz atip yanlis birsey var mi diye bakin. Kodun icinde buna benzer seyler gordum, Activitiy gibi mesela.

Son olarak, bunlarin haricinde kodun geri kalan kisimlariyla ilgili de birkac sey ekleyebilirim, bunlari yaptiktan sonra diger kisimlari icin de tekrardan issue acarim. Yazdiklarim benim goruslerim, kesinlikle boyle olacak, baska yolu yok, en iyisini ben biliyorum degil bunlar, sadece tecrubelerimi sizlere aktarmak istedim.

Kolay gelsin simdiden

Turkcell / GYAppAnd

Genel olarak yapilabilecek gelistirmeler #11