Programovani: Nazvy pracovnich promennych (diskuse)

[klusik]

Ahoj, v PHP používám:

na smyčky klasické $i

na pole nemám nic "specifického"

na výběry používám něco jako:

$sql_chocolates = "SELECT cacao, nameOfChocolate, isDia FROM chocolates WHERE cacao>70";
$data_chocolates = mysql_query($sql_chocolates);
if (mysql_num_rows($data_chocolates))
{
  while ($chocolates = mysql_fetch_array($data_chocolates))
  {
    echo "Name of chocolate is ".$chocolates['nameOfChocolate']." and contains ".$chocolates['cacao']." % of cacao. And it is ".getNotIfNot($chocolates['isDia'])." good for diabetics.";
  }
}

;) ;) Je to trošku vykonstruovaný příklad, tak se omlouvám za funci getNotIfNot, ale ... řekněme, že vrací string "not", pokud je parametrem false ;)

[Drum Bass]

:) a pouzivate nejake automaticke doplnovani? Ptam se proto, ze ty nazvy pouzivate docela dlouhe, me by to po chvili nutilo to zkracovat pokud bych tedy nemel automaticke doplnovani. Osobne pouzivam Kate, ten automaticke doplnovani umi tak, ze si pamatuje co je jednou napsano a je schopen to doplnit. Tedy ne konkretni slovnik trebas vsech funkci PHP ale doplnil by libovolne slovo, ktere se uz do souboru (zdroje) napsalo - slovnik se tedy vytvari vlastnim psanim.

To je taky jeste druha vec, jak clovek pojmenovava promenne. Treba ten muj zpusob - z toho nikdo nepozna na co to je, pokud to je nekde dal v kodu. Z $chocolates je daleko lip poznat co tam asi bude, narozdil od meho $arow :D

Ohledne vykonstruovaneho prikladu, to jeste nic neni:) To ja vykonstruoval daleko vetsi brutus:

function Service_Distribute_CopyCMSData_PrintConfiguredProjects() { ... }

funkce vypise napovedu se seznamem projektu u nichz si vyvojari mohou sesynchronizovat data z produkcniho serveru na vyvojovy server za ucelem testovani na vyvojovem serveru. Hrozny nazev :)

[________________]

Ja používam čo najdlhšie názvy identifikátorov vačšinou viac slovné, aby bolo hneď každému jasné o čo sa v kóde jedná.... V PHP a Jave používam camelCase lexikálne konvencie, v C# alebo F# PascalCase u public a protected členov tried a camelCase u private členov tried a lokálnych premenných. V Delphi a VB.NET používam PascalCase u všetkých identifikátorov. Jednoslovné názvy premenných používam len výnimočne.

Čo sa týka automatického doplňovania syntaxe tak používam Visual Studio, intelli sense je v dnešnej dobe samozrejmosť, ušetrí to kopec času a teda aj peňazí. Každý programátor by sa mal naučiť používať IDE(VS, NetBeans) ak sa chce udržať v konkurencii.

[klusik]

Jsem zjistil, že všude to dělám tak nějak intuitivně jinak; v céčku jedu_pres_podtrzitka, v javěJenPřesCCase, v PHP tak nějak oboje ;)

Jinak s tím, že by se měl každý naučit používat IDE souhlasím i nesouhlasím (ať žije Schrodinger ); prostě je fajn to používat, ale nemělo by to být to jediné, co člověk umí. Občas potřebuju něco napsat na vzdáleném stroji třeba ve VIMu a když to není nakonfigurované, tak prostě musím vědět, jak se co píše, jak se píše třída v Javě, jak se píše to či ono, co Eclipse třeba sám doplní ;)

[klusik]

Automatické doplňování prakticky jen to z kate (v Kile to funguje taky, tak jsem na to přišel, právě...) ;) Ale většinou píšu v BlueFishovi, takže nic moc ;)

Tak $cc a $arrow může být dobré, ale spíš jen pro nějaké lokální cosi, já nevím -- iterátory a tak. Ale názvy věcí, které využívám globálně všude (funkce atd.), tak se snažím víceslovně přes camelCase.

Pěkný příklad ;) ;) To se musí nechat ;) ;) Ale zase to má alespoň nějaký význam, to moje "printNotIfNot()" to už je prostě jen "aby to tam bylo" -- normálně to nepoužívám, to jen do tutoho příkladu, aby bylo jasné, co to dělá, že ;) ;)

[____]

Nechtěl bych teda po vás ten kód číst.

[Drum Bass]

tak samozrejme ten kdo se v tom musi i po case vyznat jsem i ja sam a sam dobre vim, co to je se vyznat kolikrat i ve sve treba o hodne starsi, jeste ne tak dobre zdokumentovane praci. Jasne ze pouzivam treba komentare vsude kde to je vhodne, a tyhle zazite promenne pouzivam pouze jako temporary. V ramci kusu projektu pouzit neco jako promennou $cc na neco duleziteho by mohla byt pekna sebevrazda :)

[klusik]

Ale tak zase, od čeho jsou komentáře, žejo... buď budu psát funkce jako udělejMiVýpisVšechDomůZDanéhoKatastru(), nebo printCatastr(), ale v komentáři si musím napsat, co to dělá

[AHAHA]

