Na čem skutečně záleží při programování (diskuse)

[pavlix]

Chmm, krásný citát.

I když špatnýho programátora ani ty konvence nezachrání. A jednoduchost? Pokud v té jednoduchosti nedokáže vyjádřit to, co potřebuje, tak je stejně v háji.

Takže... mezi lidma, kteří opravdu umí, může tenhle citát fungovat. Jinak je to jen výkřik do tmy (vytržený z kontextu).

[zoul]

Já jsem v posledních dvou letech došel k velice podobnému názoru. Je dobré si uvědomit, že výborného programátora nedělá špičkový intelekt. Je dobré si uvědomit, že kdykoliv člověk píše něco hodně chytrého/složitého/magického, většinou si na sebe šije hroznou past.

Tahle myšlenka samozřejmě nikoho programovat nenaučí. Ale pokud má někdo zájem o svůj obor a chce se zlepšovat, může ho velice přínosně upozornit, kudy cesta nevede.

[pavlix]

Tahle myšlenka samozřejmě nikoho programovat nenaučí

Nejsem si jistý, jestli reagujeme na stejnou myšlenku. Napadají mě dvě možnosti:

1) Výborný programátor se obejde bez intelektu, stačí, když dodržuje pořádek.

S takovou myšlenkou nemůžu souhlasit, pokud slovem programátor myslíš stejnou profesi (případně koníček) jako já (tzn ne toho, kdo napíše pár řádků html, pár řádků php a nějaký ten SQL select).

2) Výborný programátor by měl umět vyjadřovat věci jednoduše a konzistentně.

S tím naopak souhlasím velmi. Jsou to dvě důležité vlastnosti v jakémkoli oboru, kde lidé na něčem spolupracují.

Bohužel text citátu spíš vypadá jako ta první varianta.

[zoul]

Aha, tak to jen chápeme jinak ten citovaný text. Bez intelektu se neobejde žádný programátor, jen je důležité si uvědomit, že chytré řešení != dobré řešení a hodně chytrý programátor != hodně dobrý programátor. Takhle jsem ho pochopil já a takhle s ním všema deseti souhlasím.

[xkucf03]

To mi připomíná jednu diskusi tady o formátování a vůbec stylu psaní, bohužel už nevím, jak se jmenovala. Tam jsem se snažil vysvětlit, že kód napsaný na co nejméně řádek není nejšťastnější stejně jako „geniální“ kód, který plně využívá vyjadřovací možnosti jazyka, protože mu často rozumí jen jeho autor („génius“), ale ostatním to přidělává práci. Při týmové práci se proto někdy víc hodí „primitivnější“ a „neefektivní“ (šlo by to napsat úsporněji, na méně řádek) řešení a taky jednodušší jazyky (Java vs. C++).

Na druhou stranu, když člověk nedělá v týmu nebo má kolem sebe lidi na stejné úrovni (tzn. budou jeho kódu rozumět), tak nevidím důvod, proč se chytrým řešením vyhýbat. (jen to musí být skutečně chytrá řešení a ne prasárny a ošklivé hacky, které sice ušetří nějaký ten řádek teď, ale sníží přehlednost a udržovatelnost kódu v budoucnosti)

[zoul]

C++ mě napadlo taky. V práci dělám v Objective-C (iOS) a jsem za něj moc rád, málokdy se v něm podaří vyrobit nějakou ošklivou chybu. (Například takovouhle.)

[pavlix]

Takhle jsem ho pochopil já

Možná je citát právě ukázkou neschopnosti vyjádřit se jasně a srozumitelně, takže je v důsledku svou vlastní kritikou (nebo je jen vytržený z kontextu).

[pht]

1) Výborný programátor se obejde bez intelektu, stačí, když dodržuje pořádek.

Přesněji řečeno je to tak, že záleží víc na tom druhém než na tom prvním.

Můžete být dobrý/průměrný/slabý programátor s dobrými návyky, ale jak je nemáte tak jste k ničemu.

