☰

» »

Kako ugotoviti, če si dober

Kako ugotoviti, če si dober

1
2
»

Smurf ::

@BigWhale
Samo ti sedaj govoris o vplivu okolja ne o "trdem delu". Ravno ta primer, da ce z otrokom delas od rojstva je bistveno bolj pomemben dejavnik kot pa zgolj kolicina ur zapravljenih na ne cem.

DavidJ ::

Škoda, da ni nihče prebral vsebine linka, ki sem ga podal. Tam Norvig lepo opiše, od kje teh 10 000 ur pride, in kaj morate v njih početi.

Researchers (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, telegraph operation, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again. There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music.


http://norvig.com/21-days.html
"Do, or do not. There is no 'try'. "
- Yoda ('The Empire Strikes Back')

omnimint ::

Jasno, v idealnem življenju bi programer spisal lepo izpeljano kodo, ki bi 'govorila sama zase', majhne funkcije, opisno poimenovane spremenljivke... kar pa zahteva veliko napora, časa, načrtovanja, sestankov. Težava je v temu, da večina t.i. analitikov tega ni sposobna: največkrat ti pridejo z neizdelanimi zahtevami, ki se čez čas izkažejo za napačne in je treba vse skupaj popravljati. In takrat nastopijo na vrsto komentarji v kodi: kdaj sem moral kodo obrniti, kdo mi je dal ticket,... če ti naslednjič teži, ker je sam pozabil, kaj je naročil, ga lahko hitro najdeš.
Izvirni greh pa je slaba dokumentacija: najprej bi bilo treba problem razčleniti in napisati rešitve v naravnem jeziku, koda mora nato temu slediti.
Na žalost se na te reči gleda preveč kratkoročno, nihče noče vlagati v ta proces, ker se zdi nepotreben strošek. Ko se nekega dne program sesede in nihče ne ve kaj mora v resnici delati je že prepozno in seveda je za to kriv 'nesposoben programer'. Take so moje izkušnje vsaj.

ragezor ::

Zato pa se uveljavlja TDD.

Da najprej napišeš teste kako bi stvar naj delala, potem pa sprogramiraš še dejasnko stvar

nuclear ::

Jaz se strinjam, da dobra koda sama sebe komentira. Preveč komentarjev lahko pomeni, da je koda slaba. Je pa res, da se ne moreš izogniti komentarjem, ker določenih zadev se pač ne da refaktorirat, so pa na koncu še vedno "čudne". To pa se lahko potem spet razglablja o designu kode.

return 1; # returns 1

// Replaces with spaces the braces in cases where braces in places cause stasis
$str = str_replace(array("\{","\}")," ",$str);
Asus G14 2023 - Ryzen 7940HS - 32GB DDR5 - GeForce RTX 4080 - 990 PRO 4TB

Zgodovina sprememb…

  • spremenil: nuclear ()

Mavrik ::

Kdorkoli misli, da so komentarji tam, da razlagajo kaj koda dela, se naj kar doda na listo nezaposljivih.

Kdorkoli misli, da TDD, "literate programming" ali katerakoli druga bedarija zamenja tadrugo vrsto komentarjev, prav tako.
The truth is rarely pure and never simple.

nuclear ::

No, ne tako strogo ;)
Asus G14 2023 - Ryzen 7940HS - 32GB DDR5 - GeForce RTX 4080 - 990 PRO 4TB

Mavrik ::

Do mladih je treba bit strog da se kaj naučijo ;)
The truth is rarely pure and never simple.

omnimint ::

Mavrik je izjavil:

Kdorkoli misli, da so komentarji tam, da razlagajo kaj koda dela, se naj kar doda na listo nezaposljivih.

Kdorkoli misli, da TDD, "literate programming" ali katerakoli druga bedarija zamenja tadrugo vrsto komentarjev, prav tako.

S tem pa nisi kaj dosti povedal.

ragezor ::

Mavrik je izjavil:


Kdorkoli misli, da TDD, "literate programming" ali katerakoli druga bedarija zamenja tadrugo vrsto komentarjev, prav tako.



Kateri vrste so komentarji "tadruge vrste"? Ker komentarji niso samo dveh vrst.

inb4 nisi zaposljiv :D

dmok ::

CodeAsDocumentation

d.

driver_x ::

omnimint je izjavil:

