☰

» »

V kakšnem stilu pišete vašo kodo?

V kakšnem stilu pišete vašo kodo?

««
2 / 9
»»

Vanquish ::

win64 je izjavil:


Da, samo zgoraj trdi, da unit testi niso potrebni za testiranje sprememb v kodi, če imaš odlično dokumentacijo.


to je stil - jaz tak dobro programiram, da ne rabim testiranja :D

FTad ::

bbbbbb2015 je izjavil:


Tvoje vprašanje je zelo subjektivne narave. Osebno pišem module, ki so do 2000 vrstic dolgi, metode pa do 300-400 vrstic, nekatere do 1000 vrstic. Posamezne vrstice so do 180 znakov dolge, kar smo s sodelavci povečali iz prejšnjih 130 vrstic, kar pa smo povečali iz 80 vrstic.

Vsi (vsaj večina) imamo tri ekrane (sedaj imam enega 4K 27'' in dva pokonci postavljena HD 24'') in delamo (večina) v IDEA IntelliJ, nekateri tudi v Eclipse(u).

Uporabljamo code formatting in je dogovor, da je koda sformatirana, preden se naredi komit (česar pa se ne držijo vsi), za kodo pa uporabljamo SonarQube,oz. jaz imam v IntelliJ en standalone modul, ki on the fly preveri kodo.

Tako kot je, smo zadovoljni vsi, je pa stvar dogovora, kaj je sprejemljiva koda. Npr., ta koda, o kateri govorim, je popolnoma neobvladljiva na enem 13 colskem laptopu. Tudi na 15.4'' laptopu je težko delati, razen če imaš 4K ekran in dobre oči.

Sem pa prej delal v tim,u, kjer smo vsi imeli en 24'' HD ekran, tam smo imeli limit dolžine modula do 1000 vrstic in dolžino vrstice do 130 znakov.

Tako da je zelo odvisno, s kakšnim harverom delaš.


Meni to deluje neberljivo. Razumem, da je sicer sintaksa različna med programskimi jeziki, ampak težko verjamem, da je standard 180 znakov na vrstico. Jaz imam v Eclipsu nastavljeno na 100 znakov, da lahko dam dva taba paralelno znotraj programa na enem monitorju, in se še vedno da brati.

Koda naj bi bila napisana bolj v smislu kot tekst v časopisu v stolpcih, da čim manj premikaš oko iz leve proti desni. Tudi to, da moraš scrollat iz leve proti desni, če je ekran pomanjšan, je že "nevljudno" za bralca.

bbbbbb2015 ::

FTad je izjavil:

bbbbbb2015 je izjavil:


Tvoje vprašanje je zelo subjektivne narave. Osebno pišem module, ki so do 2000 vrstic dolgi, metode pa do 300-400 vrstic, nekatere do 1000 vrstic. Posamezne vrstice so do 180 znakov dolge, kar smo s sodelavci povečali iz prejšnjih 130 vrstic, kar pa smo povečali iz 80 vrstic.

Vsi (vsaj večina) imamo tri ekrane (sedaj imam enega 4K 27'' in dva pokonci postavljena HD 24'') in delamo (večina) v IDEA IntelliJ, nekateri tudi v Eclipse(u).

Uporabljamo code formatting in je dogovor, da je koda sformatirana, preden se naredi komit (česar pa se ne držijo vsi), za kodo pa uporabljamo SonarQube,oz. jaz imam v IntelliJ en standalone modul, ki on the fly preveri kodo.

Tako kot je, smo zadovoljni vsi, je pa stvar dogovora, kaj je sprejemljiva koda. Npr., ta koda, o kateri govorim, je popolnoma neobvladljiva na enem 13 colskem laptopu. Tudi na 15.4'' laptopu je težko delati, razen če imaš 4K ekran in dobre oči.

Sem pa prej delal v tim,u, kjer smo vsi imeli en 24'' HD ekran, tam smo imeli limit dolžine modula do 1000 vrstic in dolžino vrstice do 130 znakov.

Tako da je zelo odvisno, s kakšnim harverom delaš.


Meni to deluje neberljivo. Razumem, da je sicer sintaksa različna med programskimi jeziki, ampak težko verjamem, da je standard 180 znakov na vrstico. Jaz imam v Eclipsu nastavljeno na 100 znakov, da lahko dam dva taba paralelno znotraj programa na enem monitorju, in se še vedno da brati.

Koda naj bi bila napisana bolj v smislu kot tekst v časopisu v stolpcih, da čim manj premikaš oko iz leve proti desni. Tudi to, da moraš scrollat iz leve proti desni, če je ekran pomanjšan, je že "nevljudno" za bralca.


Kakor rečeno, mi imamo tri ekrane, eni dva. Imamo pa enega razvijalca, ki vztraja na enem 14'' laptopu. Ampak ta bolj potem rihta neke sistemske zadeve in bi ga jaz bolj označil kot sistemca, ne razvijalca.

RedDrake ::

win64 je izjavil:


Da, samo zgoraj trdi, da unit testi niso potrebni za testiranje sprememb v kodi, če imaš odlično dokumentacijo.

Trdim, da če izvajaš takšne spremembe v kodi, ki zahtevajo ponovno testiranje posameznih sklopov, brez da bi se na tak poseg pripravil, potem stvar počneš narobe.
Pred vsako funkcionalno spremembo, se naredi ponovna analiza, kako bo to vplivalo na program/funckijo/modul/knjižnico, ponovna dokumentacija, in se postavi ponovne okvire za test (ali celote ali dela, ki se popravlja).
VSAK code first approach je faljen v štartu.
Testi so že ok, ampak so samo toliko dobri, kot tisti, ki jih piše oziroma predvidi. Z drugimi besedami, če bi bili unit testi holy grail programiranja bi imeli bug free kodo. Tako pa večina današnjega programja počne neželene stvari praktično ves čas. Ker se programerji zanašajo, da če rutina prestane nek test, ki ga je po možnosti celo on sam zasnoval za svojo rutino, potem je vse ok in fine and dandy.
Ampak to je podobno, kot če lektoriraš lasten tekst. Najbolj očitne napake ne boš nikoli videl. Ja saj vem, teste delajo drugi (če je kolikor toliko resna firma), ampak še vedno v 99% primerih razmišljajo v enakih okvirih kot ljudje, ki pišejo kodo.

