Monthly Archives: Temmuz 2014

JavaTürk Java Kod İsimlendirme ve Şekil (Format) Standardı Yenilendi

Java

Bu yazıda daha önce burada yayınlamaya başladığım JavaTürk Java Kod İsimlendirme ve Şekil Standardı’nın yeni sürümünü yayınlıyorum, sürüm 0.2, PDF dosyasına da buradan ulaşabilirsiniz.

 

 

JavaTürk Java Kod İsimlendirme ve Şekil Standardı

 

 

Giriş

Bu dokümanda, Java kodunda kullanılacak isimlendirme ve şekil (format) standartları sıralanmıştır.

Bu doküman serbestçe kullanılabilir ve en güncel haline www.javaturk.org adresinden erişilebilir.

 

1.     Genel kurallar

1.    Daima isimlendirme ve şekil standartlarına uy. Ne kendinin ne de bir başkasının isimleri ve formatı anlamak içın enerji harcamasına sebep olma.

2.    Daima (standarda uyarak) umulan şekilde kodunu yaz, şasırtma. Standardın dışına çıkman gerektiğinde bunu açıkla.

3.    Programındaki her şey önce anlaşılır sonra küçük-kısa olsun. Ama küçüklük-kısalık için anlaşılırlığı feda etme.

4.    Hiç bir projeye bu stadartları kullanmadan baslama, başlatma. Yanlış yapılan şeylerin ileride düzeltilmesi çok zordur.

 

2.     En temel şekil kuralları

 

1.      Daima paragraf kullan. Kod yazarken parmakların sıklıkla format tuşlarında olsun. Ne sen ne de bir başkasının formatsız koda bakmasına izin verme.

2.      Her satırda sadece bir cümle (statement) yaz.

3.     Uzun satırları bir kaç satıra yay ki yatay scrolla ihtiyaç kalmasın.

4.      Mekanı rahat kullan: Mümkün olan her yerde boşluk, “ “, ve boş satır kullanarak okunurluğu arttır.

5.     Ifadelerin öğeleri arasında muhakkak boşluk bırak.

Böyle yapma:

rs = a+b*((c/a)*b);

Böyle yap:

rs = a + b * ((c / a)* b);

 

6.     Blokları mümkünse “{ }” ile değilse boş bir satır ile ayır. Blok kullanmak için sadece if-while-for gibi yapıları bekleme.

       7.     Zeka yarışına girme, “=” dahil en az 3 operatörlü ifadeleri anlamak operatörlerin   

            öncelik ve ilişkilendirme bilgisine bağlı olmasın, parantez kullan.

           Böyle yapma:

float rs = a + ++b * c/a * b;       

a += b += c;

Böyle de yapma:

rs = a + (++b)* ((c / a)* b);

Böyle yap:

b++;

rs = a + b * ((c / a)* b);

 

b += c;

a += b;

8.     Zincirleme üye erişimi ile birleşik ifade yazma, her ifadede bir üyeye eriş.

    Böyle yapma:

customer.getCompany().getAddress().getStreet();

           Böyle yap:

Company company = customer.getCompany();

Address address = company.getAddress();

Street street = address. getStreet();

Bu şekildeki zincirleme erişimin rahatlıkla kullanılabilecği tek yer web katmanındaki View yapıları (JSP, JSF vb.) olabilir. Bu yapılarda EL yardımıyla zincirleme erişim kolaylık sağlamaktadır.

 

3.     Genel isimlendirme kuralları

 

9.    Daima İngilizce isimler kullan ve kesinlikle yanlış yazma, emin değilsen sözlüğe bak.

10.    Daima anlamlı isimler kullan; uzun olsun, anlamsız olmasın.

addedValueTaxRate, getDefaultAccountInterestRate()

11.    Okumayı zorlaştıran (özellikle sesli harfleri atarak elde edilen) kısaltmalardan kaçın.

qry yerine query, cstmr yerine customer kullan.