Jasno, v idealnem življenju bi programer spisal lepo izpeljano kodo, ki bi 'govorila sama zase', majhne funkcije, opisno poimenovane spremenljivke... kar pa zahteva veliko napora, časa, načrtovanja, sestankov. Težava je v temu, da večina t.i. analitikov tega ni sposobna: največkrat ti pridejo z neizdelanimi zahtevami, ki se čez čas izkažejo za napačne in je treba vse skupaj popravljati. In takrat nastopijo na vrsto komentarji v kodi: kdaj sem moral kodo obrniti, kdo mi je dal ticket,... če ti naslednjič teži, ker je sam pozabil, kaj je naročil, ga lahko hitro najdeš.
Izvirni greh pa je slaba dokumentacija: najprej bi bilo treba problem razčleniti in napisati rešitve v naravnem jeziku, koda mora nato temu slediti.
Na žalost se na te reči gleda preveč kratkoročno, nihče noče vlagati v ta proces, ker se zdi nepotreben strošek. Ko se nekega dne program sesede in nihče ne ve kaj mora v resnici delati je že prepozno in seveda je za to kriv 'nesposoben programer'. Take so moje izkušnje vsaj.


A potem tudi mail, ki ga pišeš, najprej napišeš na papir in ga šele nato pretipkaš?

WarpedGone ::

komentar kode mora pojasnit zakaj je koda kakršna je. Kadar je to očitno iz kode same, komentar pač ni potreben, sicer je pa nujen a prepogosto vseeno manjkajoč.
Je tudi bistvena razlika kaj je pomembno v kodi nekega oneoff toola kaj pa v recimo kodi zadeve ki živi (se aktivno nadgrajuje) že 15 let in je koda šla že skozii roke N ljudi. človeške glave majo omejen volumen, tudi najhuj genij ima svoj max. Kompleksnost programskih sistemov komot presega ta max, sploh skozi daljši čas.
Zbogom in hvala za vse ribe

omnimint ::

driver_x je izjavil:

omnimint je izjavil:

Jasno, v idealnem življenju bi programer spisal lepo izpeljano kodo, ki bi 'govorila sama zase', majhne funkcije, opisno poimenovane spremenljivke... kar pa zahteva veliko napora, časa, načrtovanja, sestankov. Težava je v temu, da večina t.i. analitikov tega ni sposobna: največkrat ti pridejo z neizdelanimi zahtevami, ki se čez čas izkažejo za napačne in je treba vse skupaj popravljati. In takrat nastopijo na vrsto komentarji v kodi: kdaj sem moral kodo obrniti, kdo mi je dal ticket,... če ti naslednjič teži, ker je sam pozabil, kaj je naročil, ga lahko hitro najdeš.
Izvirni greh pa je slaba dokumentacija: najprej bi bilo treba problem razčleniti in napisati rešitve v naravnem jeziku, koda mora nato temu slediti.
Na žalost se na te reči gleda preveč kratkoročno, nihče noče vlagati v ta proces, ker se zdi nepotreben strošek. Ko se nekega dne program sesede in nihče ne ve kaj mora v resnici delati je že prepozno in seveda je za to kriv 'nesposoben programer'. Take so moje izkušnje vsaj.


A potem tudi mail, ki ga pišeš, najprej napišeš na papir in ga šele nato pretipkaš?

Si že kdaj programiral? Ker očitno ne razumeš.

Red_Mamba ::

driver_x je izjavil:

thramos je izjavil:

Nekomentirana koda in slabo komentirana koda (pa čeprav je komentarjev veliko) sta približno enako slabi.


To je mit, ki ga učijo v šolah. Kaj dela koda ali del kode je povsem jasno razvidno iz kode same. Dober programer lahko kodo piše in bere!