showsover ::

Razlika je tudi ali razvijaš nov produkt ali pa vzdržuješ (in morda niti nimaš kakovostne dokumentacije), tega je v i/t industriji ogromno.

Vanquish ::

RedDrake, testi niso zato, da bodo odkrili vse buge, ampak da bodo zmanjsali moznost napake in v koncni fazi, da z neko spremembo nisi nehote porusil katero od obstojecih stvari.

Sicer pa so unit testi prvi korak - kasneje se mas integracijske, funkcijske, end2end, ....., ki dodatno povecujejo stabilnost okolja. Seveda to ne pomeni, da bo SW bug free, se bos pa z veliko veliko verjetnostjo izognil kapitalnih napak in bos na koncu reseval specificne tezave in ne genericne.

PrimoZ_ ::

kuall je izjavil:

FTad je izjavil:

Namreč v službi me moj sodelavec (senior programer) sekira, da preveč drobim kodo v manjše metode, češ da koda ni več bralna.

Se kar strinjam z njim, da ni pretiravat s številom metod. Pa še delo imaš s tem kreiranjem milijontih metod. Dobra alternativa temu je tale, katero jaz prakticiram že 10 let: vse pustiš v eni veliki metodi in samo razdeliš metodo na dele, vsak dal pa pokomentiraš. Primer:

// Naredi stvar 1
code
code
code (nič praznih vrstic vmes)

// Naredi stvar 2 (1 prazna vrstica med blokoma)
code
code
code (nič praznih vrstic vmes, ker zmanjšajo bralnost, prazne vrstice naj bodo samo med bloki)

// Nafilaj dataset "dt"
code
code
code



Tole je clusterfuck stil programiranja :) Oprosščeno ti je samo če uporabljaš pascal kjer imaš gnezdene funkcije :)

P.S. A nisi ti rekel, da nepreklicno odhajaš... ?

cleanac ::

To, da mora funkcija početi samo eno stvar je samo znak, da več berete kot delate. Kodo se premakne v funkcijo, ko je to potrebno...recimo, da se kliče večkrat in ni ravno nek enostaven for/if stavek. Če koda ni berljiva ni problem v tem, ker je funkcija predolga, temveč, ker je slabo spisana. Nihče me ne bo prepričal, da je skakanje od funkcije do funkcije bolj berljivo kot zaporedno spisana koda na enem mestu. Seveda v kolikor situacija to dopušča. Če pa so komentarji nesmiselno napisani, dolžine spremenljivk največ 5 mestne, pa je tako bolje, da se gre takoj assembler kodo brat.

kow ::

cleanac je izjavil:

Nihče me ne bo prepričal, da je skakanje od funkcije do funkcije bolj berljivo kot zaporedno spisana koda na enem mestu..

Mene pa ravno obratno. Skok v funkcijo in nazaj sta 2 keyboard shortcuta.
Ce ima koda sredi bloka komentar, imam raje da je notri funkcija, ki ima pac ime bo bistvu komentarja.
Komentarji so v 95p primerov useless.

cleanac ::

Komentarji so useless takrat, ko ne opravljajo svojega namena, kar je žal, tako kot si rekel, v 95% primerov.

RedDrake ::

cleanac je izjavil:

Komentarji so useless takrat, ko ne opravljajo svojega namena, kar je žal, tako kot si rekel, v 95% primerov. 

%h = map { $a[$_] => $_ } 0..$#a;


:)

def0r ::

Sklepam da pisem v podobnem nacinu kakor drugi, kjer po enem letu pridemo do tega..

gandalf0r

gandalf0r

bbbbbb2015 ::

cleanac je izjavil:

To, da mora funkcija početi samo eno stvar je samo znak, da več berete kot delate. Kodo se premakne v funkcijo, ko je to potrebno...recimo, da se kliče večkrat in ni ravno nek enostaven for/if stavek. Če koda ni berljiva ni problem v tem, ker je funkcija predolga, temveč, ker je slabo spisana. Nihče me ne bo prepričal, da je skakanje od funkcije do funkcije bolj berljivo kot zaporedno spisana koda na enem mestu. Seveda v kolikor situacija to dopušča. Če pa so komentarji nesmiselno napisani, dolžine spremenljivk največ 5 mestne, pa je tako bolje, da se gre takoj assembler kodo brat.


No, no no. Počasi.

Saj so razlogi, da v dvovrstični funkciji/metodi kličeš drugo funkcijo/metodo.
Eno je recimo 'separation of concerns', kjer procesiraš transakcije v eni metodi, v drugi pošiljaš maile.
Drugi je malo bolj zmuzljiv Divide et empera, torej deli in vladaj. Problem, ki se zdi težko obvladljiv razbiješ na dva (lažje) rešljiva problema.
Tretje je recimo 'transaction context wrapping', to je sicer bolj Java specifično. Napišeš transakcijsko kodo, ki je lahko raznorazna, vendar ne začne, niti ne zaključi transakcije. Potem narediš enostavno metodo, wrapper, ki izrecno začne (in implicitno konča) transakcijo, vmes pa kliče pač vso potrebno poslovno logiko.

To tako iz glave. Morda je še kaj.

Zgodovina sprememb…

A-242 ::

