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

blay44 je 22. dec 2020 ob 15:59 izjavil:

No senior profesionalci, je smiselno drobit kodo na posamezne funkcije in s tem pumpati stack, al ne?
Pri malih zdevščinah včasih premišljujem, če ne bi bilo bolje uporabljati "inline" kot pa riniti na sklad.
V x86/x64 se že lahko delate junake.

Največji problem predstavljajo loopi. In potem če delaš nevede loope znotraj loopov da pridobiš neko vrednost, kar bi lahko naredil že prej ipd.

Smurf je 22. dec 2020 ob 22:31 izjavil:

Tako je, to je dober primer nepravilne uporabe komentarjev.

V resnici bi se to bolje imenovalo segmentiranje/kategoriziranje kode. Če vsakemu segmentu daš še naslov (komentar) je koda še toliko bolj berljiva. Saj ste videli, da je bil komentar samo 1 beseda. Če bi bili namesto 1 besede dolgi stavki potem bi bilo že malo mimo, s tem se strinjam.

Če že ne komentirate vsaj upam, da kodo segmentirate, ne pa namečete vse skupaj?

Človeški možgani lažje razumejo stvari, ki so kategorizirane in ki so majhne. Jaz kodo kategoriziram v majhne segmente. Par vrstic oziroma kolikor je logično možno. Programirat moraš tako, da bo čimlažje razumet kodo, tudi če izpadeš kot začenik, ne pa da boš izpadel kul, kako si pameten, ker noben ne razume tvojih špagetov.

Ah BigWhale, naiveni BigWhale :) taksni kot so nekateri posamezniki tu v temi zares obstajajo. Mislim da ne trollajo, pac so na junior nivoju. Sicer brez veze obsojat, vsak se je moral se nekoc naucit.

kuall je 23. dec 2020 ob 20:09 izjavil:

Zato jaz raje napišem po točkah, kako se program stestira. Točno kaj moraš vnesti, kaj klikniti in kakšne rezultate moraš pričakovati.

To se slisi kot E2E testi. Mogoce lahko naslednjic namesto docx/pdf fajla vzames nek E2E testing framework, pa te korake tam opises.

korenje3 je 23. dec 2020 ob 10:50 izjavil:

Največji problem predstavljajo loopi. In potem če delaš nevede loope znotraj loopov da pridobiš neko vrednost, kar bi lahko naredil že prej ipd.

Ja. To sem se na žalost sam naučil. So šle proste urice.
Sicer sem bolj young junior, sem pa razumel point seniorjev.

Točno kaj moraš vnesti, kaj klikniti in kakšne rezultate moraš pričakovati.

Če vneseš točno tisto kar bi "moral" in klikneš tisto kar bi "moral", skoraj vsak program dela prav. Problemi so ko se vnese in klikne kaj kar naj ne bi "moral".

kuall je 23. dec 2020 ob 20:09 izjavil:

shadeX je 22. dec 2020 ob 19:32 izjavil:

Mene bolj zanima kako vi pišete dokumentacijo za sisteme, module, razrede? Npr kakšne informacije točno se zahteva da dokumentirate v podjetjih ki delate?

Včasih se piše dolge specifikacije, ki jih potem noben ne bere, ker so predolge in suhoparne.

Veliko bolj uporabno kot neke specifikacije bi bila navodila za uporabo programa za telebane. Ampak tudi te imajo veliko nevarnost, da jih ne bo noben bral, ker bodo neuporabna in zanič napisana, v nobeno pomoč.

Zato jaz raje napišem po točkah, kako se program stestira. Točno kaj moraš vnesti, kaj klikniti in kakšne rezultate moraš pričakovati. Tisto je pa uporabno kot hudič. Obenem so tudi izvrstna navodila, kako se program uporablja in kaj je njegov namen. To naredim za vse bolj kompleksne programe, ker vem, da bo huda kriza čez 1 leto, ko bom že vse pozabil. Za majhne pa ni potrebno seveda. Po občutku.