Co dokazes vyjadrit v kodu, vyjadri v kodu. Komentare hniji prekvapive rychle.

[Grunt]

Už si někdy viděl backtrace s takovými nádherami (parametry ausgerechnet to samé) a pro jistotu aspoň tak s 50 framy? Lahoda. Pak možná změníš názor na komentáře.

[AHAHA]

Ano, vidam je kazdy den. Dobre/expresivne jmeno promenne/metody neznamena dlouhe jmeno. Nic z toho nesouvisi s komentari, proto nevim, proc bych na ne mel menit nazor.

[Grunt]

proto nevim, proc bych na ne mel menit nazor

No snad protože jsem to řekl já, ne?

[AHAHA]

Aha, ok :D

[klusik]

Já myslím, že sice jo, ale není to samospásné, jak se píše jinde; prostě strašně se mi líbí Javadoc, že to samo generuje atd., je to přehledné a tak, tohle umět PHP třeba, tak to dělám taky. Samozřejmě, můžu si v bashi nebo v čemkoliv napsat skript, kterej mi to vytvoří, dkyž to tak budu psát (a nepochybuji, že něco takového existuje...) ;) Ale beru "defaultní" možnosti ;)

[Josef Kufner]

PHP něco takového má a pak tuším, že i Doxygen to zvládá.

[randy]

ale ved to je uplne v pohode kod ;)) indovia z HP pouzivaju funkcie stylu OvRunNnmModelToolsJavaOptsLauncherClassPathOrDieVerbose()

tu je konkretny kod z HP OV NNMi

[qiRzT]

To se skoro nabízí otázka proč ještě vůbec psát kód tý funkce a nenapsat všechno rovnou do názvu V php by se určitě dalo vymyslet, jak to udělat, aby to fungovalo.

[klusik]

Tak to je dobrá hláška ;) ;)

[frEon]

v php nevim, ale v takovym lispu by to slo krasne.

[Josef Kufner]

V PHP to taky jde lehce. Možná ne přímo s funkcema, ale s metodama tříd určitě. A když to uděláš šikovně, tak to bude podle názvu hádat, co měla chybějící třída umět.

[frEon]

nj, googlil jsem, a ono to php ma uz neco podobneho jeko metoda method_missing v ruby. zajimave

[AHAHA]

... to php ma uz neco ...

jn, uz vic jak 6 let (stable verze)

[frEon]

nj, uz je to tak davno, co jsem to naposledy videl?

[musa]

Souhlas, to je hnus, navic formatovaci sablona "Matlal".

[ext3fs]

Ja jsem nikdy treba neprisel na chut zapisum jako:

Moje_Funkce()
MojeFunkce()
mojeFunkce()

ale vzdy a v kteremkoli jazyce (uz jen C, BASH, ojedinele PHP) pouzivam zapis

moje_funkce()

a nevidim jedinou vyhodu u tech prvnich trech.

[________________]

hlavne by sa mali používať oficiálne lexikálne konvencie jazyka, ktoré sú pre každý jazyk dané. a hlavne nepoužívať hungarian notation. potržítkovú syntax môžte používať v C++ pythone alebo Ruby, ale určite nie v Jave alebo C# programátor ktorý nedodržiava oficiálne lexikálne konvencie jazyka je prasa.

[Konqui]

Oficiální konvence Pythonu je třeba odsazovat mezerami. Odsazuju zásadně tabulátorem - jsem prase? Já si to zase myslím o ostatních - kdo odsazuje mezerami, je hovado...

[Michal Kubeček]

kdo odsazuje mezerami, je hovado...

Já si zase nemyslím nic lichotivého o člověku, pro něhož je to, že někdo preferuje jiný coding style než on, důvodem k nadávkám…

[Marián Kyral]

kdo odsazuje mezerami, je hovado...

Odsazuj si čím chceš. Já třeba taky odsazuji tabulátorem. Akorát, že místo \t se vloží mezery

Je celkem jedno jestli tabulátor nebo mezera. Nejhorší je zdroják, kde to programátor kombinuje dle nálady. U něj to vypadá OK, ale když si to otevře někdo, kdo má nastavený tabulátor na jiný počet míst, tak je z toho pěkný guláš

[xavier]

Tohle se občas objevuje ve zdrojácích k javě(např. třída String). Názvy metod jsou odsazené 4 mezerami a blok příkazů metody 1 tabulátorem s velikostí 8. Když jsem to viděl poprvé, tak jsem myslel, že v jejich konvenci neodsazují ten vnořený blok(mám nastavený tabulátor na 4 znaky). Tam to ale vypadá, že to je způsobené tím, že každý vývojář má nastavené něco jiného, protože se to liší u různých metod i v jednom souboru.

[masomlejn]

Proto bůh stvořil emacs a fortran-mode...

[Grunt]

hlavne by sa mali používať oficiálne lexikálne konvencie jazyka, ktoré sú pre každý jazyk dané

Ne, ne. Hlavně by se neměly vymýšlet hlouposti. To bych bral jako první dobré pravidlo.

[otec]

K čemu je dobré to zdvojování ($ii místo prostého $i)? Protože je to delší a hůř se to čte, nebo máš ještě nějaký jiný důvod? Jak už tu kdosi napsal - takový kód bych nechtěl číst.

[Drum Bass]

pouze zvyk, zadny specialni duvod to nema.