RedDrake, Vanquish: v 20 letih kodiranja se je VEDNO izkazal denar potrosen za unit teste slaba nalozba napram dobiti bolj kvaliteten kader za ta denar. Da niti ne omenjam stroskov refaktoriranja (ki jih je povzrocil nekvaliteten kader), ko je bilo treba zrusiti vse unit teste in jih spisati ponovno. Lahko sicer birokratizirata in teoretizirata o tem, dejstvo pa je, da k dobri kodi mnogo vec pripomore kompetenten pisec kot pa vsi testi za njim (je pa res, da ga je treba placat, samo osebno mislim, da gladko odtehta).

Ostali: Spageti kode SE NE DELA. Pika. Ce je funkcija vecja od ekrana ali dveh je cas za razbitje na vec funkcij. Ker pa smo v "novarek" casih, bom prevedel v danasnje case... miljauznt klasov SE NE DELA. Vasi ravioli in lazanje so hujse od spagetov, ki sicer ubijajo berljivost kode ampak se vedno manj kot classi. Naprej, single point of exit se ne dosega tako, da imas nestanih 20 if-ov, for-ov, whilov.

Ergo, tri zadeve zaradi katerih bi hitro koga zadavil, globoko nestanje pogojev in zank, testeninske feste in apriori objektno programiranje (nije zvaka za seljaka).
The world has enough for everyone's needs, but not everyone's greed.
- Mahatma Gandhi

Zgodovina sprememb…

  • spremenilo: A-242 ()

kuall ::

PrimoZ_ je izjavil:

Tole je clusterfuck stil programiranja

Če kodo komentiraš je to clusterfuck? Genijalna izjava. Ne komentiram vsake vrstice ampak bloke kode in ko pridem po 1 letu nazaj samo berem komentarje, ne kode. Še vedno, ko sem prišel nazaj na tako komentirano kodo po 1 letu sem bil teh komentarjev vesel. Pametni ljudje si stvari naredimo lažje, neumni pa težje.
Funkcije kreiram čist normalno po zdravi pameti, nimam nekih političnih prepričanj v nobeno smer niti niso razne "avtoritete" vplivale name s svojimi nasveti, kako velika mora biti funkcija.

To drobljenje v majhne funkcije je potrebno ravno zato, ker kode ne komenitirate tako kot jo jaz in potem vas kreiranje novih funkcij prisili v "komentiranje" s tem, ko morate funkciji dati naziv, kar je sam po sebi komentar.

A-242 je izjavil:

RedDrake, Vanquish: v 20 letih kodiranja se je VEDNO izkazal denar potrosen za unit teste slaba nalozba napram dobiti bolj kvaliteten kader za ta denar. Da niti ne omenjam stroskov refaktoriranja (ki jih je povzrocil nekvaliteten kader), ko je bilo treba zrusiti vse unit teste in jih spisati ponovno. Lahko sicer birokratizirata in teoretizirata o tem, dejstvo pa je, da k dobri kodi mnogo vec pripomore kompetenten pisec kot pa vsi testi za njim (je pa res, da ga je treba placat, samo osebno mislim, da gladko odtehta).


100% drži. Je bilo obdobje, ko sem bil tudi jaz navdušen nad unit test. Potem sem ugotovil, da je bolj pametno, da funkcijo 1x dobro stestiraš in dobro razmisliš, ko jo pišeš in imaš potem za vekomaj mir z njo.

Zgodovina sprememb…

  • spremenilo: kuall ()

codeMonkey ::

Invictus je izjavil:

Stil kodiranja je tak kot je predpisan v firmi...

Seveda, če ga kdo napiše ;).


Imamo tudi code style checker. Ta ni pogoj za Q-gate, je pa ena od stvari, ki se preverja, ko se dela code review.

Kar se kode tice, moramo se upostavati MISRA C oz. MISRA C++ ter HIS metrike - https://emenda.com/his/
Te stvari morajo stimati, ce zelis priti skozi Q-gate. Poleg drugih stvari seveda, ki nimajo toliko povezave s stilom: 100% code coverage, 90% generator code coverage, 100% requirements coverage, ipd.

MISRA je kar kul, predvsem pa so HIS metrike ena boljsih stvari, ki sem jih videl. Vcasih mi je kar malo tezko ze gledati kaksen open source projekt izven firme.

Zgodovina sprememb…

A-242 ::

kuall je izjavil:

Če kodo komentiraš je to clusterfuck? Genijalna izjava.


Komentarji so vredu, se lepse pa je ce opravljajo to delo smiselna imena variabel in funkcij. Razlog je preprost, koda se spreminja, komentarje pa kar nekako ostanejo. In ko oboje enkrat divergira... boh pomagi...
The world has enough for everyone's needs, but not everyone's greed.
- Mahatma Gandhi

galu ::

Moje vprašanje je, kakšen je vaš stil pisanja kode? Radi razdelite dele celotne kode na majhne metode s smiselnimi imeni in unit testi (kjer je smiselno), ali namečete celotno logiko v metode/procedure/whatever z več kot 100 vrsticami?


Sedanji nivo programiranja smo dosegli ravno z dobrimi (key word) abstrakcijami. Riniti v zide kode je anti-pattern praktično vsem sw dev praksam.
Tako to gre.

kuall ::

Ja, držanje stvari sinhronizirane med seboj zna bit zajebano, temu se je dobro izognit, če se le da. Ali pa imet mau discipline in komentarjem daš visoko prioriteto. Pa ni treba romanov pisat, dovolj je, če je komentar le 1 beseda. Če pišeš romane v komentarjih potem bodo postali obsolete ja. Romane se piše v specifikaciji oziroma še bolje v navodilih za uporabo programa (če se da lepo po točkah), ni prostor za romane v komentarjih.

techfreak :) ::