tzn ne toho, kdo napíše pár řádků html, pár řádků php a nějaký ten SQL select

Na tomhle naopak záleží ze všeho nejmíň.

[deda.jabko]

ja se v posledni dobe nejak drzim principu KISS... jak to neni jednoduche, bude to asi blbe.

napr. v dusledku toho, mam jeden projekt, ktery i pres pomerne konstantni pocet radku kodu, roste co do funkcionality.

jeste dobra indicie je vizualni stranka kodu... pokud se mi (muj) kod ,,nelibi'' a nejde to udelat hezci... taky je to priznak toho, ze neco bude spatne.

[zoul]

…jak to neni jednoduche, bude to asi blbe.

Přesně. Dřív jsem míval dojem, že je třeba příslušná část kódu opravdu těžká, že to jednodušej udělat nepůjde. Kdykoliv si dneska uvědomím, že se s něčím hodně peru, začnu přemýšlet, jestli nedělám nějakou kravinu. Většinou jo :)

[Robo]

presne tak to vidim aj ja; dokial si clovek kodi sam pre seba, tak to ma na haku, ale akonahle musi pracovat v teame a citat kody po inych tak to uz je ine (i ked plati to aj vtedy, ked ma clovek citat sam po sebe kod, ktory pisal niekedy pred rokom )

[Milan Horák]

Nemůžu si pomoct, ale nemůžu souhlasit.

[zoul]

V čem? (Nehádám se, zajímá mě diskuse.)

[Milan Horák]

Asi to vidím podobně jako kolega výše (viz).

[Milan Horák]

A ty hlasy v mé hlavě mě sice občas iritují, ale většinou mi jeden z nich dobře poradí

[Podchaljuzin]

Na plate ktory za svoje vytvory dostavas...

[zoul]

…jistě je myšleno uspokojení z tvorby, pravda? :)

[Karel Zak]

http://en.wikipedia.org/wiki/KISS_principle

[Zdenek]

Ten ja rad a taky "never touch a running system"

[pht]

"never touch a running system"

Zrovna tenhle je dost na hovno.

[manasekp]

Skutecne zalezi na tom jestli program dela to co zadavatel chce takze tvurce za nej dostane zaplaceno tolik aby pokryl naklady a jeste mu neco zbylo.

[zoul]

Tady bylo programování myšleno jako technický, nikoliv projektový problém.

[User682]

zdravim,

citat je pravdivy.

Neco ale doplnim. Zda to do roviny diskuze spada ci ne si doplnte sami.

Pokud par let "busite kod", tak zjistite urcitou cestu kudy to jde. Snazite se to drzet nejak prehledne. Rychlost a kvalita a pocet chyb hodne zavisi na tom, jakou budeme mit miru jednoduchosti dane casti, kterou prave vytvarite. Drzet to jednoduche se vyplati.

Nejake konvence se hodi. Kazda nestandartni vec neco stoji a to same nejaky preklad ci mapovani cehokoli. Viz. "co to je tady a cotoje tamhle".

Kdyz pujdeme k nejake pointe meho vypraveni, tak posledni roky zjistuji, ze nejdulezitejsi "je umet presne a jednoznacne vyjadrit dany problem". Pak uz to naprogramujete. Jsou urcite postupy, navrhove vzory, transformace, schemata, algoritmy, hotove knihovny, opensource SCM repositare a ty Vam to znacne ulehci. Nemusite nad tim pak moc premyslet a soustredite se na dulezitejsi a opravdu dulezite veci. Asi nejvice to take uvidite v nejake tymove spolupraci.

Jedna vec je dany problem videt pred sebou "nekde v hlave" jako shluk myslenek, ale dalsi je to umet presne popsat. Pri nejake osobni predstavivosti to muzete mit vykreslete pekne, ale mozek si dost veci/myslenky/elementy sam doplni (i kdyz neznate presny nazev) a take opomene ruzne chyby. Vcelku dost sazim v tomto prave na analyzu, at na papire nebo v digitalni podobe.

gf

[xxxs]