Čakaj, mešaš 3 povsem različne zadeve...

1. Specifikacije, oz. nek design mora biti. Če project manager in arhitekt tega ne znata razbiti na taske, naj zamenjata službo.

2. Navodila za telebane so spet nekaj drugega-. Pa naj bo to končni uporabnik ali tester.

3. Ja, to je del test scenarija. Navodila, kako se testira... Ne sme biti pa to edini papir...

Na koncu moraš pač napisati vse, samo programerjem se ne da napisati nič. Videno velikokrat in če ni trde roke, na koncu tudi ni nič napisano. Saj se folk hitro navadi napisati nekaj besed...

Asserti so čist kul razen tega, da pogršajo kodo. Nikoli jih ne more bit preveč.
Zgleda da GO sploh nima debug in release verzije.

Drugače pa lahko sam narediš debug verzijo...

Narediš package is...

// +build debug

package is

// Debug mode
const Debug = true

// +build !debug

package is

// Debug mode
const Debug = false

Pol pa debug kodo prevedeš s tagom debug. V kodi poljubno pišeš is.Debug... in če bo is.Debug false bo prevajalnik ven zmetal celoten is.Debug if blok

assert - ja, za vsako stanje, ki je 'nemogoce'. Itak pisem C++, tako, da jih obcutim samo jaz.
Sicer pa - razdeliti funkcijo na vec manjsih funkcij se mi zdi zelo smiselno. Vsaka naj ima najvec 3 parametre. Ce ne gre drugace, naredis strukturo, ki jo nato uporabis za argument.

Ciljam na to, da vse funkcije pridejo na en ekran - cca 40 vrstic. Izjema so kaksne funkcije za prenos parametrov.

Zato jaz raje napišem po točkah, kako se program stestira. Točno kaj moraš vnesti, kaj klikniti in kakšne rezultate moraš pričakovati. Tisto je pa uporabno kot hudič. Obenem so tudi izvrstna navodila, kako se program uporablja in kaj je njegov namen. To naredim za vse bolj kompleksne programe, ker vem, da bo huda kriza čez 1 leto, ko bom že vse pozabil. Za majhne pa ni potrebno seveda. Po občutku.

Tnx za odgovor, neki je pomagal.

Na koncu moraš pač napisati vse, samo programerjem se ne da napisati nič. Videno velikokrat in če ni trde roke, na koncu tudi ni nič napisano. Saj se folk hitro navadi napisati nekaj besed...

I can relate. Kot 100% samouk (brez mentorja, šole ali kakšne druge strokovne podlage), sem po dolgem času ugotovil da je dokumentacija nujno zlo, ki hočeš nočeš mora obstajat. Ugotovil sem namreč da sem napisal že kar nekaj manjših sistemov, ki interaktajo med seboj, nakar ugotovil čez čas da nimam pojma:

1. Kaj VSE zadeva dela
2. Kaj je avtomatizirano
3. Kako uporabim to zadevo v naslednjem projektu (glej še enkrat točko 2)

Naivno sem mislil da ker je moja koda bom že vedel ampak daleč od resnice.

Problem, ki ga imam/imel pri pisanju dokumentacije je ta, ker preprosto ne vem kaj vse moram vključiti v njo - kaj bo prineslo večjo vrednost in obenem da dokumentacija ne bo kot roman, ker ne bo noben bral.

Zato sem ustvaril nek "template", po katerem delam in napišem tiste vredne informacije, ampak se poskušam držati načela da mora biti dovolj jasna da vsak razume kako sistem dela in kaj mora uporabiti tudi če ni programer (ni tako enostavno, ker lahko hitro napišeš "preveč").

Kakorkoli, če ti teh stvari noben ne pove je zadeva lahko izjemno time consuming, ker se pač učiš iz napak.

krho je 24. dec 2020 ob 09:19 izjavil:

...Pol pa debug kodo prevedeš s tagom debug. V kodi poljubno pišeš is.Debug... in če bo is.Debug false bo prevajalnik ven zmetal celoten is.Debug if blok