Potrebno se je izogniti komentarjev kjer je to mogoce, ter pisati kodo iz katere je razvidno kaj pocne. Za netrivialne funkcije pa obvezno opisati kaj delati, ter po potrebi se opisati parametre ter vrnjene vrednosti.

techfreak :) ::

A-242 je izjavil:

Razlog je preprost, koda se spreminja, komentarje pa kar nekako ostanejo. In ko oboje enkrat divergira... boh pomagi...
Skoraj vedno se taksne stvari odkrije v code review procesu. Vecino stvari pa ujames, ce tudi sam naredis pregled kode, preden das pull/merge request naprej v CR.

Steinkauz ::

kuall je izjavil:

PrimoZ_ je izjavil:

Tole je clusterfuck stil programiranja

Če kodo komentiraš je to clusterfuck? Genijalna izjava. Ne komentiram vsake vrstice ampak bloke kode in ko pridem po 1 letu nazaj samo berem komentarje, ne kode. Še vedno, ko sem prišel nazaj na tako komentirano kodo po 1 letu sem bil teh komentarjev vesel. Pametni ljudje si stvari naredimo lažje, neumni pa težje.
Funkcije kreiram čist normalno po zdravi pameti, nimam nekih političnih prepričanj v nobeno smer niti niso razne "avtoritete" vplivale name s svojimi nasveti, kako velika mora biti funkcija.

To drobljenje v majhne funkcije je potrebno ravno zato, ker kode ne komenitirate tako kot jo jaz in potem vas kreiranje novih funkcij prisili v "komentiranje" s tem, ko morate funkciji dati naziv, kar je sam po sebi komentar.

A-242 je izjavil:

RedDrake, Vanquish: v 20 letih kodiranja se je VEDNO izkazal denar potrosen za unit teste slaba nalozba napram dobiti bolj kvaliteten kader za ta denar. Da niti ne omenjam stroskov refaktoriranja (ki jih je povzrocil nekvaliteten kader), ko je bilo treba zrusiti vse unit teste in jih spisati ponovno. Lahko sicer birokratizirata in teoretizirata o tem, dejstvo pa je, da k dobri kodi mnogo vec pripomore kompetenten pisec kot pa vsi testi za njim (je pa res, da ga je treba placat, samo osebno mislim, da gladko odtehta).


100% drži. Je bilo obdobje, ko sem bil tudi jaz navdušen nad unit test. Potem sem ugotovil, da je bolj pametno, da funkcijo 1x dobro stestiraš in dobro razmisliš, ko jo pišeš in imaš potem za vekomaj mir z njo.


Upam, da vidiš, da je tak stil pisanja (torej dolge metode, ki delajo svašta, potem pa jih komentiraš, ker je vse nametano) in boleč unit testing izjemno povezan.
Več kot imaš simple metod, lažje jih testiraš.

Smurf ::

kuall je izjavil:


100% drži. Je bilo obdobje, ko sem bil tudi jaz navdušen nad unit test. Potem sem ugotovil, da je bolj pametno, da funkcijo 1x dobro stestiraš in dobro razmisliš, ko jo pišeš in imaš potem za vekomaj mir z njo.

Se pravi, si napisal unit teste, da si s testiral funkcijo, ampak potem si jih zbrisal?

Zakaj je ze to bolje?

showsover ::

Domnevam, da kuall malo trola s tem, ko i/t panožne standarde zanemarja, ni prvič.

Invictus ::

kuall je izjavil:


100% drži. Je bilo obdobje, ko sem bil tudi jaz navdušen nad unit test. Potem sem ugotovil, da je bolj pametno, da funkcijo 1x dobro stestiraš in dobro razmisliš, ko jo pišeš in imaš potem za vekomaj mir z njo.

Ne vem kako kodo pišete in kako velike produkte, ampak unit testi niso tam zaradi testiranja samih funkcij, ampak ponavadi zaradi drugih.

Iščeš spremembe, ki ti zjebejo celotno funkcionalnost in jih je težko najti, sploh če je ekipa velika.

Teoretično bi seveda bilo čisto kul, če bi vsak do konca stestiral svojo kodo, samo vemo, da tega ni...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

FTad ::

Imam teorijo, da tisti, ki so ze v srednji soli/faxu delali zapiske urejeno t.i. uporabljali kakšne barve za podcrtavanje pomembnih delov, razdelili snov v vec manjsih tematsko smiselnih kosov, dajali kako prazno vrstico med sklopi, tudi pri programiranju raje razdelijo kodo v tematsko smiselne sklope za lazje branje.

Vsaj pri meni je tako. Jaz se nisem mogel uciti snovi, napisane na a4 list brez kakih praznih vrstic vmes, vse samo crno belo, prav tako nisem uspel nicesar na hitro najti, kajti vedno je bilo treba brati od zacetka, da najdem potem nekaj na sredini zapiskov.

Menim, da je isto pri pisanju kode. Nekaterim ni problem pisati vsega v eno metodo, dati kak komentar tu in tam in ste s tem zadovoljni, ker ste edini, ki vzdrzujete to kodo.

showsover ::

Sklope daljših metod se refaktorira v krajše metode, ki so s parametri vred smiselno poimenovane, ki jih je možno posamično razvijati širom sveta, (unit!) testirati, dokumentirati in, po možnosti, reusati. Pred vsakim mergem v main/trunk, morajo vsi tangirani unit testi biti opravljeni s čim večjo, če ne vso, pokritostjo kode in 100.0% uspehom, tudi najmanjši neuspeh unit testov mora načeloma rezultirati v zavrnitvi zahteve za merge. Tako to približno izgleda, ko imaš armado high-end senior developerjev, po možnosti globalno distribuirano.

Tako je govoril.... gtfo.

Zgodovina sprememb…

  • spremenilo: showsover ()

Vanquish ::

pa ena zadeva okoli unit testov - unit testi, niso tam samo zato, da se dobi coverage v toolih ampak da dejansko smiselno testirajo tisto :D
Ker bi se cudli kaj vse se pise pod unit teste