to je taka vseobecna pravda. iba kvalitna praca cloveka posunie dalej. talent a intelekt veci ulahcia a umoznia vacsiu efektivitu.

[void]

to je taka vseobecna pravda.

Souhlasím, jsou to takové blábolivé popisy obecně známých pravd.

Někteří lidé si v tom dost libují, a když není co říct, tak do diskuze prostě plácnou "KISS", "DRY" apod. Zvláštní je, že to dělají především - avšak v žádném případně ne výhradně - uživatelé nejmenované distribuce, která je dnes podobnou hračkou, jakou bylo onehdá Gentoo.

[xkucf03]

a když není co říct, tak do diskuze prostě plácnou "KISS", "DRY" apod.

Nejvtipnější je, když to někdo plácne na stránky svého „projektu“ hned vedle zkratek MVC a AJAX

[void]

Upřímně řečeno, mně to vtipné nepřijde - asi jsem to nepochopil.

[Ladicek]

Viva la J2EE!

[Marek Bernát]

KISS DRY AJAX je pekné kombo

[default]

jednoduchost a konvence

Na to pozor. Když se přežene konvence, jednoduchost se ztratí. Mé současné peklo na projektu…

[void]

Moc nesouhlasím. Jsem příznivcem konvencí a jejich dodržování.

Pokud už by nastal případ, kdy by dodržení konvence mělo víc záporů než kladů, je, řekl bych, ideálním řešením vytvořit konvenci druhou, novou (která bude používána v jasně daných případech). Pozn.: dvě konvence - to je snad oxymorón... Ale co.

Nejhorším případem porušení konvence je: "Tak já si to tady nějak tiše nabastlím, je to jedno, konvenci jsem stejně porušil."

(Vlastně by k původní konvenci vznikly celkem dvě konvence. První - která by řešila případy mimo první konvenci. A druhá - jež by říkala, které případy patří do které konvence.)

Když se přežene konvence

Je pak taky otázkou, zda je daná konvence dobrá nebo špatná...

[Dadam]

Co si vlastně myslíte o dodržování konvencí formátování kódu? Dodržujete to? Jestli ne, proč?

[Robo]

ja dodrzujem a dost si na tom potrpim, iba malokedy sa mi podarilo sa na to vyflaknut; ale poznam vela ludi, ktori na to kaslu, pretoze napr. nestihaju, treba to rychlo nakodit a pod.; v konecnom dosledku vsak iba pridavaju pracu tym, ktori to budu po nich musiet citat a upravovat

[Dadam]

Právě... Já si taky potrpím, jen mám někdy pocit že v ročníku jsu jediný. Tak mě napadlo jestli jsu já takový blázen nebo ostatní takové prasata
Posledně jsem si u kolegy, který je prasečím stylem známý, všiml kódu perfektně formátovaného. Pochválil jsem ho a vysloužil si za to vztyčený prostředníček. Psal to v Pythonu...

[Pavel]

nejak mi nedocvakla pointa...?

[Robo]

Python

[xkucf03]

treba to rychlo nakodit a pod.

Tohle moc nechápu – konvence by přece měla být něco přirozeného, člověk tak píše ze zvyku, nemusí na to nijak zvlášť myslet – tudíž ho to ani nemůže zdržovat. Problém může být leda v tom, že každý můžeme mít ty zvyky jiné – to je potom na vzájemné dohodě.

[Robo]

Problém může být leda v tom, že každý můžeme mít ty zvyky jiné – to je potom na vzájemné dohodě.

no niekto ma take navyky, ze na formatovanie uplne dlabe Odhliadnuc od toho, je treba sa samozrejme zosuladit. Castokrat sa stava, ze typek fixuje bug, opravi nejaku sekciu v kode, ale absolutne sa vybodne na formatovanie, konvencie pomenovania premennych, procedur a pod., ktore v danom kode su. No a takymto stylom sa za pol roka spolocne developeri dopracuju k tak sprasenemu kodu, ktory nikto nedokaze efektivne citat (co je inak problem aj viacerych open-source projektov).