Gre se za lovljenje bugov v produkciji in panic() povzroci, da se program usuje, ce tega nisi prej ujel nekje. Pri Go so sli celo tako dalec, da so zagovarjal "crash early", kar je no-go pri HA.

Mnja.. ne ga panic ne usuje (no terminira).. ker imam recover handler/interceptor vsaj tam, kjer se servirajo zahtevki...

Java je sitna z tistim objektnimi pristopom in potem vse skupaj rata dolgo za popizdit. Sam imam monitorje kjer je koda v portrait modu.

BigWhale je 25. dec 2020 ob 12:25 izjavil:

bbbbbb2015 je 24. dec 2020 ob 13:22 izjavil:

Koda, ki je omejena na 80 znakov, je na enem 27" ekranu videti smešna. 3/4 ekrana je praznega. V prejšnjem timu smo se vsi strinjali, da je omejitev na 80 znakov za leto 2015 nekoliko majhna, ter smo takrat soglasno kodo preformatirali na 130 znakov.

Vse kar je vec kot 120 znakov je resnicno veliko. Jaz imam nastiman soft limit na 80 znakov in hard limit na 120 znakov. Seveda je pri jezikih, kjer so imena funkcij in spremenljivk dolga, vcasih tezko priti pod 120 znakov, sploh ce se uporablja se inline HTML. Ampak pri nekem backend delu, kjer nimas teh reci, je pa 120 znakov vrh glave in ce rabis vec, potem mors resno razmislit o tem zakaj rabis vec.

Ce imas toliko nivojev gnezdenja, da ti je 120 znakov komaj dovolj, potem je cas za refactoring, ce imas tako dolga imena potem se je treba tudi vprasat a je to smiselno. Ce imas tako dolge pogoje v zankah in pogojnih stavkih, potem se splaca razmislit ali ni bolje treh && napisat v vecih vrsticah, ker jih tako lazje preberes in ugotovis kaj pocne tisti pogoj.

bbbbbb2015 je 24. dec 2020 ob 13:22 izjavil:

Pa ne samo to. Vsi uporabljamo isti font za razvoj - Deja Vu:
https://dejavu-fonts.github.io/

Splaca se sprobat Jetbrains Mono font z ligaturami za razlicne operaterje.
https://www.jetbrains.com/lp/mono/

Pa daj ne bluzi poštar o stvareh ki jih nisi počel. Imena so definirana v frameworku. Že imena razredov so dolga, dodaj še metode pa si na 60 znakih dok ne rečeš keks. Kdor bi mi šel pa refaktorirat kodo zaradi gnezdenja, ga pa lastnoročno odnesem od mašine.
Bebcem dat v roke refactoring orodja je greh.

Že že, pri ogromnih projektih je refractoring neizogiben, pa še tam je bolje cel modul na novo napisat, če že pride do tega.

Ni pa potreben pri stvareh, ki jih BigWhale dela. Javascript skripte in podobna jajca.

BigWhale je n00b. Dober dđouk.


Evo moj sample "refaktoring-a". Prvotna funkcija:

def getdate():
    dtstart = datetime.datetime.now();
    day = dtstart.day;
    if len(str(day)) == 1:
        day = "0" + str(day);
    month = str(dtstart.month);
    if len(str(month)) == 1:
        month = "0" + str(month);
    _date = str(dtstart.year) + "-" + str(month) + "-" + str(day);
    return _date;

Kasneje sem odkril funkcijo zfill in zadeve popravil:

def getdate():
    dtstart = datetime.datetime.now();
    day = str(dtstart.day).zfill(2);
    month = str(dtstart.month).zfill(2);
    _date = str(dtstart.year) + "-" + str(month) + "-" + str(day);
    return _date;

In od prej imam notri dtstart, kar bom enkrat tudi popravil na dtnow. Mogoče kr zdele. Pa tudi _date v dstring.

