Jump to content

SUBIECTE NOI
« 1 / 5 »
RSS
Scoatere antifurt airtag de pe ha...

Magnet in loc de clește pent...

Cumparat/Locuit in apartament si ...

Pot folosi sistemul PC pe post de...
 Sokol cu distorsiuni de cross-over

Filtru apa potabila cu osmoza inv...

Kanal D va difuza serialul “...

Upgrade xiaomi mi11
 securitate - acum se dau drept - ...

Farmacia Dr Max - Pareri / Sugest...

De unde cumparati suspensii / gar...

[UNDE] Reconditionare obiecte lemn
 Infiltratii casa noua

sugestie usa interior

ANAF si plata la selfpay

Imprimanta ciss rezista perioade ...
 

Cod lizibil comprimat + comentarii?

- - - - -
  • Please log in to reply
37 replies to this topic

#1
iulian_1976

iulian_1976

    Active Member

  • Grup: Members
  • Posts: 1,576
  • Înscris: 10.05.2008
Am 34. intrebari sa raspunda programatori cu experienta,eu nu ma includ.

1.Un cod comprimat este mai lizibil?
2.Un cod lizibil este neaparat un cod comprimat
3.Ce ajuta mai mult comentariile din cod sau un cod simplificat
4.In cazul ca ai 5 coditii  de ! si una true cum este corect.
   If(!){
}
  else if(!){
  }
... etc
  // la final
else{
true;
}
sau invers: primordial true si apoi negatiile.

Bila mea din instinct a reactionat cu prima varianta. Posted Image

Edited by MarianG, 26 October 2018 - 13:13.
tags


#2
romio79

romio79

    Active Member

  • Grup: Members
  • Posts: 1,655
  • Înscris: 30.03.2005
Raspunsurile mele :
1 nu
2 nu
3 da
4 da
Ai avut mai mult de 3 intrebari :)

#3
OriginalCopy

OriginalCopy

    I'm harmful, fear me please! :))

  • Grup: Senior Members
  • Posts: 27,268
  • Înscris: 10.08.2006
1. Depinde de definițiile pentru "comprimat" și "lizibil" și de abilitățile echipei
2. Idem
3. Depinde. Presupunând că simplificat!=comprimat (căci ar fi iar "idem"), cod simplificat aduce mai multă valoare ca unul comentat, dar lucrul acesta se judecă după caz. Depinde și de echipă, unele operații pe matrici executate de placa grafică într-un game engine e de exemplu simplificat, dar același lucru pentru un wordpressist e complicat. Prea mulți de "depinde", deci răspuns final: depinde
4. Depinde. În exemplul de cod ai sărit peste cea mai importantă informație: ce e în if, nume de variabile, obiecte, metode, etc, și cum se numește funcția în care apare acel fragment și ce parametri are și cât de importantă e


Răspuns final pentru toate: depinde.


Vino cu detalii sănătoase dacă vrei răspunsuri sănătoase.



#4
puiu_pe_diezel

puiu_pe_diezel

    Member

  • Grup: Members
  • Posts: 375
  • Înscris: 01.10.2018

 iulian_1976, on 26 octombrie 2018 - 06:44, said:

Am 3. intrebari sa raspunda programatori cu experienta,eu nu ma includ.

1.Un cod comprimat este mai lizibil?
nu

Quote

2.Un cod lizibil este neaparat un cod comprimat
nu

Quote

3.Ce ajuta mai mult comentariile din cod sau un cod simplificat
Ambele, mai ales comentariile la niste constante a caror  valoarea nu rezulta direct in business logic si vin direct de la business si pt acestia reprezinta
niste criterii de business pe care vechiul developer nu l-a specificat in cod

Quote

4.In cazul ca ai 5 coditii  de ! si una true cum este corect.
   If(!){
}
  else if(!){
  }
... etc
  // la final
else{
true;
}
sau invers: primordial true si apoi negatiile.
Este recomandat ca in conditii sa pui intotdeauana pe ramura if ce se intampla (adica subiectul) si pe
ramura else ce  se face in caz contrar.