[Jan Drábek]

U forcyklů: i,j,k,l (jiný zvyk to komplikuje ostatných pro čtení), ii je fakt nepřehledné a jednoduše se přehlídne.

U foreach cyků: $result as $key => $value

U mysql dotazů $query, $result, $row

Zkracování vede jen ke zmenšení přehlednosti, sice se argumentuje leností, ale když umíte psát všemi deseti tak ta expresivita názvu opravdu převáží.

E.g. nerad bych s vámi na nějakých kódech. Do

[Marián Kyral]

Bohužel znám jednoho staršího pána, který používá proměnné i, j, k, l, ijk, kkk, kll, ikk, xyz, zzz. Opravovat něco v jeho kódu je fakt záhul. Musel jsem si ten zdroják celý přeformátovat, proměnné přejmenovat a až potom jsem se v tom vyznal.

[Michal Kubeček]

Zkracování vede jen ke zmenšení přehlednosti, sice se argumentuje leností, ale když umíte psát všemi deseti tak ta expresivita názvu opravdu převáží.

To se nedá takhle generalizovat. Když půjdu do extrému, opravdu si nemyslím, že označení řídící proměnné cyklu outermost_cycle_counter místo i nějak přispěje přehlednosti programu. A i jinak jsou pro mne příliš dlouhá jména proměnných (víc než nějakých 10 znaků) většinou spíš otravná, a to i když je nemusím psát, ale jen číst. Navíc to zvyšuje riziko nutnosti zalomit řádek a tím zdroják dále znepřehlednit.

[Tomáš]

opravdu si nemyslím, že označení řídící proměnné cyklu outermost_cycle_counter místo i nějak

A co teprv, když člověk zjistí, že to outermost není outermost, ale potřebuju přidat ještě jeden vnější cyklus, nebo naopak zjistím, že vnější cyklus nepotřebuju atd.

[pek]

Moje oblíbené jsou foo, bar a baz.

[osvc1]

dummy1,dummy2,...

[vita]

toto, titi, tata, tutu :)

[Milan Lajtoš]

A prečo nie názvy premenných, ktoré vyplývajú z kontextu? Ak iterujem cez foreach napr. zamestnancov s ich platmi, príde mi škoda nepoužiť pár $name a $salary. Pri obyčajnom for-cykle samozrejme premenné i, j, k, l.

Znovupoužívanie generických konštrukcií sa častokrát nevyplatí - či už môže dôjsť k chybe pri recyklovaní premenných, zlému skopírovaniu pri copy&paste (napríklad iterujem od 1 po n, kde by som mal od 0 po n-1) alebo rôznych iných.

Samozrejme netreba šetriť na názvoch funkcií/metód a skutočne popísať čo robia! Nie je nič horšie ako keď sa pozeráte na signatúru int doMagic(bool x, int bbz, int* pols). Z tohto zápisu nie je vôbec jasné, čo by to malo robiť.

Mojím pravidlom je snaha písať všetky názvy premenných, metód, tried, atď. anglicky. Tak ako ja neviem čo znamená premenná $koleTapja, tak niekto nemusí vedieť, čo robí funkcia upecHovno(bool sAlobalom).

[mkoubik]

Pokud používáš objektová jazyk, tak je IMHO "pomocná proměnná" (tj. ne instanční) signál že něco smrdí a je na čase refaktorovat. Podobně jako public atribut, private metoda, použití ifu, jediný boolean atribut metody, operátor new jinde než v továrničce a sposta dalších věcí. Pokud si k tomu člověk vypěstuje podvědomý odpor, tak si často ušetří nepříjemnosti.

[vulgární Nick]

No jasně, lokální proměnné jsou kontrearevoluční a podmínkové výrazy jsou buržoazní přežitek.

Děkujeme programátorům-teoretikům, že nás baví.

[Saljack]

Vyjímečně s tebou musím souhlasit. Celkem jsem nepochopil ten if, jak ho jako nepoužívat? Co je špatného na privátních metodách? Jediný boolean parametr, taky nechápu proč by se neměl používat.

[AHAHA]

"jediny boolean parametr" - obycejne to znaci, ze by se metoda mela rozdelit na dve metody (protoze asi dela dve ruzne veci).

[Saljack]

A co když je to jenom setter? Tak to psát dvakrát setTrue setFalse?

[AHAHA]

Je tam "obycejne", tedy ne vzdy. V pripade trivialniho setteru na jedne metode nevidim nic spatneho.

[xkucf03]

Já na tom nevidím nic špatného ani v těch netriviálních případech – naopak.

Proč psát:

boolean hodnotaPodleKtereSeRozhoduji = …;
Trida o = …;
…
if (hodnotaPodleKtereSeRozhoduji) {
    o.setAbcdTrue();
} else {
    o.setAbcdFalse();
}

místo:

boolean hodnotaPodleKtereSeRozhoduji = …;
Trida o = …;
…
o.setAbcd(hodnotaPodleKtereSeRozhoduji);

?

[Grunt]

Já zas především nechápu na co kvůli jednomu blbému přiřazení (jedna instrukce) budovat celý další stackframe.

[AHAHA]

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. V onech 97% kodu programu je totiz vykon uplne irelevantni (resp. je jedno, jestli zabere 10 nebo 1000 instrukci).

