Pravidla pro pojmenování proměnných

[Sten]

There are only two hard things in Computer Science: cache invalidation and naming things.
- Phil Karlton

There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors.
- Leon Bambrick on Phil Karlton's quote

[Reklama]

[javaman ((]

Vás bych z nevodně zvolené úrovně abstrakce nepodezříval. Neberte to proto osobně, opravdu se vám v praxi osvědčilo, abstrahovat takto? Jak to pak řešíte, když aplikaci je potřeba použít v jiném prostředí. Místo komínů servisovat třeba vysokou pec?

Ne zrovna vysokou, ale pec ano. Dlouhou. Když i v programovém menu jsou ty položky odděleny a parametry servisu obou objektů jsou zcela jiné, tak se vyplatí je mít ve dvou třídách místo jedné god-class, ve které by byla hromada rozboček jen kvůli tomu, že jsem tu třídu nerozdělil. Když jsem pak přidával sušárnu, která měla opět jiné parametry, tak jsem na předchozí dvě třídy ani nesáhl a napsal jsem třetí. Do menu jsem pak jen přidal další řádek a bylo vymalováno.

Dělám to takhle už dlouho. Třídy díky tomu vychází jednoduché, mají shodné rozhraní a proto mohu využívat polymorfismus. Uvnitř jsou samozřejmě specializované pro konkrétní účel. Pokud přijde změna zadání, změním jen tu třídu, které se to konkrétně týká nebo ji při brutální změně vyměním za novou - tedy při změně, která by mohla negativně ovlivnit chování aplikace u jiného zákazníka.

Takže žádná duplicita kódu? Protože tohle zní zase jako jedna z tvých pohádek. Ale pokud máš 50 tříd s kompletně rozdílným kódem, tak v pohodě, to máš asi štěstí na projekt

[Kit]

Takže žádná duplicita kódu? Protože tohle zní zase jako jedna z tvých pohádek. Ale pokud máš 50 tříd s kompletně rozdílným kódem, tak v pohodě, to máš asi štěstí na projekt

Zase šíříš FUD, co?

Prostě si každou třídu poskládám z takových komponent, jaké jsou pro splnění mise potřebné. Přece v nich nemusím udělat veškerou práci. Říká se tomu dekompozice - co nejvíc práce deleguji do komponent.

[aa]

Máš snad nějakou konkrétní připomínku? Česky nebo anglicky?

Konzistentne. Nemam nic proti cestine, ak je vsade:

Kód: [Vybrat]

#zahrn<stdvv.h>

cis hlavni(cis argpocet, znak* argvektor[]) {
  vypisf("Ahoj svete!\n");
  vrat 0;
}


[aa]

Takže žádná duplicita kódu? Protože tohle zní zase jako jedna z tvých pohádek. Ale pokud máš 50 tříd s kompletně rozdílným kódem, tak v pohodě, to máš asi štěstí na projekt

Zase šíříš FUD, co?

Prostě si každou třídu poskládám z takových komponent, jaké jsou pro splnění mise potřebné. Přece v nich nemusím udělat veškerou práci. Říká se tomu dekompozice - co nejvíc práce deleguji do komponent.

Pri naklikanom GUI sa vygenerovany kod opakuje, ked nemas vlastne naklikavatko, ktore by dokazalo spravit nieco rozumnejsie.

Toto mi pripomina, ako som si skusal navrhovat implementaciu sietoveho stacku - perfektne zapuzdrenie, komponenty, vrstvy. Tak, ako sa to uci na skolach. A potom som chcel z prezentacnej vrstvy (klikatko) pristupovat k takym udajom ako IP adresa, MAC adresa, packet loss a chcel som mat moznost sa odpojit alebo pripojit. A zrazu su z Kitovej perfektnej dekompozicie spagety, lebo uzivatel chce ovela viac ako je niekde urcene.

[Reklama]

[Kit]

Máš snad nějakou konkrétní připomínku? Česky nebo anglicky?

Konzistentne. Nemam nic proti cestine, ak je vsade:

Kód: [Vybrat]

#zahrn<stdvv.h>

cis hlavni(cis argpocet, znak* argvektor[]) {
  vypisf("Ahoj svete!\n");
  vrat 0;
}


Hezký. S jistou sadou #define by to mohlo i fungovat

Vždycky jsem si užíval toho, že klíčová slova byla anglicky a názvy objektů česky. Dobře se mi to čte, snadno odliším klíčová slova od vlastních objektů a metod. Pak přišla móda vše pojmenovávat anglicky. Částečně jsem se přizpůsobil, ale názvy objektů a tříd IMHO stále nemá smysl překládat, pokud ten projekt není mezinárodní.

Kdokoli si ty objekty může přejmenovat podle sebe. V dnešních IDE to má za chviličku.

[Kit]

Pri naklikanom GUI sa vygenerovany kod opakuje, ked nemas vlastne naklikavatko, ktore by dokazalo spravit nieco rozumnejsie.

Toto mi pripomina, ako som si skusal navrhovat implementaciu sietoveho stacku - perfektne zapuzdrenie, komponenty, vrstvy. Tak, ako sa to uci na skolach. A potom som chcel z prezentacnej vrstvy (klikatko) pristupovat k takym udajom ako IP adresa, MAC adresa, packet loss a chcel som mat moznost sa odpojit alebo pripojit. A zrazu su z Kitovej perfektnej dekompozicie spagety, lebo uzivatel chce ovela viac ako je niekde urcene.

Nevidím důvod, proč bych měl nějaký kód opakovat pomocí nějakého klikátka. DRY.

Nemohu za to, že sis ten projekt špatně navrhl.

[Kája]

To nejde takhle říct, existuje několik konvencí pro každý jazyk, některé jsou více preferované, některé méně. Každý projekt má většinou svůj code style.

Např. v C existuje konvence uvádět jako suffix datový typ, např. count_u8. Člověk si napoprvé řekne, že je to zbytečnost, ale časem to ocení, lépe se orientuje v kódu.

[pavlix]

Např. v C existuje konvence uvádět jako suffix datový typ, např. count_u8. Člověk si napoprvé řekne, že je to zbytečnost, ale časem to ocení, lépe se orientuje v kódu.

Já to teda neocením ani časem.

[Radovan.]

Např. v C existuje konvence uvádět jako suffix datový typ, např. count_u8.

Ve FORTRANu se automaticky určuje typ proměnné prvním písmenem jejího názvu, takže I,J,K,L,M,N jsou celočíselné, ostatní reálné. Ale nadeklarovat si můžeš co chceš. Proto:

"GOD is REAL (unless declared INTEGER)"

[aa]

Nevidím důvod, proč bych měl nějaký kód opakovat pomocí nějakého klikátka. DRY.

To sa lahko povie, ale zarovnavat pixely v nejakom xml alebo v kode, pripadne pisat si rucne parser nie je ziadna zabava. Tak pouzijem Eclipse a jeho modelling tools, kde si naklikam co chcem a to vygeneruje dost hnusny kod, ktory sa opakuje. To neopakujem ja, to robi za mna IDE.

Ako zariadis DRY? Mas vlastny Eclipse?

[Kit]

Nevidím důvod, proč bych měl nějaký kód opakovat pomocí nějakého klikátka. DRY.

To sa lahko povie, ale zarovnavat pixely v nejakom xml alebo v kode, pripadne pisat si rucne parser nie je ziadna zabava. Tak pouzijem Eclipse a jeho modelling tools, kde si naklikam co chcem a to vygeneruje dost hnusny kod, ktory sa opakuje. To neopakujem ja, to robi za mna IDE.

Ako zariadis DRY? Mas vlastny Eclipse?

Ne. Mám Vim. Ten mi hnusný kód nedělá.

[alda]

Nevidím důvod, proč bych měl nějaký kód opakovat pomocí nějakého klikátka. DRY.

To sa lahko povie, ale zarovnavat pixely v nejakom xml alebo v kode, pripadne pisat si rucne parser nie je ziadna zabava. Tak pouzijem Eclipse a jeho modelling tools, kde si naklikam co chcem a to vygeneruje dost hnusny kod, ktory sa opakuje. To neopakujem ja, to robi za mna IDE.

Ako zariadis DRY? Mas vlastny Eclipse?

Ne. Mám Vim. Ten mi hnusný kód nedělá.

A ja si naivne vzdy myslel, ze hnusny kod dela programator .. a on to ma na svedomi Editor

[Screemy]

Libí se mi dnešní doba programátorska + IDE ...

Programátor bez IDE nevytvoří projekt.

A když ho vytvoří v IDE (krásně dříve řečeno "nakliká") má hnusný kód ... (logicky)

To je okecáváno tím, že to generuje IDE, ale přitom 80% programátorů ani neví, co to to IDE vygenrovalo natož co to dělá a jak by to měli udělat bez IDE.

Líbí se mi jak Kit razí "svůj styl" jelikož osobně to mám stejně ;-)

[Ivan Nový]

Libí se mi dnešní doba programátorska + IDE ...

Programátor bez IDE nevytvoří projekt.

A když ho vytvoří v IDE (krásně dříve řečeno "nakliká") má hnusný kód ... (logicky)

To je okecáváno tím, že to generuje IDE, ale přitom 80% programátorů ani neví, co to to IDE vygenrovalo natož co to dělá a jak by to měli udělat bez IDE.

Líbí se mi jak Kit razí "svůj styl" jelikož osobně to mám stejně ;-)

Za 10 let bude místo IDE podstatné části programu generovat AIDE (Artificial Inteligence Development Environment), vy budete jen připravovat trénovací data a počáteční šablony nutné ke spuštění evolučních algoritmů a aby byla možnost ovlivnit proces hledání řešení pomocí AIDE, ve výsledném kódu se pak stejně nikdo nevyzná a ani ho nebude zkoumat, AI bude generovat rovnou kód pro VM. Nebudete programátor, ale mentor stroje a k mentorování vám bude sloužit AIDE.