Din acest considerent s-ar putea sa vezi astfel de constructii:
if(X) {
// do nothing
}else{
//log error
//exit application
}

in loc de
if(!X){
//log error
//exit application
}

Considerentul este ca daca dupa 6 ore de munca te uiti pe un alt cod cu multe if-uri , din cauza oboselii, tokenul "!" din fata lui X s-ar putea sa nu-l mai "vezi"
desi este in fata ochilor tai.
Este un best-practice pe care cei care nu au citit sau scris cod de productie nu-l pot intelege si nici ratiunea de a-l scrie.

PS: am intalnit cod scris de altii in genul asta:
if(!x && y || a || !b && c && !(t && !f) ){
  //cod aici
}

"Marfa" ? !

Edited by puiu_pe_diezel, 26 October 2018 - 08:07.


#5
Mosotti

Mosotti

    Geniu umil

  • Grup: Senior Members
  • Posts: 33,295
  • Înscris: 21.04.2004
1. Nu
2. Lol
3. Comentariile din cod sint o timpenie, cu exceptia cazurilor in care exista un process fabulous de review care sa asigure consistenta lor. Din experienta mea vasta pot spune ca toate comentariile pe care le-am vazut au fost puse acolo si lasate sa moara de batrinete, chiar daca codul s-a schimbat de 15000 de ori intre timp si nu mai aveau sens.
Cele mai fabuloase comentarii sint alea care la inceputul fisierului descriu schimbarile, de-a lungul timpui, cu data si autor. Pentru alea se da nota 10 cu felicitari.
4. Nu depinde de true si false, depinde de care e cel mai intilnit caz, normal flow si apoi exceptii

#6
parabellum

parabellum

    Senior Member

  • Grup: Senior Members
  • Posts: 2,453
  • Înscris: 06.01.2010

Quote

3. Comentariile din cod sint o timpenie
Cam generala afirmatia. Comentariile din cod pot fi esentiale pentru intelegerea lui.
Exemplu: https://github.com/a...woElectrons.cpp

Citat relevant:


// copy the results from the vertical recurrence and electron transfer into a work tensor

// this holds in the beginning in the first index the L1 -> L1 + L2 range, on the second it holds only s, that is, only the 0 index is filled
//(but space is reserved to be able to hold all L2 values)
// on the third index it has the L3 -> L3 + L4 range
// the later range is not touched, the formula is simply applied on all index values and nothing more, see the 'for' for the ind3 index
// the second is filled with computation results, as a consequence the first range will decrease to L1 only, the '+ L2' is moved into the second index
// the formula does this: (L1 + L2, s | L3 + L4, s) -> (L1, L2 | L3 + L4, s)



Fara comentariul asta, chiar un specialist poate sa aiba dificultati in intelegerea codului.

Aici:


// Horizontal Recurrence Relation 1



E delimitata o formula ce are un corespondent in articolul ce descrie modul de calcul. E mult mai usor sa o identifici cu aceasta delimitare decat fara.

Daca mai sapi prin codul ala, o sa gasesti:


// for the nuclear integrals I looked first at Mathematica Journal,
// Evaluation of Gaussian Molecular Integrals, III Nuclear-Electron Attraction Integrals
// http://www.mathematica-journal.com/2014/12/evaluation-of-gaussian-molecular-integrals-4/
// there is quite a bit of symbolic computation going on there, so I turned on to
// HSERILib: Gaussian integral evaluation
// link: http://theory.rutgers.edu/~giese/notes/HSERILib.pdf
// it discusses electron-electron integrals but also other kind of integrals very shortly
// I took the information from there in order to implement this, but the resemblance
// with the Mathematica Journal article exists, because both use the same recurrence relations



Al doilea link nu mai e disponibil, dar numele pdf-ului e suficient pentru a putea gasi articolul in caz de nevoie. Fara, doar postul pe blog ar mai putea ajuta, dar ideea e ca proiectul ramane chiar daca blog-ul dispare.