Spreminjat je nisem šel za brezveze; ko sem funkcijo pisal, nisem pozan zfill, katerega sem potem napisal "na roke". Kasneje, ko sem to funkcijo odkril, sem tisto "na roke" popravil in zamenjal z za to namenjeno (že razvito) funkcijo.

BigWhale govori o nekem clusterfuck programiranju. Pol pa grem gledat njegovo github kodo in programira točno tako, kot jaz svetujem. Kodo je razdelil v bloke, vsakemu bloku je dal komentar. WTF. Kako se to razlikuje od tistega mojega originalnega komentarja? Ali se kregamo samo zato, da se kregamo?

Edino zadnji blok bi jaz stlačil skupaj in mu dal naslov
// Print results.
za večjo preglednost.

void setup() {
  Serial.begin(115200);
  while(!Serial) {} // Wait

  // Pin setup
  pinMode(LED_BUILTIN, OUTPUT);

  // Set default LED states
  digitalWrite(LED_BUILTIN, HIGH);  // Builtin LED needs to be set to LOW to turn it off
  for (int i = 0; i < 5; i++) {
    digitalWrite(leds[i], LOW);
    pinMode(leds[i], OUTPUT);
  }

  // Initialize relays
  for (int i = 0; i < 4; i++) {
    digitalWrite(relay[i], HIGH);
    pinMode(relay[i], OUTPUT);
  }

  flash_leds();

  // Set WIFI mode
  WiFi.mode(WIFI_STA);
  WiFi.disconnect();
  delay(200);

  // Connect to WiFi
  while ( status != WL_CONNECTED) { 
    digitalWrite(LED_AMBER, HIGH);
    digitalWrite(LED_RED, LOW);
    status = WiFi.begin(ssid, pass);
    delay(10000);
  }
  digitalWrite(LED_AMBER, LOW);

  // Star Wire protocol
  Wire.begin();
  while(!airSensor.begin(BME_ADDRESS)) {
    Serial.println("Could not find BME280I2C sensor!");
    delay(1000);
  }
  
  waterSensor.begin();
  Serial.print("Found ");
  Serial.print(waterSensor.getDeviceCount(), DEC);
  Serial.println(" sensor devices.");

  if (!waterSensor.getAddress(waterSensorAddress, 0)) {
    Serial.println("Unable to find address for water sensor."); 
  }
}

Zimonem je 25. dec 2020 ob 20:47 izjavil:

Pa daj ne bluzi poštar o stvareh ki jih nisi počel. Imena so definirana v frameworku. Že imena razredov so dolga, dodaj še metode pa si na 60 znakih dok ne rečeš keks. Kdor bi mi šel pa refaktorirat kodo zaradi gnezdenja, ga pa lastnoročno odnesem od mašine.
Bebcem dat v roke refactoring orodja je greh.

A se potegujes za kak nov naziv al sam tko mal na pamet zalis, ker ne ves vec kaj bi povedal?

kuall je 25. dec 2020 ob 21:41 izjavil:

Refraktoriranje? To sem včasih delal, ko sem bil nov. Zdaj napišem 1x in pustim tako kot je prvič ratalo. Prej raje malo bolj premislim, da ne bom imel dela s spreminjanjem. Refraktoriranje je zguba časa in vnaša nove buge.

Posebej mim so taki programerji, ki prevzamejo nek nov projekt in ga na veliko spreminjajo.

Po tem kar pises, se mi zdi, da verjetno se nimas izkusenj s kaksnimi bolj resnim razvojem, na projektu, ki je ziv vec let in na katerem dela vec ljudi v skupini. Do sedaj je vecina tega kar si povedal skregana z vsemi dobrimi praksami v razvoju.

No ampak, kot sem ze rekel, ce je vsa tvoja koda turing-complete, potem obstaja verjetnost, da vse napises dobro v prvo. Si pa edini na svetu, ki to pocne. Cestitke.

kuall je 26. dec 2020 ob 01:45 izjavil:

BigWhale govori o nekem clusterfuck programiranju. Pol pa grem gledat njegovo github kodo in programira točno tako, kot jaz svetujem. Kodo je razdelil v bloke, vsakemu bloku je dal komentar. WTF. Kako se to razlikuje od tistega mojega originalnega komentarja? Ali se kregamo samo zato, da se kregamo?

Joj, googlat si sel mojo kodo, jo dejansko odprl in zdej jo sem pastas? Lahk bi vsaj link do celega Github projekta dal. :> Cestitke za uporabo Googla! Nasel si moj hobi projekt, ki je napisan primarno za Arduino community z nekim tihim upanjem, da se bo iz njega se kdo cesa naucil. :) Saj vem, projekt itak sucks, ker ima zraven celo navodila za namestitev in opis delovanja. Dobri programi tega ne potrebujejo.

Evo, dobis vrecko Haribo bombonov, ce v urednistvu pustis naslov in svoje podatke.

BigWhale je 23. dec 2020 ob 08:46 izjavil:

hruske je 23. dec 2020 ob 08:34 izjavil:

Kakšne pa delate opise commitov?

Evo, primer opisa commitov...

 commit f73554c7794f2956cee6f9e9141b74353c6951fb
 Date: Tue Dec 22 21:59:25 2020 +0100
 
 Popravil bug
 
 commit 0c47e5964b38fadc00e058a67d37cc29cffdbd3a
 Date: Tue Dec 22 21:59:07 2020 +0100
 
 Neki neki Asdf
 
 commit 8138670e746a39be745d422291b4c0adb06f88f6
 Date: Tue Dec 22 21:58:41 2020 +0100
 
 Dodal ene par stvari
 
 commit c6eb63f918f0a909bbb8fcef32fcb66e562eaab1
 Date: Tue Dec 22 21:20:36 2020 +0100
 
 Removed some stuff
 
 

ti opisi so katastrofa, to je joke ?

Unit testi pa so tudi za iskanje napak in ne samo za odkrivanje regresij, ker pod unit test spadajo tudi generativni testi, ti pa ponavadi kar dobro najdejo napake, dosti bolje kot ročni testi.

Razlike je v tem, da se je BigWhale hecal s tistimi commit messagi, kuall pa je dejansko resen s svojimi posti :>.

@WizzardOfOZ
Tudi zgornji komentarje niso ravno primeri. Podvajas informacijo, ki jo dobis ze z zgodovino commitov.

WizzardOfOZ je 27. dec 2020 ob 01:42 izjavil:

Ni neke alternative. Bi bil pa vesel, če bi se kje postavil tak forum, pa malo postavili kake dobre standarde, kako se programira in kako se potem testira. (tudi regresija, ...).

Imas slack Slovenian Tech Community, kjer je kar nekaj ljudi, ki obvladajo stvari. V resnici jih najdes tudi na tem forumu, samo znati moras lociti zrno od plevela.

HotBurek je 25. dec 2020 ob 22:55 izjavil:

BigWhale je n00b. Dober dđouk.


Evo moj sample "refaktoring-a". Prvotna funkcija:

def getdate():
 dtstart = datetime.datetime.now();
 day = dtstart.day;
 if len(str(day)) == 1:
 day = "0" + str(day);
 month = str(dtstart.month);
 if len(str(month)) == 1:
 month = "0" + str(month);
 _date = str(dtstart.year) + "-" + str(month) + "-" + str(day);
 return _date;

Kasneje sem odkril funkcijo zfill in zadeve popravil:

def getdate():
 dtstart = datetime.datetime.now();
 day = str(dtstart.day).zfill(2);
 month = str(dtstart.month).zfill(2);
 _date = str(dtstart.year) + "-" + str(month) + "-" + str(day);
 return _date;

In od prej imam notri dtstart, kar bom enkrat tudi popravil na dtnow. Mogoče kr zdele. Pa tudi _date v dstring.

Povsem tehnicno vprasanje. Cemu nisi spremenljivke raje poimenoval date_start, ali pa datetime_start? Res da je funkcija kratka, ampak bi imo še za malenkost pohitrila razumevanje le te.