Java Günlüğüm
Yazılım, Java, BT, azıcık felsefe, biraz mizah...
  • Udemy Eğitimleri
  • Temiz Kod
  • Tasarım Kalıpları
  • Hakkımda
  • Arşiv
RSS
06 Ağustos 2014

Martin Fowler Türkiye’de

Akin Java, Kültür, Bilgi ve Düşünce, Yazılım Mühendisliği

Dün oturmuş “Kod Kimin İçin Yazılır” başlıklı yazıyı yazıyordum. Yazıya Martin Fowler‘ın bir sözüyle başlamıştım ki sevgili dostum Barış’tan, “Martin Fowler’ı ağırlayacağız Türkiye’de” diye bir email almaz mıyım 🙂 Sizi bilmem ama ben kendi adıma çok sevindim ve hemen buradan kayıt yaptırdım. Fowler 11 Eylül’de İstanbul’da olacak ve “Continuous Delivery and Design” konulu konuşma yapacak.

Körün istediği bir göz, Allah vermiş iki göz 🙂 Fowler’in bir “Refactoring” bir de “UML Distilled” kitaplarının hastasıyım zaten. Hele “Analysis Patterns”, türünün nadide örneklerinden. Sanırım bütün kitapları hikmet dolu bu adamın. Kaçırmayın derim. Adamı dinlemeden önce de kitaplarını okuyun ki daha fazla istifade edebileseniz.

Fowler’ı ülkemize getiren ThoughtWorks‘e de teşekkürlerimizi sunuyoruz.

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

6 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
06 Ağustos 2014

Kod Kimin İçin Yazılır?

Akin Java, Yazılım Mühendisliği anlamak, Bilgi, Bilmek

Martin Fowler, Refactoring adlı kitabında şöyle der:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Yani, dilimize çevirirsek:

Herhangi bir insan bilgisayarın anlayabileceği kod yazabilir. İyi programcılar ise insanların anlayabileceği kod yazarlar.

Devamlı, farklı eğitim, bilgi ve tecrübe sahibi yazılımcılarla görüşüyorum. Bazen konuya çok uzak insanların olduğu bir dost sohbetinde “programcı” ya da “yazılımcı” olduğumu söyleyince, insanlar çoluk-çocuklarının ya da tanıdıklarının da benzer şekilde programcı olduğunu söylüyorlar. Eğer böyle bir sohbet, İstanbul dışında, taşarada yapılıyorsa, bana bahsedilen kişi, muhtemelen endüstri meslek lisesi mezunudur ya da lise mezunu olup, bilgisayar ve oyun dünyasında ciddi vakit geçiren mesela bir internet cafe çalışanı ya da sahibidir. Bu gibi insanlar, kendi kendine, hem öğrenmek hem de ufak tefek ihtiyaçlarını gidermek hatta para da kazanmak amacıyla, VB, PHP vb. dil ve araçlarla ucundan kıyısından yazılım dünyasına bulaşmış kişilerdir.

Sıklıkla profesyonel ortamlarda üniversite mezunlarıyla, farklı tecrübe ve geçmişe sahip olan gençlerle de karşılaşıyorum. Farklı bölümlerden geliyorlar, Bilgisayar Mühendisliği, Elektrik, Elektronik Mühendisliği, Matematik bölümleri, vs. vs. Çok iyi egitim almış, fen lisesi ya da ünlü özel liselerden gelen, dolayısıyla son derece iyi bir temel eğitime sahip insanlar ciddi oranı oluşturuyor gençlerin arasında. Formal bilgilenmesine daha önem vermiş, master hatta doktora yapmış insanlarla karşılaşıyorum sık sık. Daha olgun, daha gün görmüş, daha sakin düşünen kişiler. Farklı teknolojileri kullanıyorlar: Java, .NET, Php, C/C++, Html, Javascript, mobil teknolojiler, iOS, Android, veri tabanıyla ilgilenenler, adminler, SQL, PLSQL, T-SQL uzmanları, SAP, BI vb. konularda uzmanlar vs. Çok farklı tipte teknolojilerle çalışmalarına rağmen temelde yaptıkları şey aynı; yazılım geliştirmek. Bir şekilde kodla haşır neşir oluyorlar. Farklı teknolojiler de olsa, farklı iş alanları da olsa, farklı pozisyonlar da olsa aslında hepimiz, bir şekilde bir kod parçasının doğru düzgün çalışması için çalışıyoruz.

Bu şekilde görüştüğüm insanlara farklı seviyelerde saygı duyuyorum. Kimine iyi eğitiminden dolayı kimine hiç bir eğitimi olmamasına rağmen gayretinden, öz güveninden ve bunlarla yaptıklarından dolayı saygı duyuyorum. Kimi belli ki stresli ortamlarda sakin kalmayı başarabiliyor, kimi ciddi bir yükü tek başına sırtlamış savaşıyor, bunlar da saygıyı hakediyor. Kimisi teknoloji düşkünü, bir sürü teknolojik yenilikleri öğrenmiş, çevresindekilere de öğretiyor, pek çok teknolojik kararı kendisi almış, teknoloji lideri yani, saygı duyuyorum. Bu sektörde iyi niyetle ve kapasitesinin el verdiği ölçüde üreten herkese çok saygı duyuyorum.