Si eu sunt de parere ca trebuie urmarita o cat mai buna expresivitate a codului, dar nu intotdeauna poti sa atingi idealul ala (fie din motive de complexitate, fie din motive de viteza), caz in care comentariile pot sa ajute. Proiectele mele de pe GitHub au, conform statisticilor, comentarii foarte putine: https://www.openhub.net/p/HartreeFock "Very few source code comments" - in acest caz 8% vs media de 22%. "This lack of comments puts HartreeFock among the lowest 10% of all C++ projects on Open Hub" Se pare ca nu e considerata o practica prea buna de catre respectivii: "A high number of comments might indicate that the code is well-documented and organized, and could be a sign of a helpful and disciplined development team."

Edited by MarianG, 26 October 2018 - 13:17.
fixed layout


#7
iulian_1976

iulian_1976

    Active Member

  • Grup: Members
  • Posts: 1,576
  • Înscris: 10.05.2008
parabellum@  Posted Image cel putin pentru mine o fraza mi-a usurat  in 99%  din cazuri intelegerea unui cod oricat de suplu sau lizibil a fost codul.

 puiu_pe_diezel, on 26 octombrie 2018 - 08:03, said:

Este recomandat ca in conditii sa pui intotdeauana pe ramura if ce se intampla (adica subiectul) si pe
ramura else ce  se face in caz contrar.
Din acest considerent s-ar putea sa vezi astfel de constructii:
if(X) {
// do nothing
}else{
//log error
//exit application
}

in loc de
if(!X){
//log error
//exit application
}

Considerentul este ca daca dupa 6 ore de munca te uiti pe un alt cod cu multe if-uri , din cauza oboselii, tokenul "!" din fata lui X s-ar putea sa nu-l mai "vezi"
desi este in fata ochilor tai.
Este un best-practice pe care cei care nu au citit sau scris cod de productie nu-l pot intelege si nici ratiunea de a-l scrie.
PS: am intalnit cod scris de altii in genul asta:
if(!x && y || a || !b && c && !(t && !f) ){
//cod aici
}

"Marfa" ? !

Sunt de acord cu tine,sincer ultima am comis-o la inceputuri de mult insa un prof de exceptie m-a corectat.

 Mosotti, on 26 octombrie 2018 - 08:03, said:

3. Comentariile din cod sint o timpenie, cu exceptia cazurilor in care exista un process fabulous de review care sa asigure consistenta lor. Din experienta mea vasta pot spune ca toate comentariile pe care le-am vazut au fost puse acolo si lasate sa moara de batrinete, chiar daca codul s-a schimbat de 15000 de ori intre timp si nu mai aveau sens.
Cele mai fabuloase comentarii sint alea care la inceputul fisierului descriu schimbarile, de-a lungul timpui, cu data si autor. Pentru alea se da nota 10 cu felicitari.
4. Nu depinde de true si false, depinde de care e cel mai intilnit caz, normal flow si apoi exceptii

Daca punctul 4 este clar,punctul 3 este in dezbatere.
Dupa parerea mea o fraza bine pusa,in locul care trebuie face cat o mie de vorbe si lasi unui beginer sa inteleaga ce ai vrut din cod,

Edited by iulian_1976, 26 October 2018 - 12:39.


#8
TS030

TS030

    Guru Member

  • Grup: Senior Members
  • Posts: 15,193
  • Înscris: 25.06.2012

 iulian_1976, on 26 octombrie 2018 - 06:44, said:

Am 3. intrebari sa raspunda programatori cu experienta,eu nu ma includ.

1.Un cod comprimat este mai lizibil?
2.Un cod lizibil este neaparat un cod comprimat
3.Ce ajuta mai mult comentariile din cod sau un cod simplificat
4.In cazul ca ai 5 coditii  de ! si una true cum este corect.
   If(!){
}
  else if(!){
  }
... etc
  // la final
else{
true;
}
sau invers: primordial true si apoi negatiile.