(Nehlede na to, ze kvuli setteru se stackframe velmi pravdepodobne budovat nebude)

[Grunt]

V onech 97% kodu programu je totiz vykon uplne irelevantni (resp. je jedno, jestli zabere 10 nebo 1000 instrukci).

Jo, zvláště když takový program 90% svého času nedělá nic jiného než jen furt něco volá (zrovna přiřazování asi bude dost frekventovaná akce a to vůbec nehledím na možnost, že může být v cyklu). A navíc se to musí fakt luxusně debugovat. V jakém duševní stavu musí člověk být aby implementoval přiřazování do proměnné voláním, to fakt nechápu.

Nehlede na to, ze kvuli setteru se stackframe velmi pravdepodobne budovat nebude

Pokud je to makro, tak ne. Pokud je to standardní volání implementované instrukcí call (a ne jmp) tak jo.

[Heron]

Pokud je to makro, tak ne. Pokud je to standardní volání implementované instrukcí call (a ne jmp) tak jo.

Java HotSpot strašně rád inlinuje. Takže to ve výsledku není ani call, ani jmp ale prosté přiřazení. Ve strojáku ze všech těch geterů a seterů nakonec zůstane jen práce s registrem (případně adresou).

[Grunt]

No i tak nechápu, jak může někomu něco takového přijít pohodlnější. Je to jako psát místo c = a + b c = add(a,b). V mém případě to tipuju buď na nějakou mentální degenerativní poruchu nebo malou hladinu alkoholu v krvi.

[AHAHA]

Ty to asi moc nechapes. Nikdo nepise c = add(a, b), ale stejne jako ty c = a + b. My se bavime o tom, proc je lepsi psat obj.setC(a + b) misto obj.c = a + b;

[Grunt]

BTW: To se musí fakt dost dobře debugovat když člověk očekává podle zdrojové řádky že je ve vlastním stack framu a přitom je furt na tom samém místě kde místo očekávaného call je mov.

[AHAHA]

Zvlastni, ale kdyz debuguju Javu nebo PHP, tak se s takovym problemem nesetkavam :D

[AHAHA]

Jo, zvláště když takový program 90% svého času nedělá nic jiného než jen furt něco volá (zrovna přiřazování asi bude dost frekventovaná akce a to vůbec nehledím na možnost, že může být v cyklu). A navíc se to musí fakt luxusně debugovat. V jakém duševní stavu musí člověk být aby implementoval přiřazování do proměnné voláním, to fakt nechápu.

Tak zkusim to jinak. Prirazovat promenne hodnotu neni zvykem ani v OOP. V OOP se setterem nastavuje atribut objektu. Ano, nekdy tento atribut je implementovan jako promenna, to te ale jako uzivatele nejakeho API nemusi a nema vubec zajimat. Jindy zase nastaveni tohoto atributu znamena spusteni nekolika metod jinych objektu, zapis na disk nebo treba vyhozeni vyjimky.

Dulezite je, ze tato implementace zmeny atributu se muze menit (a ver tomu, ze se skutecne meni). Co bys delal jako uzivatel GUI knihovny, ktera pro nastaveni vysky okna puvodne ve verzi 1.0 vyzadovala pouze zmenu nejakeho datoveho prvku a ve verzi 1.1 jeste vyzadovala prekresleni okna? S tvym pristupem bys musel na 1001 miste menit svuj kod, s OOP pristupem nemusis menit ani radku.

Pokud je to makro, tak ne. Pokud je to standardní volání implementované instrukcí call (a ne jmp) tak jo.

Bavime se o objektovych jazycich, zadny assembler. Tedy treba C++, ktere tu metodu bezpochyby inlajnne, C#, Java, Ruby, kde to bude zrejme zase uplne jinak ...

[kralyk z abclinuxu]

Já zas především nechápu na co kvůli jednomu blbému přiřazení (jedna instrukce) budovat celý další stackframe.

1) "Celý další stackframe" není nic tak hroznýho.
2) Není to "jedno blbé přiřazení", ale je to "jedno blbé přiřazení s kontrolou přístupu", i.e. nepředává se pouze přiřazovaná hodnota, ale i this.

Nehledě k tomu, že zavolání funkce je flexibilní - umožňuje dál kód rozšířovat. Například když změníš vlastnost objektu, může být užitečné, aby se ten objekt podle toho aktualizoval (voláním nějaké privátní funkce), což s prostým přířazením nepůjde.

Nadruhou stranu, samozřejmě, existují případy, kdy prosté přiřazení stačí... (například když má třída přiřazovací operátor :-P )

[AHAHA]

Pokud je to rozdeleni metod skutecne nepohodlne (jako v uvedenem pripade), tak neni problem si udelat metodu setAbcd(hodnotaPodleKtereSeRozhoduji), ktera obsahuje ten nepohodlny IF a vola setAbcdTrue() a setAbcdFalse().

Metoda by mela delat jen jednu vec.

[kralyk z abclinuxu]

Sorry, ale to je hovadina. Když už, tak by to mělo být obráceně; funkce setAbcdTrue() bude volat setAbcd(true).

[AHAHA]

A reknes proc? Proc by mela metoda (napr.) setVisible() okno zobrazovat i schovavat?

[kralyk z abclinuxu]