Tüm bu eğitim, teknoloji, gayret, fedakarlık, liderlik vs. vasıflarına saygı duyduğumdan çok daha ötede saygı duyduğum bir olgu var: Anlamak. Anlamak, bilmekten daha değerli hatta yapmaktan bile daha değerli. Çünkü sürdürülebilirlik yapmaktan ziyade anlamakla mümkün. Bu yüzden bu yazıya yukarıdaki Fowler’un cümlesiyle başladım. Yazılımcılar iyi-kötü, bir şekilde kod yazarlar. Ama iyi yazılımcıyla iyi olmayan yazılımcıyı ayıran en temel şey, ne eğitimi ne fedakarlığı ne de yapabilme yeteneğidir. Bence iyi yazılımcıyla iyi olmayan yazılımcıyı ayıran en temel şey, Fowler’ın da işaret ettiği gibi, bilgisayarın anlayacağı koddan çok, insanların anlayabileceği kod yazmaktır.

Benzer şeyi “Code Simplicity” isimli kitabının hemen başında Max Kanat-Alexander şöyle ifade ediyor:

The difference between a bad programmer and a good programmer is understanding . That is, bad programmers don’t understand what they are doing, and good programmers do. Believe it or not, it really is that simple.

İyi programcıyla kötü programcı arasındaki fark anlamadır. Yani kötü programcılar ne yaptıklarını anlamazlar, iyi programcılar ise anlarlar. İster inanın, ister inanmayın ama bu gerçekten bu kadar basittir.

Bence de durum bu kadar basit. Ne yazdığınızın çok fazla bir önemi yok, önemli olan nasıl yazdığınız. Hangi dili kullandığınız, hangi frameworklere daldığınız, ne kadar bilimsel konularda kod yazdığınız, ne kadar eğitimli olduğunuz, vs. vs., bunların hiç bir önemi yok aslında. Tek önemli şey, yazdığınız kodu yazılımcı takım arkadaşınız ne kadar kolay anlıyor, önemli olan bu.

Siz anlamadan, noktası virgülüne kadar her türlü detayını özümsemeden yazdığınız kodun başkası tarafından anlaşılmasını zaten bekleyemezsiniz. Yazılım yeterince karmaşık, dolayısıyla yazılım ürünü olan kod da karmaşık. Kodun yapısında o kadar farklı faktör var ki bazen bir tek satırı anlamak için saatlerinizi verirsiniz. İş mantığı, kodlanan dil, tasarlarken sahip olduğunuz yaklaşımlar ve bundan dolayı taviz verdiğiniz birliktelik (cohesion) ve oluşturduğunuz bağımlılıklar (coupling), sıra dışı durumlar, performans gibi mimari ihtiyaçlar, vs. Ufak bir kod parçasını tüm bu açılardan ele alarak, basit, standartlara uygun, odaklı, tam ve doğru bir şekilde yazmak, yani anlayarak ortaya çıkarmak çok zor hatta bazen bir kişinin yapabileceğinden çok fazla bir iştir.

Yukarıda bahsettiğim, basit gibi görünen programlama faaliyetinin tüm bu zorluklarını aşmanın tek yolu, ne yaptığınızı anlayacak şekilde kod yazmaktır. Öncelikle siz kendiniz için anlamalısınız. Anlamayı, sadece bilmeyi, sorunu çözmeyi değil her yönüyle problemi anlayıp ona yukarıdaki bahsettiğim-bahsetmediğim tüm yönlerine hakim olarak bir çözüm geliştirmeyi hedeflemelisiniz. Bu anlamda malesef VB, PHP vb. dil ve araçlar ile, biraz da büyük şirketlerin yanlış yönlendirmeleriyle, sürükle-bırak mantığıyla program yazılabileceği şeklinde bir algıya sahip olmamız, bence anlama önündeki en büyük engellerimizdendir. Bu sürükle-bırak mantığına artık bir de Google programcılığı eklenmiş durumda ki sormayın gitsin. Ben “… öğrenilmez, Google’dan çözümü bulunur” diyen, üniversite mezunu, Bilgisayar Mühendisi, yıllardır development yapan insanlar tanıdım bu ülkede. Kullandığı dilin en temel özelliklerini bilmeyen, o dil ile ilgili ister okulda ister kursta isterse de evde kitap okuyarak hiç bir formal eğitim almamış insanların yazılım geliştirdiği bir ortamdayız malesef. Eğitimsiz para babalarının, Türk futbolunda her şeyi bilir edasında davranmalarını ezikleyerek eleştirirz ama bu yaptığımızın onların yaptığından farklı olmadığını göremeyiz malesef. Aslında ikisinin de sonucu aynı: Sadece bu topraklarda geçerli ürünler. Bir türlü beklenen patlamayı yapamayan futbolumuz ile Edirne’den dışarıya çıkamayan yazılım ürünlerimizin sebebi aynı olabilir mi? Demek ki önemli olan eğitim değil, kültür. Malesef ne kadar eğitimli olursak olalım bu topraklarda iş yapış şekli hep aynı.