Invictus ::

To je predvsem odvisno od vodstva.

Dostikrat, ko se vedno zahteva unit teste, folk piše budalaštine, samo zato, da so narejeni in da je zadoščeno nekim pravilom.

Testov seveda nihče pne pregleda...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

Smurf ::

showsover je izjavil:

Sklope daljših metod se refaktorira v krajše metode, ki so s parametri vred smiselno poimenovane, ki jih je možno posamično razvijati širom sveta, (unit!) testirati, dokumentirati in, po možnosti, reusati. Pred vsakim mergem v main/trunk, morajo vsi tangirani unit testi biti opravljeni s čim večjo, če ne vso, pokritostjo kode in 100.0% uspehom, tudi najmanjši neuspeh unit testov mora načeloma rezultirati v zavrnitvi zahteve za merge. Tako to približno izgleda, ko imaš armado high-end senior developerjev, po možnosti globalno distribuirano.

Tako je govoril.... gtfo.

Indeed. Best practise je glede tega znan. Sedaj bomo pa vseeno poslusali se nekaj postov, kako ima nekdo, ki ima vec kot 10 let izkusenj s programiranjem trgovin za macjo hrano in je ugotovil, da se mu ne splaca delati unit testov :>.

bbbbbb2015 ::

FTad je izjavil:

Imam teorijo, da tisti, ki so ze v srednji soli/faxu delali zapiske urejeno t.i. uporabljali kakšne barve za podcrtavanje pomembnih delov, razdelili snov v vec manjsih tematsko smiselnih kosov, dajali kako prazno vrstico med sklopi, tudi pri programiranju raje razdelijo kodo v tematsko smiselne sklope za lazje branje.

Vsaj pri meni je tako. Jaz se nisem mogel uciti snovi, napisane na a4 list brez kakih praznih vrstic vmes, vse samo crno belo, prav tako nisem uspel nicesar na hitro najti, kajti vedno je bilo treba brati od zacetka, da najdem potem nekaj na sredini zapiskov.

Menim, da je isto pri pisanju kode. Nekaterim ni problem pisati vsega v eno metodo, dati kak komentar tu in tam in ste s tem zadovoljni, ker ste edini, ki vzdrzujete to kodo.


To je samo tvoja teorija.
V resnici je dosti več. Če jezik obvladaš, če sistem obvladaš, lahko pišeš daljše funkcije. Vsaj v Javi je tako, da je sedaj potrebna velika stopnica, da nekaj obvladaš. Dokler tega ne obvladaš, pišeš krajše kose kode. Dosti je odvisno od orodij. Moderen IDE precej pospeši produktivnost.

Pa še od marsičesa drugega je odvisno. Na primer, če obdeluješ temo, ki jo dobro poznaš (SQL in transakcije) ali pa nekaj, kar ne pozna dobro, recimo kakšno krmiljenje zunanjih naprav.

SloKin ::

kuall je izjavil:

PrimoZ_ je izjavil:

Tole je clusterfuck stil programiranja

Če kodo komentiraš je to clusterfuck? Genijalna izjava. Ne komentiram vsake vrstice ampak bloke kode in ko pridem po 1 letu nazaj samo berem komentarje, ne kode. Še vedno, ko sem prišel nazaj na tako komentirano kodo po 1 letu sem bil teh komentarjev vesel. Pametni ljudje si stvari naredimo lažje, neumni pa težje.

In potem se sprašuješ kje v komentarju je bug. Če pa piše v komentarju, da dela tako. Kje je napaka? Slovnično napako v komentarju si popravil, pa še vedno ne dela prav.
Pa ja... Nauči se brat kodo ne pa komentarje. Koda je resnica. Komentarji so pomoč. Ko ti bo to dejstvo jasno, boš začel pisat kratke funkcije.

A-242 ::

Invictus je izjavil:

Teoretično bi seveda bilo čisto kul, če bi vsak do konca stestiral svojo kodo, samo vemo, da tega ni...


Je je, in ogromno si lahko pomagas z debuggerjem, da mu sproti popravljas vrednosti v memoriji in s tem preverjas error handling ipd...