Ce bi ST mel like button bi si ga ta post zasluzil :D
[st.slika https://img.shields.io/badge/Slo-Tech-green.svg test]
Linkedin >> http://goo.gl/839Aua
Mamba's Crypto & ICO's: https://t.me/joinchat/AAAAAExTkO4P4UDy0fIZdg

BigWhale ::

Red_Mamba je izjavil:

driver_x je izjavil:

thramos je izjavil:

Nekomentirana koda in slabo komentirana koda (pa čeprav je komentarjev veliko) sta približno enako slabi.

To je mit, ki ga učijo v šolah. Kaj dela koda ali del kode je povsem jasno razvidno iz kode same. Dober programer lahko kodo piše in bere!

Ce bi ST mel like button bi si ga ta post zasluzil :D


V oni drugi temi boste pa jamrali, da vas nihce noce zaposliti in da morate delati za 800 EUR na mesec z vaso univerzitetno izobrazbo al pa clo magisterijem. Tle vas pa en kup dokazuje, da nimate pojma kaj je dobra praksa programiranja, kaksni so razlogi, da se dolocene stvari v kodi komentirajo in kako dobro dokumentirana koda sploh zgleda.

Morda lahko razumes deset tisoc vrstic "lepo" napisane kode, da bi pa kdo razumel nekaj sto tisoc vrstic kode je pa utopija. Enostavno je prevec stvari, ki jih je treba vedeti. Poleg tega je pravilno komentirana koda v veliko pomoc tudi IDE vmesnikom, saj te ob uporabi neke funkcije (metode za Java people ;>) ze vnaprej opozori o obveznih in neobveznih parametrih, kar pomeni, da ne rabis takoj iskat kje ta funkcija je, kaksne parametre pricakuje in kaj vraca.

Kadar delas s strojno opremo so komentarji precej nujna zadeva, ker imas potem v kodi bizarnosti kjer nekaterim spremenljivkam 'randomly' pristevas/odstevas/bit shiftas neke 'random' vrednosti, v resnici gre pa za workarounde buggy hardware-a. Ali pa popravljanje kake pokvarjene knjiznice.

So stvari, ki jih nobena 'razvojna paradigma' ne resuje ... test driven development ... hehe ..., vse kar ostane je 'Comment Your Code, Morons'.

urosz ::

BigWhale mogoče kak primer za tvoje pojme dobro komentirane kode? Ker očitno samo ti veš, vsi ostali na s-t pa slabo komentirajo kodo oz. nasploh pišejo zanič kodo.

Red_Mamba ::

BigWhale je izjavil:

Red_Mamba je izjavil:

driver_x je izjavil:

thramos je izjavil:

Nekomentirana koda in slabo komentirana koda (pa čeprav je komentarjev veliko) sta približno enako slabi.

To je mit, ki ga učijo v šolah. Kaj dela koda ali del kode je povsem jasno razvidno iz kode same. Dober programer lahko kodo piše in bere!

Ce bi ST mel like button bi si ga ta post zasluzil :D


V oni drugi temi boste pa jamrali, da vas nihce noce zaposliti in da morate delati za 800 EUR na mesec z vaso univerzitetno izobrazbo al pa clo magisterijem. Tle vas pa en kup dokazuje, da nimate pojma kaj je dobra praksa programiranja, kaksni so razlogi, da se dolocene stvari v kodi komentirajo in kako dobro dokumentirana koda sploh zgleda.

Morda lahko razumes deset tisoc vrstic "lepo" napisane kode, da bi pa kdo razumel nekaj sto tisoc vrstic kode je pa utopija. Enostavno je prevec stvari, ki jih je treba vedeti. Poleg tega je pravilno komentirana koda v veliko pomoc tudi IDE vmesnikom, saj te ob uporabi neke funkcije (metode za Java people ;>) ze vnaprej opozori o obveznih in neobveznih parametrih, kar pomeni, da ne rabis takoj iskat kje ta funkcija je, kaksne parametre pricakuje in kaj vraca.

Kadar delas s strojno opremo so komentarji precej nujna zadeva, ker imas potem v kodi bizarnosti kjer nekaterim spremenljivkam 'randomly' pristevas/odstevas/bit shiftas neke 'random' vrednosti, v resnici gre pa za workarounde buggy hardware-a. Ali pa popravljanje kake pokvarjene knjiznice.

So stvari, ki jih nobena 'razvojna paradigma' ne resuje ... test driven development ... hehe ..., vse kar ostane je 'Comment Your Code, Morons'.


Nikol koncal faksa. Nikoli komentiral kode.
Pa ta "Moron" zasluzi vec k 99% k dela zgornji 2 stvari.
[st.slika https://img.shields.io/badge/Slo-Tech-green.svg test]
Linkedin >> http://goo.gl/839Aua
Mamba's Crypto & ICO's: https://t.me/joinchat/AAAAAExTkO4P4UDy0fIZdg

phyro ::

to da je vedno jasno in razvidno ni res (usaj ne iz prve :)) in lahko zgubiš precej časa z razumevanjem zakaj je stvar napisana tako kot je, medtem ko bi lahko komentar enostavno povedal o čem se gre. BigWhale je dal lep primer z raznimi čudnimi 0xe432ff seštevanji in podobnimi (ki jih načeloma nima smisla vedet na pamet). Kaj je lepo komentirana koda je najbrž tudi malo subjektivna reč, ker je usak navajen svojih praks, vsak ima svoj način razmišljanja in niso vsem stvari enako razumljive (recimo da je programer matematik in uporabi neko optimizacijo, ki jo računalničarji običajno ne poznajo... matematikom morda zadostuje samo kratek opis, drugim mogoče več, to je sicer redek primer). Osebno imam raje daljšo razlago kot kratko, čeprav bi morda večina kratko razumela u izi. Meni je recimo uredu "dokumentirana/komentirana" recimo tale koda: sessions.py
Kdaj si dober? odvisno s čim se stvar primerja. To da zaposlijo le najboljše se mi zdi navaden bullshit (taki in podobni oglasi mi zvenijo kot da jih vodi nek ekonomist, ki nima blage o računalništvu in želi najboljše iz kadra :)).
Al si al nisi dober se sploh ne splača sekirat pomojem. Dokler te stvar zanima in se učiš novih tehnologij, novih načinov razmišljanja te najbrž nima kaj skrbet, če si pa eden tistih, ki reče "važno da dela", je pa precej možno da te bo z leti čas povozu.