Bila mea din instinct a reactionat cu prima varianta. Posted Image
1. Ce inseamna cod comprimat?
Codul simplificat este in general mai vizibil. Simplificat insa nu inseamna variabile de-o litera si multe statement-uri inghesuite pe o linie.
Codul obfuscat este greu lizibil. Impresia mea e ca prin "comprimat" intelegi mai degraba obfuscat.
2. Nu. Din nou, depinde ce intelegi prin "cod comprimat".
Prioritatea maxima cand programezi trebuie sa fie scrierea unui cod lizibil, usor de inteles.
3. Codul trebuie sa exprime clar cum se rezolva problema data. Comentariile trebuie sa exprime intentia ("de ce"), atunci cand asta nu e clar din cod.
4. Depinde.
In primul rand, conditia trebuie pastrata rezonabil de simpla. Sunt cazuri in care e logic sa ai negare pe if, sunt cazuri in care nu.

Ca fapt divers, C++20 va introduce (foarte probabil) atribute prin care poti semnala care ramura este mai probabila de-a fi executata. Deci nici macar scuza "dar asa e mai rapid!" nu va sta in picioare... scrieti cod clar.

#9
MarianG

MarianG

    be that as it may

  • Grup: Moderators
  • Posts: 31,440
  • Înscris: 10.08.2005

Quote

Este recomandat ca in conditii sa pui intotdeauana pe ramura if ce se intampla (adica subiectul) si pe
ramura else ce  se face in caz contrar.
asta e definitia
 if condition is true do something 

eu stiam ca best-practice este sa testezi intr-un mediu izolat lucrurile care nu merg

Edited by MarianG, 26 October 2018 - 13:34.


#10
puiu_pe_diezel

puiu_pe_diezel

    Member

  • Grup: Members
  • Posts: 375
  • Înscris: 01.10.2018
Nu, definfitia este
if condition is true do something
otherwise to other things

Chestie care este valabil pentru orice circuit comparator. Orice circuit comparator are posibile doua valori: valoare in caz de true si valorea in caz de false.
iar definitia trebuie sa urmeze calea circuitului comparator.
In concluzie: definitia de la care pleci este falsa. Nu ai o ramura , ai intotdeauna doua ramuri ,doarece un circuit comparator iti formeaza doua ramuri logice ca output. Posted Image

 TS030, on 26 octombrie 2018 - 12:43, said:

Ca fapt divers, C++20 va introduce (foarte probabil) atribute prin care poti semnala care ramura este mai probabila de-a fi executata.
Nimeni nu se va baza pe astfel de predictii decat dupa 10 ani in care se va dovedi ca de fiecare data este "reliable"

Quote

eu stiam ca best-practice este sa testezi intr-un mediu izolat lucrurile care nu merg
Ce anume nu merge ?

Edited by puiu_pe_diezel, 26 October 2018 - 14:16.


#11
MarianG

MarianG

    be that as it may

  • Grup: Moderators
  • Posts: 31,440
  • Înscris: 10.08.2005

 puiu_pe_diezel, on 26 octombrie 2018 - 14:20, said:

In concluzie: definitia de la care pleci este falsa. Nu ai o ramura , ai intotdeauna doua ramuri ,doarece un circuit comparator iti formeaza doua ramuri logice ca output. Posted Image
dar nu esti obligat sa legi ambele ramuri la circuitul mare

 puiu_pe_diezel, on 26 octombrie 2018 - 14:20, said:

Ce anume nu merge ?
problema ta, tu esti cel care 'repara' codul

 puiu_pe_diezel, on 26 octombrie 2018 - 14:20, said:

In concluzie: definitia de la care pleci este falsa. Nu ai o ramura , ai intotdeauna doua ramuri ,doarece un circuit comparator iti formeaza doua ramuri logice ca output. Posted Image
definitia este incompleta, nu dar falsa

Edited by MarianG, 26 October 2018 - 14:44.


#12
puiu_pe_diezel

puiu_pe_diezel

    Member

  • Grup: Members
  • Posts: 375
  • Înscris: 01.10.2018
In mult cod de productie o sa gasesti principiile enuntate de mine , este best-practice.

#13
TS030

TS030

    Guru Member

  • Grup: Senior Members
  • Posts: 15,193
  • Înscris: 25.06.2012

 puiu_pe_diezel, on 26 octombrie 2018 - 14:20, said:

Nimeni nu se va baza pe astfel de predictii decat dupa 10 ani in care se va dovedi ca de fiecare data este "reliable"
Absurd. Compilatoarele se vor baza pe asemenea - nu predictii, ci - atribute, hint-uri oferite de programator. La fel cum se bazeaza pe inline.
gcc de altfel implementeaza ceva similar (__builtin_expect()).

P.S. Prea mult trolling pe aria asta, nu credeti?

Edited by TS030, 26 October 2018 - 15:01.


#14
iulian_1976

iulian_1976

    Active Member

  • Grup: Members
  • Posts: 1,576
  • Înscris: 10.05.2008
Ai dreptate la punctul 1 un Cod obfuscat.

Ca sa nu scriem in abstract, va prezint 3 stiluri diferite,3 limbaje diferite,3 viziuni de a scrie cod diferit :Posted Image
Spoiler

Nu comentam decat stilul nu intram in detalii,codul este modificat fata de original.
1.M-am lovit de un cod neexplicat exemplul 3 tipul spunea ca asta este standard in informatica ;
2.exemplul 2 este asa si asa
3.eu personal prefer exemplul 1.

Concluzie stilul " este standard?

Edited by MarianG, 26 October 2018 - 16:08.
extra long code


#15
Mosotti

Mosotti

    Geniu umil

  • Grup: Senior Members
  • Posts: 33,295
  • Înscris: 21.04.2004

 parabellum, on 26 octombrie 2018 - 11:27, said:

Cam generala afirmatia. Comentariile din cod pot fi esentiale pentru intelegerea lui.
Nu e generala afirmatia, pentru ca m-ai scos din context. Intotdeauna se citeaza TOATA propozitia, nu ce vrei tu Posted Image

Deci ca sa repetam, ce am spus de fapt

Quote

Comentariile din cod sint o timpenie, cu exceptia cazurilor in care exista un process fabulous de review care sa asigure consistenta lor.

Ceea ce nu se intimpla mai deloc. Un comentariu nu trebuie niciodata sa explice ce face codul, din mai multe motive:

- cel pe care l-am expis deja, si anume cei care vor schimba codul in anii ce vor urma nu se vor sinchisi sa si schimbe comentariul, mai ales in timpurile noastre agile, cu releasuri la termene dese si fixe si presati de sefi si client pe care-I doare la banana de comentarii

- comentariile trebuie sa fie extrem de bine scrise, daca descriu codul, orice scapare in comentariu care creaza o diferenta fata de cod, orice exprimare ciudata sau incompleta, il va face pe cel care se uita la ambele sa se scarpine in cap

- cu cit comentariile sint mai lungi, cu atit sint mai greu de intretinut, inclusive de catre autorul original

Comentariul asta "relevant"

Quote

// copy the results from the vertical recurrence and electron transfer into a work tensor
// this holds in the beginning in the first index the L1 -> L1 + L2 range, on the second it holds only s, that is, only the 0 index is filled
//(but space is reserved to be able to hold all L2 values)
// on the third index it has the L3 -> L3 + L4 range
// the later range is not touched, the formula is simply applied on all index values and nothing more, see the 'for' for the ind3 index
// the second is filled with computation results, as a consequence the first range will decrease to L1 only, the '+ L2' is moved into the second index
// the formula does this: (L1 + L2, s | L3 + L4, s) -> (L1, L2 | L3 + L4, s)

este fix ce nu ar trebui sa contina un comentariu, descrierea pas cu pas a codului.

Daca codul ar fi fost scris ca lumea si nu ar fi folosit nume de variabile precum ind3 & shit, n-ar mai fi fost nevoie de explicatii de genul "see the for". Mai mult, cind un cod este complex, se poate (este de fapt superindicat) sparge in bucatele in functii cu denumiri relevante. In plus, intr-o dezvoltare sanatoasa, orice commit ar trebui sa aibe trasabilitate, adica un bug / feature de care sa fie legat si in care sa se descrie natura implementarii, cu amanunte multe si marunte, formule etc. Cind ceva e neclar in cod te poti uita in istoric si vezi exact si cu mult mai multe amanunte DE CE s-a scris ce s-a scris acolo, adica care e intentia, pentru ca CE s-a scris ar trebui sa fie clar uitindu-te la cod. In anumite cazuri se poate chiar vedea ca o anumita cerinta a fost pur si simplu implementata intr-un mod superstupid si ca se putea face de fapt mult mai simplu Posted Image