Tonla teknolojiyi bilmektense, az ama bir araya getirip bir çözüm kurgulayabileceğimiz sayıda teknolojiyi bilmeye çalışalım. Her gördüğümüze atlamaktan, her yeni çıkan teknolojiyi öğrenmeye çalışmaktan vazgeçelim, az bilelim ama öz bilelim. Yazdığımız kodun da teknolojik olmasından ziyade ve önce, anlaşılır, kolay okunur, kısa, öz, standart, tam ve doğru olmasına özen gösterelim. Bu konuda burada yazdığım pek çok yazıya göz atabilirsiniz.

Einstein’in dediği gibi “Herkes bilebilir. Önemli olan anlamaktır” (Any fool can know. The point is to understand.)

Dolayısıyla kod önce kendin için sonra arkadaşların için sonra senden sonra gelecekler için yazılır.

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

15 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
24 Temmuz 2014

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

Akin 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ı: 1815

11 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
23 Temmuz 2014

İsimlendirme ve Hungarian Notation

Akin Java Clean Code

İ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ı: 1499

6 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
«< 38 39 40 41 42 >»

Günlüğüme Hoşgeldiniz

Bu günlükte, Yazılım Mühendisliği, Bilgi Teknolojileri, Java, kişisel gelişim ve zaman zaman da diğer konulardaki düşüncelerimi sizlerle paylaşacağım. Umarım beğenir ve hoşça vakit geçirirsiniz.

Her türlü düşüncenizi, yorum olsun, beğeni ya da eleştiri olsun, bana iletmenizi rica ediyorum sizden. Ayrıca bana akin@javaturk.org adresinden ya da Twitter'dan ulaşabilirsiniz. Videolarıma da buradan ulaşabilirsiniz.

Teşekkür ederim.

Akın Kaldıroğlu

Rahat Okumak İçin

A Decrease font size. A Reset font size. A Increase font size.

Sosyal Medya

  • Twitter
  • Facebook
  • LinkedIn
  • Youtube

Son Twitlerim

→ Takip Etmek İçin

Abone Olun

Emalinizi girerek yazılardan haberdar olun.
Loading

Son Yazılarım

  • Udemy Eğitimlerim Üzerine
  • (başlıksız)
  • Clean Code / Temiz Kod Eğitimi Udemy’de
  • Java ile Nesne-Merkezli Programlamaya Giriş Eğitimi Udemy’de
  • Selsoft Video Eğitimleri
  • Spring ile Kurumsal Yazılım Geliştirme
  • Corona Günlerinde Design Patterns
  • Corona Günlerinde Java
  • JDK 10 ve “var” Özelliği
  • Onur Özcan
  • Analist ve İş Bilgisi
  • Farklı Dillerin Bakış Açısıyla Nesne-Merkezli Programlama
  • Java Nedir?
  • Bilgi Teknolojilerinde Yetenek Yönetimi – II: Tanımlar ve Eleştiriler – I
  • Alelade Hikayeler – II: Bir Başka Performans Problemi

Yazı Kategorileri

Yazı Takvimi

Mart 2026
P S Ç P C C P
 1
2345678
9101112131415
16171819202122
23242526272829
3031  
« May    

Yazı Arşivi

Blogroll

  • Binnur Kurt'un Günlüğü
  • Ender'in Java Blogu
  • Erdem Seherler
  • Kızımın Günlüğü
  • Kurumsal Java
  • Levent Karagöl
  • Levent'in Java Blogu
  • Mert Can Akkan’s java tips,options, news…
  • Yaşar Safkan
  • Yasin Saygılı
  • Yazı Dünyası

Yazı Etiketleri

analiz Bilmek C Desen design pattern EJB Eğitim Fortran Hibernate Java Java'ya nasil baslarim Java dersleri Java EE Java Persistence API Java SE Java Sertifika Java Öğren Java öğreniyorum Java öğrenmek JPA Kalıp Kurumsal Java nesne nesne-merkezli No Silver Bullet object object-oriented Oracle Java Certifications pattern performans programlama programlama dilleri programlama nedir sertifika singleton tasarım tasarım deseni tasarım desenleri tasarım şablonu yazılım yazılım geliştirme Yazılım Mühendisliği yazılımın doğası yazılımın zorlukları Şablon

↑

© Java Günlüğüm 2026
Powered by WordPress • Themify WordPress Themes
 

Yorumlar Yükleniyor...