P.S. Take it easy on me, mnenje ne bazira na podlagi izkušenj ker jih nimam veliko

nuclear ::

BigWhale je izjavil:


Morda lahko razumes deset tisoc vrstic "lepo" napisane kode, da bi pa kdo razumel nekaj sto tisoc vrstic kode je pa utopija.


Brez sarkazma, a to sploh obstaja v novejših projektih? V starih projektih starih 20 let razumem, da bo nekdo tišal tono kode v en "fajl", danes se koda razbija na več fajlov(razni patterni), tako da struktura je boljša in se določene zadeve lažje najdejo. Kar je fant želel povedati je to, da če je koda dobra, potem je sama seb komentar. In če je koda dobro sprogramirana in razumljiva takoj na oko, potem so komentarji za ta del kode redundantni.
Asus G14 2023 - Ryzen 7940HS - 32GB DDR5 - GeForce RTX 4080 - 990 PRO 4TB

BigWhale ::

Red_Mamba je izjavil:

Nikol koncal faksa. Nikoli komentiral kode.
Pa ta "Moron" zasluzi vec k 99% k dela zgornji 2 stvari.


Ce kodiras tko k citiras, ... Pa cist vseen kolk zasluzis. :>

BigWhale ::

nuclear je izjavil:

V starih projektih starih 20 let razumem, da bo nekdo tišal tono kode v en "fajl", danes se koda razbija na več fajlov(razni patterni)

Kdo pa govori o vsej kodi v eni datoteki?

nuclear je izjavil:

Kar je fant želel povedati je to, da če je koda dobra, potem je sama seb komentar. In če je koda dobro sprogramirana in razumljiva takoj na oko, potem so komentarji za ta del kode redundantni.


To kar je fant povedal naceloma drzi. Vcasih je pa treba poslusati se kaksnega moskega. ;> Koda, ki bi bila sama po sebi razumljiva na nekem vecjem projektu je zelo redka. Sploh, ko razvijas kak API, ki ga bodo drugi uporabljali. Takrat ponavadi napises dokumentacijo prej, da oni, ki bo API uporabljal ve kaj bos spisal in lahko vzporedno dela na necem, ceprav mu se 'taglavni' del manjka. In med pisanjem APIja komentiras razrede, metode, funkcije, return vrednosti. Ce ne zaradi drugega, pa zaradi tega, da se ti potem clickable API dokumentacija sama ustvari.

Tako kot je en prej gor komentiral "return (1);" ne komentiras z "/* returns one */"

Vsakic, ko naletis na kak quirk, kjer je treba kaka telovadba, to komentiras. In razlozis zakaj je blo to narjen. Ce ne mas na koncu v kodi en kup IF stavkov (switch/case, ce vam je ljubse), za katere nihce ne ve tocno zakaj je tam.

Spura ::

phyro je izjavil:

Meni je recimo uredu "dokumentirana/komentirana" recimo tale koda: sessions.py

Primerjaj stevilo uporabnikov, programerjev in porabljenih ur na sessions.py s stvarmi ki jih sam napises. Logicno da je toliko komentirano.

BigWhale je izjavil:


Morda lahko razumes deset tisoc vrstic "lepo" napisane kode, da bi pa kdo razumel nekaj sto tisoc vrstic kode je pa utopija.