A reknes proc? Proc by mela metoda (napr.) setVisible() okno zobrazovat i schovavat?

Nic takového jsem neřekl.
Moje pointa byla v tom, že se obejdeme bez ifu.

Ale když už jsme u toho, tak ano, nevidím důvod, proč by měla být ta metoda rozdělena do setVisibleTrue() a setVisibleFalse().

[AHAHA]

Pripominam, ze se nebavime o trivialnich getterech a setterech, ktere pouze nastavuji nejakou instancni promennou.

Ted te ocituji, ale vymenim nic nerikajici jmena metod mym prikladem:

Sorry, ale to je hovadina. Když už, tak by to mělo být obráceně; funkce showWindow() bude volat setWindowVisibility(true).

Z toho mi jasne vyplyva, ze chces implementaci obou veci (zobrazeni i skryti) implementovat v metode setWindowVisibility().

A proc by to mely byt dve metody a ne jedna? Protoze metoda by mela delat jednu vec - kdezto setWindowVisibility() by v tvem podani implementovala dve ruzne (dokonce presne opacne) veci. Myslim, ze je docela zrejme, ze implementace skryti a zobrazeni okna budou pravdepodobne dost odlisne ...

[kralyk z abclinuxu]

Protoze metoda by mela delat jednu vec

Ale vždyť to ta metoda dělá jednu věc - nastavuje viditelnost okna. To, že vevnitř to řeší tak a tak je navenek jedno.

Myslim, ze je docela zrejme, ze implementace skryti a zobrazeni okna budou pravdepodobne dost odlisne ...

Proč by měly být (výrazně) odlišný? Windows manager taky pravděpodobně udržuje u každého okna všelijaký informace včetně boolean visible.

[xkucf03]

A co když těch stavů bude víc? Třeba minimalizované, maximalizované, ikonifikované, normální – pak budeš mít čtyři metody, aby „každá dělala jen jednu věc“? Jak bude takové API přehledné? Spousta metod – a jak poznáš, že zrovna tyhle patří k sobě a jiné dělají něco úplně jiného? A co když budeš třeba měnit stavy objednávky – někde asi budeš chtít mít číselník stavů, jakých může objednávka nabývat, abys to měl na jednom místě, ne? Změna stavu nebude triviální setter, bude dělat něco víc (třeba něco posílat, počítat, ověřovat), ale to ti nebrání, abys změnu stavu měl jako jednu metodu a jako parametr jí předával nějaký Enum – stav, na který se má změnit.

[AHAHA]

Mozna to nebylo z mych postu jasne, ale ja se tu snazim mluvit hlavne o konecne implementaci techto zmen atributu.

API at je maximalne pohodlne. Verejne metody muzou klidne zdanlive "obsluhovat" nekolik veci najednou (ale samozrejme rozumne), ale pak by tyto veci mely delegovat nebo rozdelovat ostatnim metodam.

Zkratka, snazim se rict, ze funkce uvedena nize je spatna:

function chytraFunkce($prepinac)
{
	if($prepinac == true) {
		...
		...
		spousta kodu
		...
		...
	}
	else {
		...
		...
		spousta kodu
		...
		...
	}
}

[xkucf03]

V takovém případě více méně* souhlas, jenže ono to často vypadá takhle:

function chytraFunkce($prepinac) {
	...
	...
	spousta kodu
	...
	...

	if($prepinac == true) {
		…trochu kódu…
	} else {
		…trochu kódu…
	}
	...
	...
	spousta kodu
	...
	...
}

nebo tam dokonce ani ten vnitřní if (…) není a jednoduše předáváš ten $přepínač někam dál.

*) i když někdy může být rozdělení na více metod kontraproduktivní – v případě, že se jedná o kód, který od odjinud volat nebudu.

[mkoubik]

V tom případě opakuji:

Pokud je v ifu jenom část metody, nešlo by upravit životní cyklus objektu, vyčlenit společné části a rozdílnost fáze v podmínce řešit polymorfismem?

[xkucf03]

a co z toho?

[AHAHA]

Jeste jsem zapomnel: ta pointa je spatne. V tvem pripade bude ten IF schovany uvnitr metody setVisible() (vzdyt o tom je tento thread!)

[kralyk z abclinuxu]

Nemusí to tak být. setVisible() může nastavit vnitřní proměnnou a zavolat update() a tam (ne)musí být if potřeba podle vlastností backendu. Zkrátka ten if by měl (imho) být co možná nejníž.

[vulgární Nick]

Rozhodně neplatí vždy. Raději třeba java.awt.Component.setVisible(boolean) než show() a hide().

[Michal Kubeček]

Takže když budu mít metodu, z níž se uprostřed pět procent buď provede nebo ne, tak mám napsat dvě skoro stejné a při každé změně v těch zbylých 95 procentech je obě stejně přepsat?

[AHAHA]

Takova metoda si velmi pravdepodobne zaslouzi kompletni refaktorizaci (hlavne rozdeleni).

[Michal Kubeček]

Určitě ne v plné obecnosti a pro mne osobně ani ve většině případů.

[AHAHA]

Nesmi se to brat jako dogma. Kdyz si potrebuji za par hodin zplacnout nejakou malickost, taky se nedrzim vsech "spravnych zasad". I refaktorizace stoji nejaky cas a nekdy se to jednoduse nevyplati ...

