Programlarda ad secerken kullandigim kurallar

[acehreli]

Baska bir konuya kisa bir yanit vermek icin basladigim yazi
kendi konusu olacak kadar buyudu. Programlarda ad secimleri
konusunda kullandigim kurallari hatirladigim kadariyla
yaziyorum:

Ad secimleri konusunda kendi uyguladigim kurallar cok
hizlica ve aklima geldigi kadariyla asagidaki gibi. Bu
kurallari baska C++'cilarin kodlarinda gorerek benimsedigim
icin genelin de hosuna gittigini dusunuyorum.

Soylemeye gerek olmayan :) kurallar
===================================

- Ad, programda temsil ettigi seyi acikca belli etmelidir:

int toplamHoroz = 1; // iyi
int omrTrps = 0; // OmUr torpusu! ;)
int f = 3; // felaket!

Not: Tek harften olusan adlar, cok yerlesmis olduklari icin
dongu degiskeni olarak kullanilabilirler. Ama o da icice
dongu kullanildiginda kedere neden olur :)

- Uygulanan kurallar tutarli olmalidir

- Projede kabul edilen kurallara uyulmalidir. (Cikintilik
rahatsiz eder. :) )


Konusulsa iyi olan kurallar :)
==============================

- Birlesik sozcukler: Birden fazla sozcukten olusan adlarda
sozcuk baslari ya buyuk harflerle ya da _ karakteriyle
belirtilir:

int toplamKaburga = 0; // benim tercihim
int toplam_borulce = 134507;

- Makro adlari: Butunuyle buyuk harflerle yazilir. Makro
olmayan hicbir ad da butunuyle buyuk harflerle yazilmaz; yoksa
karisir. Ornek:

#define TOPLAM_KEREVIZ 1
int const birSabit = 7;

- Tur adlari: class, struct, enum, typedef, vs. gibi tur
adlari buyuk harfle baslar. Ornek:

class KapiTokmagi;
typedef vector<Kalem> Kalemler;

- Islev ve nesne adlari: Kucuk harfle baslar. Ornek:

void foo();
int uzunluk = 12;

- Oge nesneler: Nesne adi kurallarina ek olarak oge
olduklarini belirten bir de takintilari olur:


class Araba
{
Direksiyon direksiyon_;
Korna korna_;
/* ... */
};


Yukarida oldugu gibi sonuna _ karakteri eklemek yaninda,
basina m_ karakterlerini ekleyenler de olur:


class Bisiklet
{
Sele m_sele;
Gidon m_gidon;
/* ... */
};


Bazi programcilar oge nesneleri de siradan nesneleri
adlandirdiklari gibi adlandirirlar. Iki nedenden oturu ben
buna karsiyim:

1) Kurucu islevlerde hangi adin ne oldugu anlasilamaz:


class Bisiklet
{
/*
Oge olduklari adlarindan anlasilmadigi icin bunlar
sorun cikartacaklar
*/
Sele sele;
Gidon gidon;
/* ... */

public:

Bisiklet(Sele const & sele, Gidon const & gidon)
:
sele(sele), gidon(gidon) // <---
{
if (/* ... */)
{
Sele yeniSele = /* ... */
sele = yeniSele; // <===
}
}

/* ... */
};


Yukaridaki kurucu islevde iki okla isaretledigim iki
'sele'nin ne olduklari iki yerde farklidir:

---> Oge seleye parametre sele ataniyor
===> Parametre seleye yeniSele ataniyor

(Derleyicim olmadigi icin deneyemiyor. Onun icin bu kuralda
yanlislik yapmis olabilir. Lutfen siz deneyin ve yanlissam
duzeltin.)

2) Birinci nedendeki duruma dusmeyelim diye parametre
adlarini anlasilmaz sekilde kisaltmak durumunda
kalabiliriz:


Bisiklet(Sele const & s, Gidon const & g)
:
sele(s), gidon(g)
{
/* ... */
}