[Marek Bernát]

Opakom toho je, keď pošleš funkčný patch na dôležitý bug, ale pol roka ťa drbú len kvôli štýlu a k skutočnému obsahu sa nikto nevyjadrí. To človeka fakt poteší Ale inak uznávam, že z dlhodobého hľadiska máš pravdu.

[pavlix]

To dost chápu, kdo by se vyjadřoval k něčemu, co se nedá rozumně číst.

[Marek Bernát]

Prečo by sa to nemalo dať čítať? Len preto, že to má trochu iný štýl, než je konvencia daného projektu? Fakt úžasné...

[pavlix]

Tak zaprvé ten styl mohl být hodně špatný.

Zadruhé je dobré dodržovat styl, aby šel patch použít bez úprav.

[Marek Bernát]

Mno, skôr mi ide o to, že občas sa na bugzillách človek stretne až s fanatickými zástancami konvencií, ktorí uprednostňujú formu pred obsahom a trpia tým všetci, lebo treba čakať na dôležité patche. Na druhej strane, z hľadiska dlhodobého sa asi vyplatí počkať.

[pht]

Problém může být leda v tom, že každý můžeme mít ty zvyky jiné – to je potom na vzájemné dohodě.

Jo, je důležitější mít jednu strukturu v celém projektu, než systém každej pes jiná ves.

Co se týče prostého formátování textu, dnešní nástroje umí na jeden příkaz přeformátovat všechny soubory za několik málo sekund takže není problém takovou konvenci kdykoliv změnit nebo přeformátovat cizí kus kódu (klidně i po praseti).

Horší to je bohužel s konvencema ohledně jmen, struktury a obecně stylu psaní. Tam někdy pomáhá code review, někdy motivace a někdy je to boj s větrnými mlýny.

[Filip Jirsák]

pretoze napr. nestihaju, treba to rychlo nakodit

To je zmáčknutí jedné klávesové zkratky v IDE tak zdržuje?

[Robo]

s codesweepermi nemam dobre skusenosti a nepouzivam ich (kazdy ma nejake muchy) a popravde ani osobne nepoznam cloveka, ktory by to pouzival

[Filip Jirsák]

To je právě ono. Kde kdo nepoužívá automatické formátování kódu, nepoužívá IDE, nepřekládá se zapnutými varováními kompilátoru, nepoužívá automatické testy a nepoužívá cizí knihovny, protože to všechno přece zvládne sám daleko lépe. A pak píše programy plné chyb s nečitelnými zdrojáky, které spoustu běžných věcí neumí nebo dělají jinak („protože na to mám vlastní knihovnu a musel bych to tam dopsat“). Možná bych k tomu „na čem skutečně záleží při programování“ doplnil „na zautomatizování všude tam, kde je to možné“. Zaměstnávat geniálního programátora tím, aby ručně formátoval kód, znamená plýtvat jeho schopnostmi, protože zformátovat kód zvládne i cvičená opice.

[Dadam]

Automatické formátování kódu nepoužívám, protože nemám moc rád když mi kurzor pod rukama dělá skopičiny. To už si ten tabulátor radši zmáčknu sám.
IDE taky raději nepoužívám, zatím jediné se kterými jsem měl tu čest byly CodeWarrior od Freescalu a NetBeans. CodeWarrior dělal čest svému jménu, válčili jsme spolu pekelně. No a NetBeans... představte si, že napíšete půl řádku kódu, zmáčknete středník a IDE vám ten půlřádek smaže. Napíšete to znovu a stejný výsledek. Znovu, abyste to ukázal kolegovi, no a potom napsat středník, půlřádek kódu, vyjmout půlřádek kódu a vložit ho před středník. Říkejte si co chcete, ale přílišná automatizace někdy škodí
Navíc mi ty IDE (je pravda že jsem zatím nedělal na opravdu velkém projektu) připadají strašně komplikované a přeplácané... Strašně rád bych zkusil práci v něčem, co by umělo zvýrazňovat syntaxi, kliknutím schovávat funkce, ukazovat čísla řádků a mít dvanáct tlačítek namapovaných na eFka, kterým bych mohl přiřadit nějaký příkaz (dva, tři - prostě miniskriptík) a to je vše. Jinak s vámi souhlasím.

