slovník identifikátorů

Taky máte někdy problém vymyslet název proměnné pro danou věc? A ne a ne přijít na to správné?
Co založit něco, co by pomáhalo. Je to spíš legrace, ale třeba to bude zajímavé.
Jak by se v tom mělo hledat? Co by tam všechno mohlo být?
příklad:
i - index, for cykly, indexy polí... následuje j jako vnořený, k...

seznam, číselník - list, enum, proboha ne dial! ;-)
<HTML>S tim problemy nemam.</HTML>
Promiň, ale tohle mi příjde jako nesmysl ;)

U cyklů snad všichni používají i j k a u ostatních proměnných se většinou dává (kupodivu) název podle toho, co proměnná vyjadřuje. A těžko uděláš seznam všech věcí, které mohou být uloženy v proměnné.
Nehledě na to, že někdo používá česká slova, někdo anglická (někdo obojí), dlouslovné názvy je možné zádavat $MojePromenna nebo $moje_promenna atd....
Taky si myslim, ze je to blbost. Kazdy pouziva vlastni nazvy promen.

Ale jista pravidla lze najit, ale tech je prece jen malo.
1) Klasika u cyklu - pismena. Nejcasteji i,j,k,l
2) U velkych projektu, aby nedoslo ke konfliktu promennych, se pred nazvem promenne jeste pouziva neco jako nazev projektu (ci casti) - $mysql_xxx , $galerie_xxx, $shop_xxx .
3) Nektere identifikatory funkci pouzivaji zavedenou klasiku - $fp u souboru, $conn u mysql, atd.
<HTML>Tomik: u velkych projektu se pouziva OOP kde se da kazde promenne priradit jeji prava (public,private,protected) a ve spolupraci lokalnich promennych (uvnitr cyklu, funkce) neni treba zadne predpone $neco_ to zbytecne prodluzuje jeji zapis

MzM:
Je fakt, ze promenne s globalni platnosti dedene ve tridach ktere nesou zakladni data (napr. inicializovana konstruktorem) by se mozna i dali sepsat do nejakeho seznamu protoze jejich ucel byva vetsinou standardni ale to zalezi na spouste faktoru a je tu pomerne velka skala informaci a jejich rozliseni.</HTML>
Richard: To jest pravda. OOP osetruje mnozstvi promen, takze nejake $neco_ neni potreba. Ale jedna vec. Prava jsou, pokud vim, az v PHP5.
Ale najdou se lidi, co jeste nepresli na OOP, tak jim tato volba muze usnadnit orientaci. Tak jako u mne. Ja zatim pendluji mezi starym zpusobem a novym OOP ;) U rozjetych projektu, kde pouzivam stary zpusob, se mi nechce pracne predelavat do OOP. U novych pouzivam uz OOP a tam se skutecne nemusis moc starat o konflikt promennych.
mzm: spis je problem najit "vhodne" jmeno metody/fce. existuji almanachy kde muzes najit seznam jmen metod a zjistit zda se napriklad pouziva vice jmeno removeItem nebo deleteItem. pro promenne jsem nic podobneho nevidel, spis jen obecne rady tykajici se delky nazvu, popisnosti nazvu a vseobecne pojmenovavaci konvence, ktere se ale muzou lisit projekt od projektu - nekdo pouziva velbloudi notaci u vseho (promenne, metody, tridy), nekdo oddeluje podtrzitky atd. a nekdo dokonce pouziva i prefixy pro oznaceni druhu promenne - I jako interface, C jako class, O jako object, V jako variable (prim. dat. typy).
all:nicmene na jednom GDS v Brne kde nejmenovany tym nezvislych vyvojaru predvadel svuj tool pro tvorbu map, pouzival programator tohoto nastroje pojmenovavani fci programu jako "chapadelnik", "chobotnice" atd. :) - popisne, ale zcela mimo:) nakonec se mu to tak libilo ze tyto nazvy prenesl i do menu aplikace, takze level designeri z toho byli trochu vydeseni:)
richard: predevsim by v OOP navrhu nemely byt zadne takove globalni (viditelne mimo rozsah tridy) promenne - porusuje to zakladni princip zapouzdreni dat, pokud se bavime o prim. dat. typech. pro tridy pak plati rizeni pristupu pomoci balicku ci nejakeho jineho systemu daneho jazyka.