[AHAHA]

Co je spatneho na pomocne (neinstancni) promenne, privatni metode a pouziti ifu? Diky.

[:::]

ty ses teda dobrej jeliman... :))

jestlis v zivote neco naprogramoval (o cemz pochybuju ale stejne), mohl bys poslat nejakou ukazku ? rad bych se neco "priucil" ...

btw. jak treba vynasobis 2 matice bez pomocne neinstancni promenne? thx

[vulgární Nick]

Třeba nesnáší i pole a tvoří místo nich instanční proměnné jako arrayItem1, arrayItem2 a arrayItem3, ... :)

[:::]

jo to jedine. a pak to misto cyklu vsechno rucne rozepise... :)

to mkoubik: ta ukazna nemusi byt nic velkyho. staci par set radku na vysvetleni koncepce...

[vulgární Nick]

Nerozepíše to jen tak! Napíše si na to metody: iteration1, iteration2 ... iteration44563. Bude to pak přehlednější a lépe se to bude refaktorovat. :))

[mkoubik]

Poněvadž se tady vynořila horda chytrolínů, tak se to pokusim vysvětlit. Jednak tyhle pravidla pouze "naznačují, že je pravděpodobně něco špatně". Rozhodně je nelze brát dogmaticky, jenom je to impuls k zamyšlení. Druhak to platí pro objektový návrh architektury. Teď k jednotlivým bodům:

• Pomocné (kontextové) proměnné se samozřejmě hojně používají a leckde to má smysl. Např pokud je součástí nějakého algoritmu, ale ty se obvykle píší procedurálně (např to slavné násobení matic) a moje rady se tedy na ně nevztahují. Příklad kde to smrdí je např když v rámci jedné metody vygeneruješ data, uložíš do proměnné a pak s nimi dál pracuješ - stojí zato popřemýšlet o rozdělení metody
• Public atribut Zamyšlení: "opravdu chci, aby se mi v tomhle atributu jiné objekty jakkoliv hrabaly, nehodili by se setter?"
• Private atribut Zamyšlení: "Aha, tady máme vyčleněnou společnou funkčnost (která není součástí API) několika metod jedné třídy, neměla by to být public metoda jiné třídy (není porušen single responsibility princip)? Neměla by ta metoda public? Jak tu metodu budu testovat?"
• Jediný bool parametr/if/switch Zamyšlení: "Nevykonává tahle metoda 2 oddělitelné funkce? Pokud je v ifu jenom část metody, nešlo by upravit životní cyklus objektu, vyčlenit společné části a rozdílnost fáze v podmínce řešit polymorfismem?". Samozřejmě existuje spousta legitimních použití ifu a bez něj by to nešlo. Třeba ten setter. Kombinace bool parametru a ifu v metodě nicméně smrdí a to tím víc, čím větší část metody je v tom ifu (Pozor: "smrdí" neznamená "je špatně").
• Operátor new Zamyšlení: "Opravdu musím ten objekt vytvářet zrovna tady? Co když budu chtít vyměnit implementaci v celé aplikaci? To budu v kódu hledat new ImplementationA() a nahrazovat za new ImplementationB()? A co mockování (např připojení k databázi) v testech? Nebylo by lepší vytvářet instance na jednom místě? Třeba v IoC kontejneru nebo ServiceLocatoru?"

Nevim jestli jsem toho naprogramoval hodně nebo málo, ale tyhle návyky jsem si vybudoval praxí (nejsou to nějaký akademický kecy). Čím objektovější jazyk člověk používá, tím dřív k tomuhle dospěje. Pokud někdo píše algoritmy v céčku, tak ho to moc trápit nemusí (a chápu že mu to přijde k smíchu) a spokojí se s tím že bude celej život čučet na int i,j,k;.

[vulgární Nick]

Zvláští, před chvíli tady "něco smrdělo", teď tu "možná něco smrdí, ale spíš ne"...

Jinak děkujeme za výcuc z nějaké knížky o programování pro začátečníky.

P. S.: Něco tady fakt smrdí, není vám to trapné?

[mkoubik]

"Něco smrdí" znamená "možná není správně", "možná něco smrdí" tudíž znamená totéž. Jinak přijde mi, že v knížkách pro začátečníky se nějaké to if, while a Auto extends DopravniProstredek dočteš hnedka z kraje. Názory, které tu prezentuju jsou (bohužel) spíš taková avantgarda, o výuce programování ve školách radši nemluvě.

[AHAHA]

Existuje neco, co nesmrdi?

[mkoubik]

Ne, existují pouze věci které smrdí tak málo, že se tím nemá cenu zabývat.

[mkoubik]

Jinak, nejsem jedinej programátor teoretik, kterej se ohání akademickejma žvástama. Kdysi jsem četl blog od nějakého ruby programátora, kde byly podobné best-practices pěkně vysvětlený a ne a ne to teď vygooglit. Tohle mi přišlo do cesty a je to na stejný téma.

[AHAHA]

Pridam jeste jednu vec: dedeni trid smrdi, protoze je vetsinou lepsi uprednostnit kompozici pred dedicnosti.

Takove flamy jsou zbytecne - vetsinou z nich vyjde, ze vzdy zalezi na konkretnim pripade a nema cenu kolem sebe machat ucebnicovymi pouckami. Verim, ze i na takove GOTO se najde use case, ve kterem je vhodne a tedy se neda obecne oznacit a priori za spatne.