In zakaj bi kdo rabil razumet sto tisoc vrstic kode naenkrat?
1. Taksen codebase pokriva ponavadi vec ljudi, s tem da se vecina ukvarja z moduli, ki so precej manjsi in so neodvisni od ostale kode.
2. Ce je zadeva dobro napisana ti ni treba razumeti vec kot kakih 10 classov naekrat (ce stejemo implementacije istega interfacea kot en class), ker imeti procese, kjer medsebojno sodeluje 100 classov je dost butasto in je neobvladljivo tudi ce imas vsako vrstico komentirano.
3. Kompleksnost ne izvira iz stevila vrstic ampak iz stevila medsebojnih interakcij classov

V vecini primerov imam okoli dva komentarja na 1000 vrstic. Lahko bi bilo vec, ampak ni krize. Vec komentiram predvsem kake public APIje, pa tudi tam se v nekaterih primerih lahko izognes komentarjem. Vcasih je treba komentirat kake assumptione (pa ne trivialne, kot to da parameter ne sme biti null).

Mavrik ::

To ti delaš z nekim čudnim softwarom. Kak laboratorij / faks / akademija morda?
The truth is rarely pure and never simple.

driver_x ::

Seveda pa nikakor ne moremo posploševati, kajti imamo različne programske jezike, različno zahtevno vsebino projektov, različen obseg projektov, različno število razvijalcev, ipd.

Ko sem pred 15-20 leti začenjal s temi rečmi, sem tudi sam napisal raje kakšno vrstico komentarjev preveč, kakor premalo. Vmes sem spoznal, da tudi popravljanje nekomentirane kode za kom drugim ni tak bavbav, kot sem sprva mislil.

Ko sem nazadnje pred nekaj leti delal na poslovnih aplikacijah v Javi EE, komentarji skoraj niso bili potrebni, saj je bila koda že sama po sebi dovolj zgovorna, upoštevajoč relativno enostavno razumljivo vsebino aplikacije. K temu je dodatno pripomoglo tudi upoševanje pravil za pisanje kode, ki veljajo v Javi. Koda je obsegala cca. 250.000 vrstic, vendar so bili razredi in metode postavljeni dovolj intuitivno in razumljivo.

Se pa čisto strinjam, da so komentarji v kodi na nižjih nivojih, kakor navaja BigWhale, še kako potrebni.

111111111111 ::

OK, za komentarje ne bom pametoval, jaz jih pišem, kolega pa ima raje dolga imena spremenljivk, ki baje povejo več kot komentarji. Jaz komentiram PHP kodo in potem ustvarim iz tega dokumentacijo. Komentiram C++ kodo in ustvarim dokumentacijo.

Ampak dokumentacija fantje, dokumentacija: opisi razredov, funkcij, metod itd...

Roko gor tisti, ki programirate in niste nikoli brskali po dokumentaciji (Java, C++, ...) in tu in tam zgubili živce. :)

Nič ti ne pomaga odličen programski jezik brez ustrezne dokumentacije in pojasnil.
Brez dokumentacije ni dobre aplikacije, pa če komentirate ali ne. Nekdo ki pride za vami ne bo vedel nič, pa je lahko profi v branju kode. Sami se lahko 1 leto kasneje zgubite v lastni kodi.

Sam rešujem vprašanje dokumentacije s komentarji me pa zanima kako zadevo spravite vi. Pri projektu mi je osebno to najtežji del, da bo za mano nekdo znal brati in takoj poiskati zadevo, če se bo delala nadgradnja, optimizacija...

phyro ::

Spura je izjavil:

phyro je izjavil:

Meni je recimo uredu "dokumentirana/komentirana" recimo tale koda: sessions.py

Primerjaj stevilo uporabnikov, programerjev in porabljenih ur na sessions.py s stvarmi ki jih sam napises. Logicno da je toliko komentirano.


Sicer je res, da je koda namenjena veliki skupini uporabnikom, sam nisem to mislu s tem (oz. moje mnenje ni blo povezano s tem). Kar se mi dopade tuki je razmerje kode in dokumentacije oz. komentarjev. Tudi če sam delam na projektu, raje imam tako lepo dokumentirano (oz. kar se da temu podobno, običajno daleč od tega, but what the heck)

draciel ::

Mavrik je izjavil:

Kdorkoli misli, da so komentarji tam, da razlagajo kaj koda dela, se naj kar doda na listo nezaposljivih.

Kdorkoli misli, da TDD, "literate programming" ali katerakoli druga bedarija zamenja tadrugo vrsto komentarjev, prav tako.