[Josef Kufner]

Zkoušel jsi (g)vim?

[Dadam]

Na vimu mi vadí, že když mám zobrazené čísla řádků a chcu kopírovat kód, kopíruje se i s těmi čísly (někdy se to může hodit, třeba při kopírování někam do fóra, mně ale ne). Nainstaluju gvim a mrknu co to umí.

[Marek Bernát]

Skús

:set mouse=a

Druhá možnosť je nabindovať si na nejakú klávesu príkaz

:set invnumber

[Josef Kufner]

Proto mám rád gvim. Tyhle drobné problémy interakce s ostatními grafickými aplikacemi řeší. Ale jako terminál je pomalý (Při editaci to nevadí, ale pozor na dlouhé ladicí výpisy.)

[Marek Bernát]

Gvim sa v tomto ohľade ale chová úplne rovnako ako vim. V defaultnom nastavení kopíruje aj čísla riadkov.

[Filip Jirsák]

Automatické formátování používám, a nikdy mi kurzor pod rukama neskákal. NetBeans taky používám, a nikdy mi nemazaly kód. Kdyby šlo opravdu jen o jedno zmáčknutí tabulátoru – ale stačí třeba přidat nebo odstranit podmínku, a musíte odsazovat celý blok. Stačí přesunout část kódu, a musíte ji posouvat o několik tabulátorů. Proč, když to může udělat počítač na jednu klávesovou zkratku?

[Robo]

a v ktorych jazykoch programujete a ake IDE pouzivate? ja robim skoro denne v: PL/SQL, C, unix shell, perl, iScript, rozne konfiguraky (Oracle BRM pipelines a pod.), obcas PHP/HTML a nepoznam (multiplatformne) IDE, ktore by dokazalo vsetky syntaxy rozoznat a codesweepera, ktory by to vedel vsetko naformatovat; inak v praxi je casto dolezita flexibilita a programatora, ktory je zavisly sa na svojom IDE a bez toho nevie pisat zrozumitelny kod by som za priklad urcite nedaval
BTW, odsadit blok ide jednoducho-> oznacit + tabulator (na to nie je potreba ziaden codesweeper, ktory casto dokaze zmrsit cely kod ak clovek niekde napr. zabudol zatvorku)

[Filip Jirsák]

Na úpravu jednotlivých skriptů nepotřebujete IDE, navíc nevyužijete jeho možností, takže je na to daleko lepší jednoduchý editor. Pokud člověk někde zapomněl závorku, měl by ho na to editor upozornit, a přinejhorším to zjistí právě tím formátovačem kódu – tak závorku doplní a formátovač spustí znova. „Jednoduché označení“ pořád znamená, že musím hledat začátek a konec bloku a odsazovat, přitom to samé zvládne počítač udělat na jednu klávesovou zkratku. Prostě když píšu v něčem, kde nemůžu použít automatické formátování, přidělává mi to ruční formátování práci a svádí mne to k tomu nechat kód tak jak je bez nějakého formátování, případně bez úprav, které by třeba zlepšily čitelnost kódu nebo i zlepšily samotný kód, ale musel bych to potom zase vše ručně zformátovat. Když mi kód automaticky formátuje editor, používám třeba formát kódu, který mi nepřipadá úplně ideální (protože do té ideální podoby nejde formátovač zkonfigurovat), ale za to je zformátovaný všechen kód, a já se nevyhýbám změnám v kódu jenom proto, že bych pak kód zase musel ručně zformátovat.

[default]

Já třeba dělám ne-Javí věci v NetBeans s naprostou spokojeností. Java, SQL, PL/SQL, Bash… Je to jednodušší, než v texťáku. Jestli je to zelený nebo modrý mě nějak nepálí.

[xkucf03]