Kot sem povedal, kakrsen kader, taksen izdelek. In ker vsi najemajo kakrsnokoli "opico" (pun intended) in probajo z velikim stevilom "opic" napisati Shakespearjeva dela (Put enough monkeys in a room with a typewriter they'll produce Shakespeare) potem se pojavijo razni fail safe mehanizmi za izravnavanje napak kadrovske sluzbe in zmedenost v glavah vodilnega kadra. Tako se pac ne dela, seveda pa lastniki podjetij / managerji v svoji pogoltnostni za denarjem zmanjsujejo stroske tam, kjer jim prinesejo najvec denarja (in prisparanih zivcev), po drugi strani pa ni noben problem ta denar potem zagonit za izdatna unit testiranja, razne metrike, metodologije, itd, cez 10 let pa, iskati supermane, da jim razresijo na stari kodi, kar so "opice" na zacetku zajebale.

Ko gres zidat hiso tudi ne vzames zidarja, ki skili in ima samo se pol leve roke, potem mu pa porines v roko standarde o gradnji in popreprostis hiso do te mere, da jo je nekako sposoben dostavit.

Programiranje je umetnost. Vsi pa bi radi naredili iz tega delo za tekocim trakom in rezultat je temu primeren, time-to-market, karkoli, kakorkoli, s cimerkoli. Zelo lep primer kaj naredi pohlep.
The world has enough for everyone's needs, but not everyone's greed.
- Mahatma Gandhi

Zgodovina sprememb…

  • spremenilo: A-242 ()

Smurf ::

Hvala fantje, tale tema me je nasmejala in hkrati pokazala kako ponekod izgleda programerski svet izven mojega bubbla.

Invictus ::

Saj najbrž pozntea tisto menedžersko foro...

Manager tuhta, imam žensko, rodila bo čez 9 mesecev. Predolgo...

O.K. našel bom še 8 žensk, in potem bo teh 9 rodilo v 1 mesecu...

Tako nekako izgleda razmišljanje menedžerjev in zaposlovanje dodatnega folka na projekt, ko zamuja...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

Zgodovina sprememb…

  • spremenil: Invictus ()

BigWhale ::

bbbbbb2015 je izjavil:

Kakor rečeno, mi imamo tri ekrane, eni dva. Imamo pa enega razvijalca, ki vztraja na enem 14'' laptopu. Ampak ta bolj potem rihta neke sistemske zadeve in bi ga jaz bolj označil kot sistemca, ne razvijalca.


To je neumnost. Ce ti berljivost kode pogojuje hardware, potem je tvoja koda fucked up. Vse kar je vec kot 120 znakov v vrstici je neberljiva klobasa, pa je popolnoma vseen a imas 21" 24" al pa 32" monitor.

So primeri kjer je tezje napisat krajso vrstico kot 120 znakov, sploh pri front-endu kjer imas recimo HTML oz markup zmesan skupaj s kodo ampak to so izjeme in se jih je treba izogibat.

RedDrake je izjavil:

Trdim, da če izvajaš takšne spremembe v kodi, ki zahtevajo ponovno testiranje posameznih sklopov, brez da bi se na tak poseg pripravil, potem stvar počneš narobe.


Wat? Vsaka sprememba kode zahteva ponovno izvajanje unit testov in testiranje posameznih sklopov. Obstajajo bolj ali manj trivialne spremembe in stvari so odvisne od sistema ampak dozivel sem ze, da je sprememba nekega stringa povzrocila fail na povsem drugem koncu. Slisi se bizarno ampak taksne stvari se dogajajo.

RedDrake je izjavil:


Z drugimi besedami, če bi bili unit testi holy grail programiranja bi imeli bug free kodo. Tako pa večina današnjega programja počne neželene stvari praktično ves čas. Ker se programerji zanašajo, da če rutina prestane nek test, ki ga je po možnosti celo on sam zasnoval za svojo rutino, potem je vse ok in fine and dandy.


To je samo delno res. Unit testi primarno niso namenjeni temu, da bi se pisala bug-free koda. Unit testi so namenjeni testiranju posameznih enot in skrbijo predvsem zato, da se enote ne polomijo pri delu s celoto. Ne rabis 100% pokritosti kode s testi, rabis imet pokrite tiste dele, ki se prej polomijo.

RedDrake je izjavil:

cleanac je izjavil:

Komentarji so useless takrat, ko ne opravljajo svojega namena, kar je žal, tako kot si rekel, v 95% primerov. 

%h = map { $a[$_] => $_ } 0..$#a;


:)


Taksno kodo, s komentarji ali brez, ti bo vsak pameten reviewer takoj vrgel ven in jo bos moral izredno dobro zagovarjati, da bo sploh ostala v produkciji.

(A nam vseen lahk razlozis, kako ti je uspel Perl spravit v produkcijo? ;>)

A-242 je izjavil:

RedDrake, Vanquish: v 20 letih kodiranja se je VEDNO izkazal denar potrosen za unit teste slaba nalozba napram dobiti bolj kvaliteten kader za ta denar. Da niti ne omenjam stroskov refaktoriranja (ki jih je povzrocil nekvaliteten kader), ko je bilo treba zrusiti vse unit teste in jih spisati ponovno. Lahko sicer birokratizirata in teoretizirata o tem, dejstvo pa je, da k dobri kodi mnogo vec pripomore kompetenten pisec kot pa vsi testi za njim (je pa res, da ga je treba placat, samo osebno mislim, da gladko odtehta).


Pics or it didn't happen. Resnicno. Za tvoje zgornje trditve bos moral pokazati kaksne konkretne stevilke al pa enostavno rect, da si stvari zmisljujes in v bistvu nimas pojma kaj govoris. Tvoje nadaljno razlaganje o kvaliteti kadra in o kompetentnih piscih, ki ne rabijo pisati testov pa kaze samo na to, da v resnici pojma nimas kaj so test in kaj je test driven development in kaksen je njihov namen.

kuall je izjavil:

100% drži. Je bilo obdobje, ko sem bil tudi jaz navdušen nad unit test. Potem sem ugotovil, da je bolj pametno, da funkcijo 1x dobro stestiraš in dobro razmisliš, ko jo pišeš in imaš potem za vekomaj mir z njo.


A si upas povedati kje delas in kdo je tvoj delodajalec? :> Tolk zgresenih izjav je kr tezko na kup zmetat ampak tebi je se kr ratal.

No, al si pa eden izmed redkih na svetu, ki pise turing-complete programe. Tudi v ne turing-complete jezikih. V tem primeru pa iskrene cestitke!

A-242 je izjavil:

Je je, in ogromno si lahko pomagas z debuggerjem, da mu sproti popravljas vrednosti v memoriji in s tem preverjas error handling ipd...


O kristus. No ja, saj imas prav, tudi klesce za puljenje zebljev lahko uporabljas za zabijanje.


Smurf je izjavil:

Hvala fantje, tale tema me je nasmejala in hkrati pokazala kako ponekod izgleda programerski svet izven mojega bubbla.


Jaz sem bolj obstal z grotesknim izrazom na obrazu. Nekak tko k Han Solo, k so ga v carbonite zaprl.

Zgodovina sprememb…

  • spremenil: BigWhale ()

FTad ::

bbbbbb2015 je izjavil:

FTad je izjavil:

Imam teorijo, da tisti, ki so ze v srednji soli/faxu delali zapiske urejeno t.i. uporabljali kakšne barve za podcrtavanje pomembnih delov, razdelili snov v vec manjsih tematsko smiselnih kosov, dajali kako prazno vrstico med sklopi, tudi pri programiranju raje razdelijo kodo v tematsko smiselne sklope za lazje branje.

Vsaj pri meni je tako. Jaz se nisem mogel uciti snovi, napisane na a4 list brez kakih praznih vrstic vmes, vse samo crno belo, prav tako nisem uspel nicesar na hitro najti, kajti vedno je bilo treba brati od zacetka, da najdem potem nekaj na sredini zapiskov.

Menim, da je isto pri pisanju kode. Nekaterim ni problem pisati vsega v eno metodo, dati kak komentar tu in tam in ste s tem zadovoljni, ker ste edini, ki vzdrzujete to kodo.


To je samo tvoja teorija.
V resnici je dosti več. Če jezik obvladaš, če sistem obvladaš, lahko pišeš daljše funkcije. Vsaj v Javi je tako, da je sedaj potrebna velika stopnica, da nekaj obvladaš. Dokler tega ne obvladaš, pišeš krajše kose kode. Dosti je odvisno od orodij. Moderen IDE precej pospeši produktivnost.

Pa še od marsičesa drugega je odvisno. Na primer, če obdeluješ temo, ki jo dobro poznaš (SQL in transakcije) ali pa nekaj, kar ne pozna dobro, recimo kakšno krmiljenje zunanjih naprav.


Ne gre se za to, kako zakomplicirano lahko pišeš in kako dolge so (lahko) funkcije. Gre se za to, da tisto kar si napisal, je za tebe ali pa kolege, ko odpres kodo čez 1 leto, hitro spet razumljivo, kaj si zelel takrat napisati.

A-242 ::

BigWhale je izjavil:

Pics or it didn't happen. Resnicno. Za tvoje zgornje trditve bos moral pokazati kaksne konkretne stevilke al pa enostavno rect, da si stvari zmisljujes in v bistvu nimas pojma kaj govoris. Tvoje nadaljno razlaganje o kvaliteti kadra in o kompetentnih piscih, ki ne rabijo pisati testov pa kaze samo na to, da v resnici pojma nimas kaj so test in kaj je test driven development in kaksen je njihov namen.


Pics or it didnt happen. Za trditve bos moral pokazati kaksne konkretne stevilke, koliko bugov so unit testi preprecili v korelaciji so kompetencami pisca ali enostavno reci, da si zmisljujes in v bistvu nimas pojma kaj govoris. Tvoje razlaganje o *vstavi poljubno besedilo* pa dokazuje da nimas pojma kaj je *vstavi poljubno besedilo*, ne da se mi niti vstavljat besedila v genericne neumnosti, daj si ga sam. Ce delas na aplikacijah (medicinskih npr.) kjer rabis paper trail za preprecevanje tozb, oz. potencialnih sodiscih si excused. Tam imajo smisel in jih rabis. Pa verjetno bi nasel se kaksen promil primerov, ki sem jim naredil krivico.
The world has enough for everyone's needs, but not everyone's greed.
- Mahatma Gandhi

Zgodovina sprememb…

  • spremenilo: A-242 ()

BigWhale ::

A zdaj bos pa se 'to si ti kaj sem pa jaz' idiota igral? Podas izjavo in je ne znas argumentirati?

https://www.microsoft.com/en-us/researc...

http://citeseerx.ist.psu.edu/viewdoc/do...

Preberi ta dva dokumenta, potem ju pa spodbijaj s kaksnimi podobnimi raziskavami. Lahk pa takoj napises, da govoris na pamet in pravzaprav nimas pojma o cem govoris.

Smurf ::

Jaz po pravici se nisem pogruntal ali eni samo tako dobro trolate, ali pa res ne znate uporabljati unit testov. Unit testi so standard v bolj kot ne vsaki na pol resni firmi. Sploh ni diskusija ali jih imeti ali ne. Diskusija je bolj koliksen code coverage je recimo financno optimalen.

Pa spet, preden se Invictus oglasi, pustite hobi projekte, ki jih delate za teto, ki ima spletno trgovino.

BigWhale ::

A-242 je izjavil:

Ce delas na aplikacijah (medicinskih npr.) kjer rabis paper trail za preprecevanje tozb, oz. potencialnih sodiscih si excused. Tam imajo smisel in jih rabis. Pa verjetno bi nasel se kaksen promil primerov, ki sem jim naredil krivico.


Joj, nehaj, prosim. Unit testi in test driven development nimajo prav nobene povezave s tem kar sedaj razlagas. Tko resnicno nobene in vecje neumnosti skoraj ne bi mogel ziniti.

A-242 ::

BigWhale je izjavil:

A zdaj bos pa se 'to si ti kaj sem pa jaz' idiota igral? Podas izjavo in je ne znas argumentirati?

https://www.microsoft.com/en-us/researc...

http://citeseerx.ist.psu.edu/viewdoc/do...

Preberi ta dva dokumenta, potem ju pa spodbijaj s kaksnimi podobnimi raziskavami. Lahk pa takoj napises, da govoris na pamet in pravzaprav nimas pojma o cem govoris.


Ne smejal se ti bom. Papir zdrzi vse, na kar si me opomnil, jaz bom pa tebe.
The world has enough for everyone's needs, but not everyone's greed.
- Mahatma Gandhi

BigWhale ::

Torej, zate velja enako... Si upas povedati kdo je tvoj delodajalec? :D

A-242 ::

Prevec testov sem ze videl v zivljenju, ki so bili management initiated, da sem razvil organski odpor do vsakogar, ki zacne omenjati teste... Ja, ampak ti dam prav, unit testi imajo smisel, ko jih pise clovek, ki ve kaj dela, v vecini primerov so pa sami sebi namen. Ce si nasel sluzbo, kjer ti bojo placali test driven development, good for you.