Si nu in ultimul rind, beginnerii n-au ce cauta intr-un cod complicat pe care nu-l pot intelege decit daca scrie deasupra ce face codul in cuvinte. Asta e valabil in orice domeniu, nu doar programare. Deci nu exista nici o scuza ca lasi comentarii pentru saracii de "beginari"… Cind am inceput sa ma duc la lectii de pian am inceput cu melc melc codobelc, nu cu Rahmaninov Posted Image

Ah, am uitat sa mentionez, toti aia care scriu comentarii in alta limba decit engleza sint idioti. :first:

Edited by Mosotti, 26 October 2018 - 16:02.


#16
MarianG

MarianG

    be that as it may

  • Grup: Moderators
  • Posts: 31,440
  • Înscris: 10.08.2005
@iulian_1976 exista un motiv pentru care 'oameni mari' folosesc un numar maxim de caractere pe rand atunci cand scriu cod

sunt uimit ca vreti sa comprimati codul si sa labartati comentariile

private void afficheMessage(String message, String titre) {
JOptionPane.showMessageDialog(null, message,titre, JOptionPane.INFORMATION_MESSAGE);
// in prima mesaj,a doua titlul
}

Cine a generat acest cod este idiot, si nu pentru ca pus comentariile in alta limba decat engleza cum sugereaza Mosotti mai sus
are impresia ca se adreseaza unui tampit care nu stie ce este un titlu si un mesaj

 iulian_1976, on 26 octombrie 2018 - 15:26, said:

Concluzie stilul " este standard?
stilul standard il implementezi cu echipa

Edited by MarianG, 26 October 2018 - 16:17.


#17
Mosotti

Mosotti

    Geniu umil

  • Grup: Senior Members
  • Posts: 33,295
  • Înscris: 21.04.2004
Actually si aia care scriu nume de variabile, clase etc in alta limba sint idioti. Tre sa se inteleaga nu doar ca engleza este limba universala in general si in programare in special, dar mai ales ca toate limbajele de programare uzuale sint facute de americani, imensa majoritate a documentatiei si a informatiilor sint in limba engleza, nu exista nici un motiv sa scrii in limba ta prin cod. Problema cea mai nasoala este cind proiectul este mutat in alta parte si aia cunosc doar limba aia universala de care ziceam… Titre my ass

#18
iulian_1976

iulian_1976

    Active Member

  • Grup: Members
  • Posts: 1,576
  • Înscris: 10.05.2008
Legat de limba din experienta o spun:trebuie sa te adaptezi la tara unde lucrezi,acum daca vin peste tine tone de proiecte si te doare la basca este alta treaba.

Nu stiu cat de mare sau mic sunt insa tipul care scrie in stilul nr 1 este chemat ca expert in C si C++ doar cand celor mari le da cu virgula.

Faptul ca vrei sa scrii un numar maxim de caractere pe rand si fara comentarii este treaba ta insa nu cere 'celor mici' sa te ajute dupa 10 ani si sa te rezolve si rapid si..eventual si ieftin.

Edited by iulian_1976, 26 October 2018 - 16:41.


Anunturi

Chirurgia cranio-cerebrală minim invazivă Chirurgia cranio-cerebrală minim invazivă

Tehnicile minim invazive impun utilizarea unei tehnologii ultramoderne.

Endoscoapele operatorii de diverse tipuri, microscopul operator dedicat, neuronavigația, neuroelectrofiziologia, tehnicile avansate de anestezie, chirurgia cu pacientul treaz reprezintă armamentarium fără de care neurochirurgia prin "gaura cheii" nu ar fi posibilă. Folosind tehnicile de mai sus, tratăm un spectru larg de patologii cranio-cerebrale.

www.neurohope.ro

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

Forumul Softpedia foloseste "cookies" pentru a imbunatati experienta utilizatorilor Accept
Pentru detalii si optiuni legate de cookies si datele personale, consultati Politica de utilizare cookies si Politica de confidentialitate