12.    Tanıdık isimler kullan. Aynı şeyler için her yerde aynı ismi kullan.

13.     İsim verirken herhangi bir kodlama kullanma. Örneğin Hungarian notasyonunu uygulayarak aşağıdaki gibi isimler verme:

m_name, d_interest, l_increase

Bu durumun tek istisnası arayüz isimlerindeki “I” olabilir.

14.   Kısaltmalarda büyük harflerle yazma.

Böyle yapma:

hTTPSession, TCPIPConnection, getXMLNode(), getHTTPMethod()

Böyle yap:

httpSession, TcpIpConnection, getXmlNode(), getHttpMethod()

 

15.   Tutarlı ol. Aynı ismi sadece küçük-büyük harf ayrımıyla ya da hem kısa hem uzun şekliyle defalarca kullanma.

sqlQuery, sqlQry ya da session, ssn

16.    İsimlendirmede daima “Camel Case” yaklaşımını kullan, alt çizgiden “_”, uzak dur. Camel Case’in iki türü vardır, her ismin baş harfinin büyük olduğu Upper Came Case (UCC) ile sadece ilk kelimenin ilk harfinin küçük, sonrasının UCC olarak devam ettiği Lower Camel Case (LCC).

 

StudentInformation is UCC

getAllStudents() is LCC

studentAddress is LCC

 

4.     Paket isimlendirme kuralları

 

17.    Paket isimlerine internet alan adınızı tersinden yazarak başla.

tr.com.selsoft, org.javaturk

 

18.    Paketlerini küçük harfle yaz ve tek ve tekil isimler ver.

tr.com.selsoft.atm.domains

org.javaturk.designpattern.customers

19.     Paket isimlerin, paket içeriği hakkında bilgi versin.

tr.com.selsoft.atm.domain, org.javaturk.atm.view.bean

 

5.    Tip isimlendirme kuralları

 

20.    Sınıf, arayüz, enumeration gibi tiplerin adlandırırken isim kullan ve UCC yaz.

Account, CheckingAccountService, StudentInformation

21.    Arayüzleri adlandırırken daima isim ya da sıfat kullan ve UCC yaz.

Payable, ActionListener

22.    Bir konuyla ilgili özellikleri, sabiteleri ya da metotları bir araya getiren tiplere çoğul isim ver.

AtmProperties, StringUtils, ATMProperties

 

23.      Enum tiplere tekil isimler ver.

Day, Month, Size

 

6.     Değişken isimlendirme kuralları

 

24.    Değişken adlandırmalarında isim kullan ve daima LCC yaz.

count, firstName, taxRate, orderNumber

25.    Torbalar için çoğul isimler kullan.

Collection<Student> students

Map<Integer, Player> players

26.    Boolean değişkenler için uygunsa edilgen fiil (ya da sıfat-fiil) kullan öyle ki başına “is” getirildiğinde anlamlı bir soru olsun. Boolean değişken isimlerinde “is” ya da “are” kullanma.

married, tankFilled, seatBooked, tasksFinished

Eğer boolean değişken sahip olma durumunu gösteriyorsa ismin sonuna “Installed” gibi bir son ek getirilebilir.

gasTankSensorInstalled, radioInstalled

 

27.    Özellikler (properties) için daima JavaBean (bean) gösterimini kullan. Bean gösteriminde tüm değişkenler “private” (kalıtım durumunda “protected”) tanımlanır ve bunlara LCC olarak yazılmış set/get metotları ile ulaşılır:

private String name;

public String getName() {

        return name;

}

public void setName(String name) {

        this.name = name;

}

Boolean değişkenler için getter olarak “is” ön ekli metot kullanılır:

private boolean deceased = false;

public boolean isDeceased() {

        return deceased;

}

public void setDeceased(boolean deceased) {

        this.deceased = deceased;

}

 

28.    Metotlardaki yerel değişkenler için nesne değişkenleriyle aynı isimleri kullan ve nesne değişkenlerinie “this” ile ulaş.