Iste oge adlarinin sonuna bir _ karakteri eklemek bizi bu
dertlerden kurtarir.


Yasaklar
========

Hicbir ad iki tane _ karakteriyle baslamaz. O tur adlar
uygulamaya (derleyici ve kutuphaneleri) ayrilmistir. Ayni
nedenden dolayi, hicbir ad bir tane _ karakteri ve pesinden
bir tane buyuk harfle baslayamaz. Yine ayni nedenden oturu,
global ad alanindaki hicbir ad tek bir _ karakteriyle
baslayamaz.

Goruldugu gibi, bu alt cizgi kurali bir ust paragrafta belki
benim de yanlis hatirlamis olabilecegim gibi cok
karisiktir. Onun yerine ben su kurali uygularim: Hicbir ad _
karakteri ile baslamamalidir.

Bir kac tane yanlis ad:

/*
Bazi programcilar baslik korumalarinda bu hataya duserler:
*/
#ifndef _BASLIGIM_EKLENDI
#define _BASLIGIM_EKLENDI
#endif

int _foo(); // global alandaysak YANLIS
int __bar(); // heryerde YANLIS

(Not: Kullanicilarin kendi programlarindaki adlardan
bahsediyorum. Boyle adlar derleyici ve kutuphalerinde
kullanilmis olabilir.)

Ali

[Euclides]

ben macar notasyonundan vazgeçemeyenlerdenim
HANDLE hFile;int nValue;long lBlaBla,DWORD dTmp vb....

[Arkantos]

Benim de uzun süredir merak ettiğim bir konuydu bu.
Konu başlığı için tek bir yorumum var --> :super:

[Volkan Uzun]

microsoft bile vazgecti macar yonteminden :)

[Euclides]

daha iyi bir fikrin var m? ? ??? :)

[Volkan Uzun]

ms in var benim degil :)

[eceligelenfare]

microsoft bile vazgecti macar yonteminden :)

Bende -hala- macar notasyonunu kullananlardanım.

MS in neden vazgeçtiğini bilen var mı ? Açıkçası ben başka bir notasyonda pek rahat yazamıyorum.

Bu notasyon kullanma konusunu hatrı sayılır abilerimin bulunduğu bir toplantıda açmıştım. Sen nasıl rahat ediyorsan onu kullan diye bir cevap aldım. Tabii bu yöntem birden fazla programcının çalıştığı projelerde nasıl bir etki yaratır bilmem.

[acemi]

MS in neden vazgeçtiğini bilen var mı ?
Nesne yonelimli programlamanin yayginlasmasinin, Macar notasyonuna ragbetin azalmasina etkisi olmus olabilir.

[Galahantine]

Macar notasyonunda aklima gelen bir problem su:

Degisken adini ve tipini birbirine bagladigi icin degisken tipinde yapilacak bir degisiklik ayni zamanda degisken adinda da degisiklik yapilmasini gerektirecektir. Her ne kadar bugunlerde kullanilan IDE'lar refactoring isini iyi yapabilseler de hata yapma olasiligini durup dururken arttirmaya gerek yok bence.

Yukarida bahsettigim senaryon aslinda pek sik ortaya cikacak bir sey degildir ama yine de bir olasilik. Birden fazla programcinin calistigi projelerde genelde bu tur konularda belirli kurallar koyulur en basta.

[Euclides]

zaten değişken tipini değiştiriyorsan olay çıkması kaçınılmaz...VisualBasic değilki bu String ile long arasında fark olmasın :) :)

[Galahantine]

temel tiplerde bu tur problemler cok rahat ortaya cikabilir. Bir hesaplama icin short integer kullanabilirim, bu degiskeni de siLength gibi adlandirabilirim. Daha sonra bakarim ki short integer isime gelmiyor, onu float'a ceviririm. Program hala calisir ama degiskenin adini da
fLength sekline cevirmem gerekir (macar notasyonuna sadik kalmak icin).