Zapomenutá závorka bývá při programování dost zásadní problém IDE nebo lepší editory mají funkci „zpět“, takže pokud zmáčkneš např. Ctrl+Alt+F a zjistíš, že se ti kód rozhodil, tak zmáčkneš Ctrl+Z a opravíš chyby. V IDE na to ale většinou nedojde, protože to ti chyby kontroluje průběžně a podtrhává.

Hlavně jde ale o to, že konvence formátování kódu by měla být relativně jednoduchá sada pravidel (když je jsou konvence příliš komplikované, tak si je lidi stejně nepamatují a kašlou na ně). A tahle jednoduchá pravidla není problém zautomatizovat a nechat tuhle práci dělat robota-program – jednak to šetří drahý čas programátorů a jednak je zarušeno, že všichni budou formátovat stejně (což se hodí i při práci s verzovacím systémem – pak tě nerozptylují změny formátování a řešíš jen podstatné změny v kódu).

[Robo]

IDE nebo lepší editory mají funkci „zpět“, takže pokud zmáčkneš např. Ctrl+Alt+F a zjistíš, že se ti kód rozhodil, tak zmáčkneš Ctrl+Z a opravíš chyby

v editore, co som pouzival CTRL+Z nepomohlo, nepametal si tolko krokov dozadu Inak, ked sa da tak IDE samozrejme pouzivam, zvyraznovanie syntaxe a pod. je dobra vec len nie vzdy mas moznost pouzivat svoje IDE, na ktore si zvyknuty. U nas na projekte sa castokrat stava, ze opravujes (debugujes) veci priamo niekde na (production, disaster) unix servri, kde nemas moznost si nainstalovat, pouzivat vlastne IDE (okrem vi-cka tam nic lepsie neni); inak ja pisem kod hned formatovany (sam by som sa v tom nevyznal, keby som pisal ako prasa) a nepotrebujem este klikat na button, ktory mi to dodatocne kod sformatuje

a jednak je zarušeno, že všichni budou formátovat stejně

tak takyto idealny stav IMHO nikdy nenastane; to by si musel vsetkym developerom, ktori su kdekade po svete a ktorych poznas iba po maily nanutit pouzivat rovnake IDE, co je IMHO nemozne a aj tak by sa nato vela ludi vysralo

[Filip Jirsák]

tak takyto idealny stav IMHO nikdy nenastane; to by si musel vsetkym developerom, ktori su kdekade po svete a ktorych poznas iba po maily nanutit pouzivat rovnake IDE, co je IMHO nemozne a aj tak by sa nato vela ludi vysralo

Stačí pro daný projekt nadefinovat konvence formátování. Pokud nejsou nějaké šílené, každý vývojář si to může nastavit ve svém formátovači (případně rovnou můžete vystavit konfigurace pro nejčastěji používané formátovače).

[Robo]

no ale toto je nadpraca, na ktoru sa kazdy vybodne; casto treba fixovat kod a clovek nema k dispozicii vymozenosti IDE a v pripade, ze je casova tiesen, tak taketo konvencie ludia prestavaju respektovat; vtedy sa ukaze, ze kto aky citatelny kod pise a ak to clovek nema v sebe (pisat uhladny a citatelny kod), tak potom vznikaju tak sprasene kody ake su; formatovanie je uplny detail, ktory je mozne velmi lahko napravit (aj ked v pripade, ze treba fixovat nieco priamo na servri a je to tam deploynute bez formatovania ... ), horsie su veci ako pomenovania premennych, funkcii ... Programator by mal mat urcite konvencie a ich dodrziavanie zazite v sebe. Tak ako sa pise v tom citate, moze byt ten programator hocijaky genius, raz sa mu nedodrziavanie konvencii vypomsti. Formatovanie je len maly detail.

[xkucf03]

+1

(akorát by to chtělo opravit ten zvýrazňovač syntaxe, který obarvuje politiky)

[Josef Kufner]

Co jsem tak viděl, tak největší hrůzy produkují právě ti s IDE.

[default]