29.     Kurucu ya da set metotlarına nesne değişkeni ile aynı isimde parametre geç, nesne değişkenine “this” ile ulaş. Bkz. #27

30.     Kısaltılmış ya da bir-iki harflık isimleri sadece sık kullanılan yerel değişkenler için kullan.

Döngü indexleri için i, j

String s ya da String str

stream için in ve out, exception için e ya da ex

 

31.     CamelCase yaklaşımının tek istisnası olarak sabitelerde (public, static ve final) araları alt çizgi “_” ile ayrılmış büyük harfli kelimeler kullan. Başka hiç bir isimde “_” kullanma.

public static final double ADDED_VALUE_TAX = 0.18;

public static final String USERNAME = “app”;

 

7.     Metot isimlendirme kuralları

 

32.    Get/set metotlarını JavaBean gösterimiyle yaz. Bkz. #27

33.     Metot isimlerinde daima emir kipi kullan ve LCC yaz.

calculateTax(), findOwnerOfAccount()

  

Kaynaklar

·      Java Code Conventions September 12, 1997 (Oracle Java Code Conventions

http://www.oracle.com/technetwork/java/codeconv-138413.html)

·      http://www.ambysoft.com/downloads/javaCodingStandards.pdf

·      http://www.ambysoft.com/downloads/javaCodingStandardsSummary.pdf

·      Google Style of Java

http://google-styleguide.googlecode.com/svn/trunk/javaguide.html

·      Al Vermeulen et al., The Elements of Java Style, CU Press, 2007

·      http://collaboratory.emsl.pnl.gov/docs/collab/sam/CodeStandards.html

·      http://www.ambysoft.com/downloads/javaCodingStandards.pdf

·      http://www.ambysoft.com/downloads/javaCodingStandardsSummary.pdf

·      http://www.javacodegeeks.com/2012/10/java-coding-conventions-considered-harmful.html

·      http://www.iwombat.com/standards/JavaStyleGuide.html

·      Unmaintainable Code http://mindprod.com/jgloss/unmain.html

 


Toplam görüntülenme sayısı: 1748

İsimlendirme ve Hungarian Notation

Java

İsimlendirme, kod yazarken en başta düşünmemiz gereken konulardan. Hatta o kadar ki bir şeye iyi bir isim bulamıyorsak muhtemelen o şeye sahip olmamamız gerekli ya da yanlış bir soyutlama yapıyoruz demektir. Bu yüzden doğru ve standart isimlendirme, anlaşılır kod, basit kod, clean kod, artık ne derseniz deyin, yazmanın en temel öğesi.

Java’nın çok güçlü bir isimlendirme standardı ve geleneği var. Bu standart üzerinde daha önce burada yazmış ve bir de kendi oluşturduğum bir isimlendirme ve şekil standardı dokümanı paylaşmıştım. Java’nın bu kadar güçlü ve yaygın isimlendirme standardı olmasına rağmen hala zaman zaman Java öncesi alışkanlıkların Java kodlarına taşındığına da şahit oluyorum. Bunlardan en yaygını ise “Hungarian Notation” ya da Macar Notasyonu denen isimlendirme yöntemi.

Hungarian Notation, DOS’un ilk zamanlarında Microsoft’un mimarlarından olan, Macar Dr. Charles Simonyi tarafında geliştirilmiş bir isimlendirme standardıdır. Bu standardın en belirgin tarafı, tip bilgisinin ismin başına kısaltma olarak gelmesidir. Örneğin

lNumber: long integer değişken
bReadLine(): byte döndüren bir fonksiyon
fTrue: boolean değişken

Yukarıdaki örnekler tip ile ilgili bilgi veriyor. Macar notasyonunda tip dışında

pX: X'e bir pointer
cX: X'in nesnelerinin sayısı

gibi daha mantıksal ön ekler de mevcuttur. Bu şekilde isimlendirmeyle oluşturulmuş bir kod şöyle gözükecektir:

1   #include "sy.h"
2   extern int *rgwDic;
3   extern int bsyMac;
4   struct SY *PsySz(char sz[])
6      {
7      char *pch;
8      int cch;
9      struct SY *psy, *PsyCreate();
10      int *pbsy;
11      int cwSz;
12      unsigned wHash=0;
13      pch=sz;
14      while (*pch!=0
15         wHash=(wHash<>11+*pch++;
16      cch=pch-sz;
17      pbsy=&rgbsyHash[(wHash&077777)%cwHash];
18      for (; *pbsy!=0; pbsy = &psy->bsyNext)
19         {
20         char *szSy;
21         szSy= (psy=(struct SY*)&rgwDic[*pbsy])->sz;
22         pch=sz;
23         while (*pch==*szSy++)
24            {
25            if (*pch++==0)
26               return (psy);
27            }
28         }
29      cwSz=0;
30      if (cch>=2)
31         cwSz=(cch-2/sizeof(int)+1;
32      *pbsy=(int *)(psy=PsyCreate(cwSY+cwSz))-rgwDic;
33      Zero((int *)psy,cwSY);
34      bltbyte(sz, psy->sz, cch+1);
35      return(psy);
36      }

Modern dillerle uğraşanların yukarıdaki gibi bir kodla karşılaşmak isteyeceklerini sanmıyorum. Java, C#, Python gibi modern diller isimlendirme ile ilgili, Simonyi’nin notasyonunu geliştirdiği zamanki dillere göre pek çok avantajı var. Modern dillerde tip kavramı çok daha zengin, bu dillerin ifade gücü eskilere oranla çok yüksek, fiziksel hiç bir sınırlamaları da yok. Hele nesne merkezli diller tip kavramını çok daha mantıksal bir seviyeye çıkarmışlar ve isimlendirme ile ilgili herhangi bir kodlamaya ihtiyaç bırakmamışlardır.

Zaman zaman Javacılar arasında macar notasyonun etkilerini görüyorum. Örneğin nesne değişkenlerini member kelimesinden esinlenerek “m_” ile başlatıp yerel (local) aynı isimli yerel değişkenlerle karışmasını önlemek ya da metoda geçilen parametreleri “p_” ile başlatmak gibi. Bence Javacıların bu tipten kodlamalara da ihtiyacı yok. Zaten internette yaygın olarak bulabileceğiniz hiç bir standartta böyle bir uygulama da yok. Örneğin Google’ın Java isimlendirme standartında “Rules common to all identifiers” kısmında şöyle deniyor:

“In Google Style special prefixes or suffixes, like those seen in the examples name_, mName, s_name and kName, are not used.”

Dolayısıyla Javacılar da “m_” gibi ön ekler kullanmaktan vazgeçmeliler. Metotlarda aynı isimdeki yerel değişkenlerden ayır etmek için “this” anahtar kelimesi kullanılmalıdır. Bu şekilde kodlamaların belki standart olmasa bile en fazla bileni ve kullanılanı, interface isimlerinde başta ya da sonra “I” kullanılması ve bu arayüzlerin gerçekleştirmelerinde ise “Impl” son ekinin kullanılması olabilir. Arayüzleri ayrı paketlere koyarak ya da arayüzlerin ruhuna uygun isimlendirmeler ile böyle bir kodlamaya da gerek kalmayabilir.

İfade gücü yüksek isimlendirme her zaman kodlayarak isimlendirmeden daha anlaşılırdır. En önemlisi ise bir koda baktığınız zaman sizin de aynı standartta kod yazacağınızı biliyor olmanız. Standartlara uymak çok büyük rahatlık.

 

 

Toplam görüntülenme sayısı: 1406

Java Kodunuzun Nesne-Merkezli Olmadığının 10 İşareti – VI: Aralarında benzerlik ilişkisi olan nesneleri modellemek için kalıtım kullanmamak

Java, Yazılım Mühendisliği

Geliştirdiğimiz Java kodunun nesne-merkezli olmadığının 10 işaretinin neler olduğunu bu yazıda listelemiş ve ilk dört maddeyi ele almıştık. Şimdi de beşinci maddeyi ele alalım:

Aralarında benzerlik ilişkisi olan nesneleri modellemek için kalıtım kullanmamak. (No inheritance hierarchy to model is-a relationships between the objects.)

Sebebi basit: Eğer kalıtım hiyerarşileriniz yoksa aynı tipten olan nesneleri ifade ederken pek de nesne-merkezli bir yöntem kullanmıyorsunuz demektir. Kalıtım kullanmazsanız polymorphismden faydalanamazsınız. Dolayısıyla kalıtım ve bunun sonucu olan polymorphism kullanılmıyorsa “neden nesne-merkezli bir dil kullanıyorsunuz?” sorusuna muhatap olursunuz? Hakikatten kalıtım ve polymorphism yok ise nesne-merkezli dilin en temel özelliklerinden sadece sarmalama ya da encapsulationu kullanıp sınıflar oluşturuyorsunuz demektir. Bu da Java’yı tam gücüyle kullanmamak, Java’yı C gibi kullanmak demektir.

Peki, kalıtım kullanılmadığında aralarında benzerlik ilişkisi olan yapıları nasıl ifade ederiz? Aşağıdaki basit sınıf bu durumu gösteriyor:

public class User{

	private String username; 
	private String password;
        private String name;
	private String lastname;
	private int type;

	public void register(){
		if(type == 1){
			doThis();
		}
		else if(type == 2){
		        doThat();
		}
		…
	}
}

Yukarıdaki örnekte User sınıfının farklı alt tipleri kalıtım yoluyla yeni sınıflar oluşturarak değil de aynı sınıf üzerinde oluşturulmuş int tipinde type isimli bir değişkenle temsil ediliyor. Bunun en temel problemi, farklı tiplerin davranışlarını farklılaştırmak için metotlarda bol miktarda “if/switch” cümleleri kullanmak zorunda kalmaktır. Eğer kalıtım kullanılsaydı “if/switch” cümlelerini kullanmaya gerek kalmayacaktı çünkü register() metodunun farklı, override eden implementationları olacaktı.

Inheritance

Yukarıdaki durumda User sınıfının ve register() metodunun abstract olduğunu, dolayısıyla da onu extend eden sınıfların register() metodunu override ettiğini düşünebiliriz.

public abstract class User{

	protected String username; 
	…

	public abstract void register();
}

--------------------------------------------------------------
public class IndividualUser extends User{

	…

	public void register(){
		doThis();
	}
}

--------------------------------------------------------------
public class CorporateUser extends User{

	…

	public void register(){
		doThat();
	}
}

Yukarıdaki koddan da görüldüğü gibi bir kalıtım hiyerarşisi ve override edilmiş metotlar ile hem nesne açısından daha hoş bir yapıya ulaştık hem de “if/switch” cümlelerinden kurtulduk. Bu sayede tipe göre davranışı ayırt etmek artık JVM’in görevi haline geldi.

Öte taraftan kalıtım kullanmanın sarmalamaya (encapsulation) ters bir yapı olduğunu ve hiyerarşideki nesneler arasında ciddi bir bağımlılık (coupling) oluşturduğunu da söylemeliyiz. Örneğin User sınıfında yapılacak bir değişiklik alt sınıfları etkileyecek ve onların değişmesini gerektirebilecektir. Bu durum “inheritance violates encapsulation” yani “kalıtım sarmalamayı bozar” olarak ifade edilir. Bu sıkıntıdan dolayı kalıtım kullanırken dikkatli olmakta fayda vardır. Bu konu aslında burada hızlıca geçiştirilecek kadar basit değildir. Bir başka yazıda bunu ele alabiliriz.

Bol kalıtımlı günler dilerim.

 

 

Toplam görüntülenme sayısı: 1142