[mkoubik]

Právě tak jsem se to snažil podat - je užitečné mít reflex "když vidím public atribut, tak to se mnou škubne a zamyslim se" reflex "když vidím public atribut, změním ho na private a dopíšu setter/getter" je k ničemu.

Stejně tak když vidíš před sebou na chodníku psí hovno, tak tě na to podvědomí upozorní a reflexivně se mu vyhneš, i když určitě existuje situace kdy by se hodilo do něj šlápnout.

[Heron]

Právě tak jsem se to snažil podat - je užitečné mít reflex "když vidím public atribut, tak to se mnou škubne a zamyslim se" reflex "když vidím public atribut, změním ho na private a dopíšu setter/getter" je k ničemu.

Upřímně řečeno lepší by to bylo naopak. Atributy psát vždy jako private a k nim (třeba automatické, triviální) get/set metody a v případě opodstatněného použití jej předělat jako public.

[AHAHA]

Jiste, on ale zrejme mluvi o cizim/starem kodu ("kdyz vidim public atribut ..."). Na vytvoreni public atributu musi mit clovek hodne dobry duvod ...

[Michal Vyskočil]

Upřímně řečeno lepší by to bylo naopak. Atributy psát vždy jako private a k nim (třeba automatické, triviální) get/set metody a v případě opodstatněného použití jej předělat jako public.

Vůbec nejlepší by bylo, kdyby Gosling tolik nečetl manuál k C++ a Javu udělal více podle Smalltalku. Tam jsou všechny členské proměnné v Java terminologii protected a metody public, což je taková úroveň oprávnění, kterou obvykle programátor potřebuje.

[mkoubik]

V ruby jsou všecnhy atributy private, ale zas je tam extrémně jednoduché generování getterů a setterů.

[Kvakor]

Verim, ze i na takove GOTO se najde use case, ve kterem je vhodne a tedy se neda obecne oznacit a priori za spatne.

Dobrým příkladem jsou linuxové moduly, kde se používají skoky pro zjednodušení kódu při inicializaci tak, aby se v okamžiku, kdy něco nevyjde, nemusleo složitě řešit to, co už bylo inicializováno/naalokováno a co ještě ne. Ne že by to nešlo řešit bez skokú, ale buď by to znamenalo držet si stav (což zabíra zbytečně paměť) nebo použít vnoření, která se ale mohou při větším množství stát velmi, velmi nepřelednými a člověk pak při čtení kódu vypadá jak ten zlý pes ze Simpsonů .

[xavier]

Přednáška k návrhu metod.

[Radek Miček]

Pokud to jde, pracovní proměnné nepoužívám.

[kolcon]

asi tak, ve vetsine pripadu si vystacim s $_

[kralyk z abclinuxu]

Jak by řekl přednášející (už nevím který):
int moje_promenna_kterou_jsem_si_definoval_po_prednasce_z_programovani_ktera_na_me_udelala_velky_dojem_1;
int <dtto>_2;

[Luk]

Jen mě tak napadlo - má tato konstrukce:

while ($cc=each($nejake_pole)) 
  { /* nejaka cinnost s $cc["key"] a/nebo $cc["value"] */ }

nějakou zvláštní výhodu oproti této:

foreach ($cc as $key => $value)
  { /* nejaka cinnost s $key a/nebo $value */ }

(používám právě tuto druhou cestu a rád bych věděl, jestli ta první není v něčem lepší)?

[Luk]

Samozřejmě místo $cc má být u druhé konstrukce $nejake_pole, ale to snad každý pochopí.

[AHAHA]

Prvni verze pravdepodobne zadnou vyhodu nema, je IMHO jen mene prehledna a znacne pomalejsi. each() se hodi na jine veci.

[asfethan]

Po vas by som teda nechcel (o/u)pravovat nejaku aplikaciu. Nazvy podaktorych premennych su nelogicke, ostatne zase prilis usporne.

Ja mam tiez zavedene nejake pravidla pri svojej tvorbe a sice:

$x__abcd

kde x moze by b,m,s,a,i,r tzn. bool, mixed, string, array, integer, resource...

abcd je zase nazov, ale taky aby bolo hned jasne o co ide...

Priklad:

  $r__db_connection = mysql_connect($s__host, $s__user, $s__pass);
  mysql_select_db($s__database, $r__db_connection);

  $r__products = mysql_query("SELECT ...", $r__db_connection);

  for ($i__row = 0; $i__row < mysql_num_rows($r__products); $i__row++)  {

    $a__product      = mysql_fetch_array($r__products);
    $s__product_name = $a__product['product_name'];

  }

  // mysql_close, unset a atd...

  exit(0);

[Michal Kubeček]

To je v podstatě jen variace na již zmíněnou maďarskou notaci, jen je tam navíc to zdvojené podtržítko, které IMHO na přehlednosti moc nepřidá (kdyby bylo jedno, tak možná).

[kralyk z abclinuxu]

Není mi jasný, proč někdo, kdo má nutkání mít v názvu proměnný i její "typ", používá slabě typovaný jazyk?

[xkucf03]

+1

[Michal Kubeček]