a nepoužívá cizí knihovny, protože to všechno přece zvládne sám daleko lépe

Tak tady bych byl opatrný. Používání cizích knihoven spolu nese learning curve. A to nejen na úrovni API, ale hlavně na úrovni vnitřní implementace. Není nic lepšího, než se v testech dostat do křížku se side-effectem nějaké knihovny. Jako příklad za vše můžu uvést třeba Apachí Commons Configuration. Nese si s sebou tisíce dalších knihoven a chyb. A přitom člověk zpravidla potřebuje jen nasypat nějaký properties do HashMapy. Pardón, ale připadá mi jedna třída mnohem jednodušší na správu, než tuny balastu, nad kterými nemám kontrolu.

Hoši támhle v Anglii takhle vyměnili under-layering knihovny v našem produktu. Vedlo to k tomu, že současné implementace u zákazníků se musí kompletně předesignovat. Jen proto, že někdo udělal kompilát 3rd-party knihoven a teď zamíchal polívčičku.

Celý tohleto code reusability je velice ošemetná záležitost a na prvním místě bych to rozhodně nevypichoval. Zvlášť co se open source týče.

[Filip Jirsák]

Používání IDE, konfigurace formátování zdorjového kódu, psaní testů – to všechno s sebou nese nějaké vedlejší náklady. Nikdo netvrdí, že je to vše zadarmo a vše bude samo od sebe fungovat. Ale zpravidla je to tak, že když si budete psát vlastní knihovnu, budete tam mít ještě víc chyb, než kolik je v té už hotové. A tisíce dalších knihoven a problémy s výměnou knihovny budete mít také. Taky jsem nikde nepsal, že máte použít první knihovnu, která vám padne pod ruku, bez ohledu na její kvalitu. Pro mne osobně by třeba ta první dvě slovíčka v názvu „Apache Commons Configuration“ byla dostatečným varováním, abych se té knihovně vyhnul…

[default]

No to vysvětluj těm magorum v Anglii.

[Robo]

no mam dojem, ze vy musite byt cisty javista. Nie pre vsetky jazyky su take idealne IDE ako pre Javu ci C#

[Filip Jirsák]

To je pak pro ty jazyky nevýhoda. Ale když někdo místo programování radši formátuje kód, je to jeho věc…

[pht]

Nie pre vsetky jazyky su take idealne IDE ako pre Javu ci C#

Nástroje lint, indent a ctags (pro C) tu byly ještě dávno před tím, než Java a C# vznikly.

[pavlix]

Kde kdo nepoužívá automatické formátování kódu,

Tak minimálně takovýten klasický smartindent je v podstatě nutnost.

nepoužívá IDE

To je každého věc.

nepřekládá se zapnutými varováními kompilátoru, nepoužívá automatické testy

O tom by se už dalo bavit.

nepoužívá cizí knihovny, protože to všechno přece zvládne sám daleko lépe.

Případ od případu.

[pht]

s codesweepermi nemam dobre skusenosti a nepouzivam ich

To nevadí, ono stačí když to použije příjemce Vašeho zdrojáku.

[default]

V tomhle jsem ultraortodoxní extrémista. Když mi na stole přistane třeba SQL skript, kde je byť jedno klíčové slovo lower-case nebo table-reference upeer-case, vůbec se tím nezabývám a automaticky odmítám.

To samý platí o tatarských notacích v Javě či PL/SQL. A taky o špatně zformátovanym kódu.

Když něco děláme, máme to dělat pořádně.

[xkucf03]

Mluvíš mi z duše jednu dobu jsem dělal s lidmi, kteří měli konvenci psát názvy tabulek/objektů VELKÝMI písmeny (asi proto, že to byly důležité tabulky a závisel na nich celý náš byznys), jenže SQL klíčová slova psali taky „konvenčně“ velkými písmeny. To je pak trochu devalvace – držím se proto velkých klíčových slov a malých identifikátorů, pak je SQL přehledné i bez obarvení syntaxe + to chce hezky odsadit (aspoň ty delší dotazy).