V jaké verzi Visual Studia vyvíjíte komerčně?

[Kit]

dnes o kitovej metrike dlzky tried

Příště bude o zavrženém "else"

[Reklama]

[Kit]

Myslíš ty tisíce bezejmenných vývojářů v softwarových fabrikách?

Například Micro$oft ;-)

Takovou firmu neznám. Poněkud nevhodný nápad si dávat do názvu znak "$".

[perceptron]

dnes o kitovej metrike dlzky tried

Příště bude o zavrženém "else"

a netreba ani if ked mate tabulky a strategy, ze?

napiste o tom blog, nazvite ho Exampless

[AgentK]

Obvykle stačí vyházet gettery a settery.

vitajte v patnastom dieli kitovho kurzu oop navrhu bez getterov,  bez prikladov a bez realnych skusenosti, zato zo zadeke vytiahnutymi cislami

dnes o kitovej metrike dlzky tried

implementovat budete vo vime, s 200 riadkovym pluginom pre javu

Jakoby programování bylo o editoru a o textové délce třídy. Já jsem také toho názoru že je pohodlnější použít IDE, ale VIM používám také, a to denně v závislosti na tom, co chci dělat.

Bez getterů a setterů by to asi moc u mě nešlo, chce-li člověk ještě implementovat nějaké akce na základě změny, že.
Samozřejmě je to jiná, pokud kit má třídy, které to nepotřebují, nebo je mít nesmí kvůli pravidlu o délce headeru.
Později, při implementaci getterů a setterů, může celý projek refaktorovat ve vimu ,  které v jednom bodě jistě potřebovat začne.
To ale až mu koupí lepší tiskárnu a pravidlo o délce headeru pozbyde důvodu k existenci.

Ale samozřejme je to kitův prozíravý přístup, na který má své svobodné právo. Má na starosti veliké projekty, takže ví přece co dělá.

Berte můj příspěvek jako nadsázku. Je to tu moc hezký flame, tak proč si taky nezašpásovat!!

-K-

[perceptron]

gettery a settery urobia z maleho projektu velky. +3 LoC ku kazdej premennej

[Reklama]

[Kit]

Jakoby programování bylo o editoru a o textové délce třídy. Já jsem také toho názoru že je pohodlnější použít IDE, ale VIM používám také, a to denně v závislosti na tom, co chci dělat.

Textová délka třídy je jen užitečnou pomůckou, jak ve třídě udržet SRP.

Bez getterů a setterů by to asi moc u mě nešlo, chce-li člověk ještě implementovat nějaké akce na základě změny, že.

Kupodivu to jde. Obvykle stačí místo všech setterů použít jeden notify() a místo getterů jeden toString(). Jenže to bychom museli programovat objektově, že?

[Radovan.]

Myslíš ty tisíce bezejmenných vývojářů v softwarových fabrikách?

Například Micro$oft ;-)

Takovou firmu neznám. Poněkud nevhodný nápad si dávat do názvu znak "$".

A co teprve pojmenovat jí po svém penisu 8-O

[dustin]

Ano, programování je o kvalitním editoru, který pomůže udržet v kódu pořádek. Jen přehledný kód se správně pojmenovanými proměnnými/metodami a aktuálně správnou strukturou (tedy zrefaktorovaný na aktuální požadavky) má dlouhodobou hodnotu, jinak je to pouze koule na noze. Autor se mohl prsit, jak to měl krátké, ale někdo po něm jej bude proklínat. A majitel kódu platit jak mourovatý za každý další požadavek.

Do 80 sloupců se nevejde kód s popisnými názvy (ty nemají pár znaků). A nepopisné názvy (ač krátké) jsou úplně k ničemu.

To samé platí i pro linuxový kernel. Pochopit významy několikaznakových kryptických proměnných zabere spoustu času. Přitom by bývalo stačilo je pořádně pojmenovat.

Jenže na školách se učí vychytané algoritmy, mraky teorií, nic co by se v normální programátorské praxi byznys aplikací nějak zásadně využilo. Nic proti tomu, ale nesetkal jsem se s tím, že by někdo nedostal zápočet za to, že má jeho kód nedostatečně vysvětlující názvy. Přitom to je to zcela nejzásadnější - aby na tom šlo dál stavět. To se řeší až ve firmách a všichni s tím bojují (tedy kromě programátorů, těm je to fuk, však on to někdo zaplatí...). To by mělo být to nejdůležitější, co by mělo profesionálního programátora zajímat - dokáže to někdo další po mě rozvíjet dál? Není náhodou má výplata pro zadavatele dlouhodobě jen vyhozený peníz, když se tím bordelem bude muset po mě někdo prokousávat?

[Cajova_Houba_2]

Jakoby programování bylo o editoru a o textové délce třídy. Já jsem také toho názoru že je pohodlnější použít IDE, ale VIM používám také, a to denně v závislosti na tom, co chci dělat.