IMHO je k tomu donucen okolnostmi. Napadá mne (a) kombinace neznalosti a lenosti (nic jiného neumí a učit se nechce), (b) nedostatek odvahy (nevěří, že by něco jiného zvládl), (c) potřeba přizpůsobit se prostředí (na daném hostingu nic jiného než PHP použít nelze). Nebo prostě jiné výhody převažují - mně třeba taky na PHP spousta věcí vadí (a absence typové kontroly by byla na předních místech), ale jednoduché věci je často prostě nejjednodušší napsat v něm.

[asfethan]

Nie netrpim ziadnym neduhom ktory je popisany v bodoch a,b,c. Riadok na ktorom su tieto body spomenute by mohol byt uplne kludne vymazany, nepridava ziadnu informacnu hodnotu, skor naopak (zavana mi to pokusom o urazku a ukazku prvotriednej arogancie).

"IMHO je k tomu donucen okolnostmi nebo prostě jiné výhody převažují" - kludne stacilo iba toto napisat...

[Michal Kubeček]

Pokud v tom hledáte urážku, je to váš problém, ne můj.

[asfethan]

Ked sa naucite pouzivat iny operator ako "==" mozno to pochopite

[kralyk z abclinuxu]

Teď bych zas mohl já hrát uraženýho
Jinak samozřejmě já používám i jiný operátory, ale taky používám silně typovaný jazyk.

[asfethan]

Tak ja ovladam viac jazykov a vsade sa snazim mat nejaku stabnu kulturu. Naviedol ma na to pan Herout pomocou jeho knihy Ucebnice jazyka C (ked som sa pred 6timi rokmi tento jazyk ucil). Odhliadnuc od toho ze PHP je naozaj slabo typovany jazyk, zvysuje tento navyk u mna prehladnost a efektivitu. Nehovoriac o tom ze ked nieco riesim totalne unaveny (ci uz fyzicky, psych., alebo splocensky) dokazem sa vyvarovat niektorym chybam :P

[Grunt]

Naviedol ma na to pan Herout pomocou jeho knihy Ucebnice jazyka C (ked som sa pred 6timi rokmi tento jazyk ucil). …zvysuje tento navyk u mna prehladnost a efektivitu. …dokazem sa vyvarovat niektorym chybam.

Jsem jediný u koho tyto bojové výkřiky ve stylu

vyvolávají jemný úsměv na tváři a jediný co si myslí, že se tu zas řeší leda tak kraviny? To je snad úplně jedno jak to píšeš, ne? Pokud nejsi pako a nebo fakt v nějaké ovlivnění smyslů, tak snad dovedeš rozumně pojmenovat nějaké proměnné a pokud není pako (a nebo též nějak ovlivněn) ten co to po tobě bude číst, tak to snad bude i schopen pochopit. Jestli je to už jazyk interpretovaný nebo překládaný a nebo silně tipovaný nebo slabě tipovaný a nebo rudý nebo růžový.

[Michal Kubeček]

Aspoň že nenapsal, že to zvyšuje efektivitu o 12.6 procenta. :-)

[Grunt]

Jsem hledal mnohem rýpavější plakátek, ale radši jsem to nechal být nebo by se tady ještě na mně mohl někdo rozzlobit.

[Grunt]

tipovaný

No dobře. Jdu spát.

[Michal Kubeček]

Na tom něco bude, taky to zkusím.

[Kvakor]

Taky si myslím, že v danném přípasdě je to zbytečný "overkill", protože jediné problémy s typovostí, se kterými jsem se v PHP setkal, byly s poli a s bitovými operace. A na to stačí jen dvě relativně jednoduché věci: ujistit se, že pole (občas resource nebo objekt) je opravdu pole a ne skalár, na což jsou funkce, a explicitně přetypovat číslo na celé. Prakticky tedy stačí rozlišovat jen pole, resource/objekt a zbytek, těch několik specialit (jako výše zmíněné bitové operace) je jednodušší ošetřit přetypováním.

[asfethan]

Ide o to ze ked niekto cita vas kod, hned vie co je co a kde ma co ocakavat. Bez nejakej specialnej analyzy. Netvrdim ze moj system je najlepsi, ale mne sa s nim velmi dobre pracuje (zvysuje aj efektivitu mojej prace) a vim je velmi silny editor, preto mi to ako overkill nepride, prave naopak.

[__dark__]

Ty 2 podtrzitka, to je opravdu skvost. Ale chapu, ze chces byt unikat :)

[__dark__]

Hruza

Zdvojovani standardnich promennych nechapu (proc ne proste i, j?, cc mi nesedi uz vubec). Divnou polohu zavorek taky nechapu, a proc neodsazovat u funkce taky ne. Secteno a podtrzeno - nelibi se mi tvuj styl :)

[Luk]

Divnou polohu zavorek taky nechapu, a proc neodsazovat u funkce taky ne.

Tohle je to poslední, co by se mělo řešit. Běžně se používají různé styly, každému vyhovuje něco jiného.

[__dark__]

Různé styly chápu, ale nevidím smysl v tom, vymyslet si svůj vlastní, který od všech zažitých odbočuje. PS: Komentovat ostatní věci nemám sílu:)

[frEon]

me prijde kazda poloha zavorek divna, pokud neni lispova

[Josef Kufner]

indent -kr -i8 -l120