Hmm, prosim obrazloži tole. Zakaj točno so potem komentarji kot pa da nekomu / tebi (čez nekaj časa), pač povejo kaj koda dela, brez da bi seveda porabil celo uro in razbral iz kode sam. Torej, zakaj obstajajo t.i komentarji v kodi Mavrik?

Mavrik ::

draciel je izjavil:


Hmm, prosim obrazloži tole. Zakaj točno so potem komentarji kot pa da nekomu / tebi (čez nekaj časa), pač povejo kaj koda dela, brez da bi seveda porabil celo uro in razbral iz kode sam. Torej, zakaj obstajajo t.i komentarji v kodi Mavrik?


Ideja je da komentarji razlagajo ZAKAJ, ker koda zna samo povedati KAJ in da bralcu prihranijo čas.

Recimo poglej si tipičen primer kode in komentarja zgoraj v sessions.py:
            # Google chrome does not like cookies set to .localhost, so
            # we just go with no domain then.  Flask documents anyways that
            # cross domain cookies need a fully qualified domain name
            if rv == '.localhost':
                rv = None


Vidiš, da komentar razloži ZAKAJ je bilo potrebno odstraniti .localhost, ker tega koda sama po sebi ne zna povedati. Manjko teh komentarjev zna biti glavni razlog za ogromne glavobole pri vzdrževanju programske opreme - ker je nekdo pozabil napisati (ali misli da je tak car da bo itak očitno) kaj je bil namen tistega hacka, workarounda, vrstnega reda izvajanja, izbire čudne podatkovne strukture, etc.

Druga stvar je, ko imaš res kako klobasasto kodo s kakšnega razloga (tipično recimo si rabil optimizirati kakšen algoritem, kar je močno zbilo preglednost) in lahko bralcu prišparaš minute razbijanja glave s preprostim stavkom "to je optimiziran algoritem za sortiranje po naravnem vrstnem redu".

Podobna fora kot z dokumentacijo parametrov metod, return type-a in (v dinamičnih jezikih) pričakovanih tipov parametrov ter vrnjenih vrednosti. Če je kdorkoli uporabljal scipy, matplotlib, pyopencv in podobne zadeve bo hitro se spomnil kako zabavno je branje klobasaste kode ker se nekomu ni dalo napisati katere exceptione lahko pričakuješ in v kateri obliki se pričakujejo podatki na vhodu.

Pač je čist simpl: don't be a dipshit. Če misliš da si tak car da nikoli ne rabiš komentarjev, potem pač nočem delati s tabo, ker malo bolj kompleksne kode, ki je straightforward pač ni.
The truth is rarely pure and never simple.

Isotropic ::

jah to je edini nacin, da postanes nepogresljiv:D

BigWhale ::

Isotropic je izjavil:

jah to je edini nacin, da postanes nepogresljiv:D


Na Ministrstvu za Finance so mel boljse nacine:

int main() {
  read_cnt_from_db();
  if (cnt > 100000) {
    printf("Prislo je do kriticne napake! Poklici programerja!");
    return (-1);
  }
  while (do_stuff()) {
    randomly_increase_cnt();
    write_cnt_to_db();
  }
}


Programer je mel skoz ful dela! Iz kakih desetih uradov so ga vsaj enkrat na teden poklicali in je moral popravljati napake na programih. Dejansko je bil nepogresljiv. :>

Red_Mamba ::

BigWhale je izjavil:

Red_Mamba je izjavil:

Nikol koncal faksa. Nikoli komentiral kode.
Pa ta "Moron" zasluzi vec k 99% k dela zgornji 2 stvari.


Ce kodiras tko k citiras, ... Pa cist vseen kolk zasluzis. :>


Delam v UK in nimam slo tipkovnice ce te to moti :D
[st.slika https://img.shields.io/badge/Slo-Tech-green.svg test]
Linkedin >> http://goo.gl/839Aua
Mamba's Crypto & ICO's: https://t.me/joinchat/AAAAAExTkO4P4UDy0fIZdg
1
2
»

Vredno ogleda ...

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

Analiza kode: goto rabimo po pameti

Oddelek: Novice / Znanost in tehnologija		2913853 (10413) one too many
»

Svež popravek za od mrtvih obujen Windows XP (strani: 1 2 )

Oddelek: Novice / Varnost		9444020 (38678) MrStein
»

Incident Knight Capital in slaba programska oprema, ki poganja svet

Oddelek: Novice / Znanost in tehnologija		4715524 (12431) Poldi112
»

PHP in objektno programiranje (strani: 1 2 )

Oddelek: Programiranje		8512153 (10620) kivi113

Več podobnih tem