Textová délka třídy je jen užitečnou pomůckou, jak ve třídě udržet SRP.

Bez getterů a setterů by to asi moc u mě nešlo, chce-li člověk ještě implementovat nějaké akce na základě změny, že.

Kupodivu to jde. Obvykle stačí místo všech setterů použít jeden notify() a místo getterů jeden toString(). Jenže to bychom museli programovat objektově, že?

A je to tady

[Cajova_Houba_2]

Jenže na školách se učí vychytané algoritmy, mraky teorií, nic co by se v normální programátorské praxi byznys aplikací nějak zásadně využilo. Nic proti tomu, ale nesetkal jsem se s tím, že by někdo nedostal zápočet za to, že má jeho kód nedostatečně vysvětlující názvy. Přitom to je to zcela nejzásadnější - aby na tom šlo dál stavět. To se řeší až ve firmách a všichni s tím bojují (tedy kromě programátorů, těm je to fuk, však on to někdo zaplatí...). To by mělo být to nejdůležitější, co by mělo profesionálního programátora zajímat - dokáže to někdo další po mě rozvíjet dál? Není náhodou má výplata pro zadavatele dlouhodobě jen vyhozený peníz, když se tím bordelem bude muset po mě někdo prokousávat?

Tak tohle neni pravda. Moji spolužáci (ZČU) se s timhle osobně setkali, kdy jim neuznali semestrální práci, protože měli prasáckej kód. A celkově mi přišlo, že nás vedli k tomu aby jsme kód pro kalkulačku psali s ohledem na fakt, že by to někdy někdo mohl chtít předělat na operační systém.

[Jakub Galgonek]

Jenže na školách se učí vychytané algoritmy, mraky teorií, nic co by se v normální programátorské praxi byznys aplikací nějak zásadně využilo. Nic proti tomu, ale nesetkal jsem se s tím, že by někdo nedostal zápočet za to, že má jeho kód nedostatečně vysvětlující názvy.

Učí se tam i jiné věci, viz třeba: http://d3s.mff.cuni.cz/teaching/programming_practices/.

[Kit]

Do 80 sloupců se nevejde kód s popisnými názvy (ty nemají pár znaků). A nepopisné názvy (ač krátké) jsou úplně k ničemu.

S tím si dovolím nesouhlasit. Nikdo nedělá 80znakové popisné názvy, ale zpravidla si vystačí s 5-30 znaky. A takové výrazy se do 80 sloupců v pohodě vejdou.

To samé platí i pro linuxový kernel. Pochopit významy několikaznakových kryptických proměnných zabere spoustu času. Přitom by bývalo stačilo je pořádně pojmenovat.

Jenže na školách se učí vychytané algoritmy, mraky teorií, nic co by se v normální programátorské praxi byznys aplikací nějak zásadně využilo. Nic proti tomu, ale nesetkal jsem se s tím, že by někdo nedostal zápočet za to, že má jeho kód nedostatečně vysvětlující názvy. Přitom to je to zcela nejzásadnější - aby na tom šlo dál stavět.

S tím souhlasím. Jsem proti kryptickým názvům proměnných. Čím vzdálenější je proměnná od místa použití, tím by měl být její název popisnější.

Na druhou stranu: Proč používat vzdálené proměnné? Není lepší používat pokud možno pouze lokální a udržovat jejich názvy jednoslovní, snadno vyslovitelné (kvůli telefonu) a přitom dostatečně popisné? Vždyť v běžné třídě se nachází jen cca 2-4 atributů, v každé metodě 2-4 lokální proměnné. Copak na jejich rozlišení jsou nutná dlouhá slova typu klapkoBřinkoStroj nebo nosoČistoPlena?

[dustin]

Tak tohle neni pravda. Moji spolužáci (ZČU) se s timhle osobně setkali...

Hm, zrovna ze ZČU (KIV) byli/jsou všichni naši programátoři (já KKY, ale ani tam se nic takového samozřejmě neřešilo). Možná se to už zlepšilo, ale co když sleduji ten kód, nemám takový dojem.

[dustin]

S tím si dovolím nesouhlasit. Nikdo nedělá 80znakové popisné názvy, ale zpravidla si vystačí s 5-30 znaky. A takové výrazy se do 80 sloupců v pohodě vejdou.

Vejdou, ale vůbec ne v pohodě a přehledně, v javě bude každý druhý řádek zlomený. Nevidím důvod si znečitelnit kód úplně zbytečným omezením.

Na 5 znaků ve většině případů nedáš popisnou proměnnou, to bude akorát tak nesrozumitelná nekompletní zkratka.

[dustin]

Učí se tam i jiné věci, viz třeba: http://d3s.mff.cuni.cz/teaching/programming_practices/.

Hezké, to má přínos. A je ten předmět pro nějaký SW směr povinný?