BigWhale je izjavil:

Torej, zate velja enako... Si upas povedati kdo je tvoj delodajalec? :D


Seveda, zato menjam userja vsakih nekaj mesecov, da ti bom povedal se stevilko noge. Si me pa spomnil, da bo pocasi ze cas...
The world has enough for everyone's needs, but not everyone's greed.
- Mahatma Gandhi

Zgodovina sprememb…

  • spremenilo: A-242 ()

Invictus ::

A-242 je izjavil:

BigWhale je izjavil:

Pics or it didn't happen. Resnicno. Za tvoje zgornje trditve bos moral pokazati kaksne konkretne stevilke al pa enostavno rect, da si stvari zmisljujes in v bistvu nimas pojma kaj govoris. Tvoje nadaljno razlaganje o kvaliteti kadra in o kompetentnih piscih, ki ne rabijo pisati testov pa kaze samo na to, da v resnici pojma nimas kaj so test in kaj je test driven development in kaksen je njihov namen.


Pics or it didnt happen. Za trditve bos moral pokazati kaksne konkretne stevilke, koliko bugov so unit testi preprecili v korelaciji so kompetencami pisca ali enostavno reci, da si zmisljujes in v bistvu nimas pojma kaj govoris. Tvoje razlaganje o *vstavi poljubno besedilo* pa dokazuje da nimas pojma kaj je *vstavi poljubno besedilo*, ne da se mi niti vstavljat besedila v genericne neumnosti, daj si ga sam. Ce delas na aplikacijah (medicinskih npr.) kjer rabis paper trail za preprecevanje tozb, oz. potencialnih sodiscih si excused. Tam imajo smisel in jih rabis. Pa verjetno bi nasel se kaksen promil primerov, ki sem jim naredil krivico.

Jaz ti dam kar lasten primer unit testov, ki sem jih pisal že leta nazaj za testiranje network protokola...

Dobesedno ob prvem zagonutestov našli zoprn bug (lokalno vse delalo), in ni bilo po standardu. Zamenjava little/big endian... Je pač šlo za bolj low level zadeve...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

napsy ::

The ego of some people ... me spominja na debato kdo je dober voznik :) (seveda vsak zase pravi, da je najboljsi)

So doloceni industry best practices, ki dokazano pozitivno vplivajo na kvaliteto kodo in na manjse stevilo bugov. Unit testing je zagotovo ena teh praks, pa ce se kdo se na glavo postavi. Spomnim se nesteto situacij, kjer so me testi resili pred potencialnimi regressioni, kadar sem moral kodo refaktorirat ali pa naredit rewrite dolocenih kosov kode. Sej ni problem, ce imas par 10k vrstic, problem je, kjer imas 100k-200k vrstic kode, ki je po moznost stara vec let.
"If you die, you die. But when you live you live. There is no time to waste."

Smurf ::

A-242 je izjavil:

Prevec testov sem ze videl v zivljenju, ki so bili management initiated, da sem razvil organski odpor do vsakogar, ki zacne omenjati teste...

En nasvet. V profesionalnem svetu ne delati odlocitev na podlagi custev, ampak argumentov.

Na tem mestu lahko razmislis zakaj imas bistveno drugacne izkusnje kot stroka, lahko pa si se naprej zakrivas usesa in ponavljas "lalala".

Btw moznost takih racionalne refleksije loci dobre in povprecne ;).

codeMonkey ::

Smurf je izjavil:

Jaz po pravici se nisem pogruntal ali eni samo tako dobro trolate, ali pa res ne znate uporabljati unit testov. Unit testi so standard v bolj kot ne vsaki na pol resni firmi. Sploh ni diskusija ali jih imeti ali ne. Diskusija je bolj koliksen code coverage je recimo financno optimalen.


Meni je znaimivo, da se pri unit testih omenja le code coverage. Kako resna mora biti firma, da se pri unit testih omenja tudi zahteve :)

kow ::

A-242 je izjavil:


Programiranje je umetnost.


In hkrati obrt. Idealno se kancek razumevanja znanosti. Glorificiranje programiranja me spominja na pumpanje ega pri bodocih pravnikih.

          ::

FTad je izjavil:

Argument sodelavca je, da je nesmiselno dajati ta del kode v manjšo metodo, češ da mora potem klikniti na metodo, da prebere, kako je ta implementirana -> posledično se kode ne da več tekoče brati, saj mora prekiniti branje, ko je treba klikniti na metodo.


Delitev na smislene metode (kakor navajaš zgoraj) je lahko tudi argument za bolj tekoče branje, saj se ti med branjem ni potrebno spuščati v vse detajle. Sicer pa so slogi pisanja kode različni in menim, da tukaj ni "pravilnega" in "nepravilnega" načina pisanja (pustimo ekstreme ...). Nekomu morda ustreza delitev na manjše enote, komu drugemu ne. Jaz svojim zaposlenim ne pridigam kako naj kodirajo, obvezno je edino držanje standarda, ki ga definira Java.
««
2 / 9
»»

Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Python najbolj vroč programski jezik (strani: 1 2 3 )

Oddelek: Novice / Ostala programska oprema		12229136 (23490) BigWhale
»

Unit testing - se poslužujete?

Oddelek: Programiranje		335179 (3329) krneki0001
»

Applov nov programski jezik Swift (strani: 1 2 )

Oddelek: Novice / Apple iPhone/iPad/iPod		7234345 (28906) Kocka
»

Incident Knight Capital in slaba programska oprema, ki poganja svet

Oddelek: Novice / Znanost in tehnologija		4715447 (12354) Poldi112
»

Odkrit resen hrošč v PHP 5.3.7 (strani: 1 2 )

Oddelek: Novice / Varnost		5016996 (14763) Spura

Več podobnih tem