☰

» »

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

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

««
3 / 9
»»

darkolord ::

BigWhale je izjavil:

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.
No ja, 120 znakov je pa spet neka cisto arbitrarna cifra.

techfreak :) je izjavil:

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.
Komentar napišeš, kjer je to potrebno za lažje razumevanje. Neko posebno izogibanje vodi v delanje kvazi "self-commenting code", kar se itak v veliki večini primerov izkaže kot fail.

Zgodovina sprememb…

  • spremenilo: darkolord ()

Smurf ::

codeMonkey je izjavil:

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 :)

Je bil podan zgolj kot primer, ki ga vsak pozna.

darkolord je izjavil:

Komentar napišeš, kjer je to potrebno za lažje razumevanje. Neko posebno izogibanje vodi v delanje kvazi "self-commenting code", kar se itak v veliki večini izkaže kot fail.

Ce lahko napises kodo tako, da ni potreben komentar je to definitivno bolj pravilna pot. Po drugi strani, moras kdaj v kodi naresti kaj takega kar je skregano z logiko (npr. ce ima api nek bug, pa moras delati workaround), v takem primeru pa je fino, da se dokumentira.

Zgodovina sprememb…

  • spremenil: Smurf ()

darkolord ::

To se ne izključuje - če ni potreben, pa ti vseeno močno olajša prihodnje branje in/ali razumevanje, potem ni nobenega razloga, da bi se mu posebej izogibal.

Trivial primer: če nekaj računaš in je malo bolj kompleksna operacija, lahko precej koristi, če na vrh napišeš formulo (ne glede na to da se da "na roke" tudi razbrati, kaj si računal)

Zgodovina sprememb…

  • spremenilo: darkolord ()

Smurf ::

Ne vem, osebno opazam sploh pri junior programerjih, da komentiranje pogosto uporabljajo za resevanje napacnih problemov.

Ne pomeni, pa da je slabo v vsakem primeru.

darkolord je izjavil:

Trivial primer: če nekaj računaš in je malo bolj kompleksna operacija, lahko precej koristi, če na vrh napišeš formulo (ne glede na to da se da "na roke" tudi razbrati, kaj si računal)

Spet odvisno od primera, marsikatero (oz. vecji del) formul se da lepo opisati tudi v kodi.

Po drugi strani je mogoce smiselno v komentar napisati literaturo iz kje je bila formula pridobljena.

Zgodovina sprememb…

  • spremenil: Smurf ()

Invictus ::

Če napišeš še toliko komentarjev v kodi, to ne more zamenjati design dokumenta s kako sliko, pa čeprav je tega samo par vrstic...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

darkolord ::

Smurf je izjavil:

Ne vem, osebno opazam sploh pri junior programerjih, da komentiranje pogosto uporabljajo za resevanje napacnih problemov.
Ja, ampak tu so komentarji potem simptom, ne vzrok :)

Smurf ::

darkolord je izjavil:

Smurf je izjavil:

Ne vem, osebno opazam sploh pri junior programerjih, da komentiranje pogosto uporabljajo za resevanje napacnih problemov.
Ja, ampak tu so komentarji potem simptom, ne vzrok :)

Drzi.

blay44 ::

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.

techfreak :) ::

To je nekaj s cimer se naj prevajalnik ukvarja. V 99.9%+ programih pa to ne vpliva bistveno na hitrost samega programa.

Skoraj v vseh primerih se splaca zrtvovati malo performansa za boljso izkusnjo razvijalcev.

Irbis ::

Smurf je izjavil:

Ce lahko napises kodo tako, da ni potreben komentar je to definitivno bolj pravilna pot. Po drugi strani, moras kdaj v kodi naresti kaj takega kar je skregano z logiko (npr. ce ima api nek bug, pa moras delati workaround), v takem primeru pa je fino, da se dokumentira.

Aha, nekoč sem moral v kodo dodati i = i;
Brez tega dodatka se je prevajalnik nekaj zmedel in v release verziji zaradi optimizacije ni prav delalo (v debug je pa seveda delalo brez težav). In tu je vsekakor nujno dodati komentar, ker ti bo drugače nekdo za tabo takoj vrgel ven tako nesmiselno vrstico. Na srečo se se prevajalniki precej popravili in se take težave ne dogajajo več toliko.

Meni so se sicer zdele nekatere ideje v Clean Code vseeno malo pretirane (omejitev funkcije na 10 vrstic). Jasna imena spremenljivk je veliko bolj uporabna zahteva, težko se je odvaditi kratkih imen, če si začel v času basica, ko so ti dolga imena spremenljivk odžirala prostor v 64 kB, kolikor je bil lahko dolg program vse skupaj.
Me pa kdaj zanese v precej dolge funkcije, kadar nimam notri kakšnih kosov, ki bi bili potencialno uporabni kje drugje (tudi par tisoč vrstic). Težava je, ker delam stvari, ki znajo biti časovno potratne in predvsem z ogromnim številom klicev, ker je notri kar nekaj rekurzije, potem pa človek ugotovi, da pač že sami klici funkcij porabijo kar precej časa. Delno si sicer človek lahko pomaga z inline funkcijami, samo tam si kar precej omejen, kaj lahko vsebujejo, da se res tako prevedejo.

darkolord ::

blay44 je 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.
Jaz se nisem nikoli s tem ukvarjal s tega vidika. Rabimo sicer high performance, ampak je hit count dovolj nizek, da takšne optimizacije prinesejo nekaj redov velikosti nižji gain kot na drugih nivojih.

Glede berljivosti je pa odvisno - če imam občutek, da se funkcija komplicira in da bi bilo precej bolj berljivo/logično, če je en kos posebej, gre lahko v ločeno funkcijo, seveda s predpostavko, da ga je enostavno izluščiti.

Da bi pa kar vse povrsti drobil, to pa ne. Je sicer osnoven flow funkcije res bolje viden, moraš pa potem skozi skakati gor in dol, če želiš videti celo funkcijo.

Zgodovina sprememb…

  • spremenilo: darkolord ()

kuall ::

Enim se ne da razmišljat in potem mislijo, da bo tipkanje milijon unit testov nadomestilo razumevanju tega, kar delajo. V resnici pa je najbolj važna kvaliteta programerja strmenje k razumevanju stvari in v resnici rabiš samo 1 unit test: glavna funkcija programa. Če tista faila greš potem kopat, kaj je narobe, ne pa da vnaprej zgubljaš čas s tipkanjem unit testa za čist vsak drek, kjer ni potrebno.

Drgač je pa kar šokantno, kako ste proti komentarjem. Tu delate veliko napako.

Zgodovina sprememb…

  • spremenilo: kuall ()

blay44 ::

Pa smo spet tu;
true == ~(true)
:)
Sej je res, ko iščeš kak bug po svoji kodi. Pa na kakšnem mlinčku s stackom povoziš delovni ram. Pa grejo spet ure..
Če pa se igraš profija....gas, gas..:D

kuall ::

Smurf je izjavil:

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

Zakaj je ze to bolje?


Nič nisem brisal samo v prihodnjih projektih sem delal drugače.
Unit testi v Visual Studiu tudi niso preveč zreli - šteka in zgubljaš čas, posebej ko test faila in ga moraš debuggirat je lažje to delat z navadnim console app.

shadeX ::

Zato pa uporabiš malo bolj "napreden" IDE, npr Jetbrains Rider dela super.

Smurf ::

Irbis je izjavil:


Aha, nekoč sem moral v kodo dodati i = i;
Brez tega dodatka se je prevajalnik nekaj zmedel in v release verziji zaradi optimizacije ni prav delalo (v debug je pa seveda delalo brez težav). In tu je vsekakor nujno dodati komentar, ker ti bo drugače nekdo za tabo takoj vrgel ven tako nesmiselno vrstico. Na srečo se se prevajalniki precej popravili in se take težave ne dogajajo več toliko.

Tako, to je dober primer kdaj uporabiti komentar ja.

Irbis je izjavil:


Meni so se sicer zdele nekatere ideje v Clean Code vseeno malo pretirane (omejitev funkcije na 10 vrstic).

Sej clean coda se ni treba drzati religiozno. Dobro je vedeti, kaj je priblizno ideal oz. zacnes razmislati sploh o teh zadevah, ampak na koncu seveda zraven uporabis nekaj kmecke pameti. Ampak v resnici je to ze, da razmisljas v tej smeri (npr. ali lahko morda to skrajsam in razbijem) veliko.

kuall je izjavil:

Enim se ne da razmišljat in potem mislijo, da bo tipkanje milijon unit testov nadomestilo razumevanju tega, kar delajo.

To, da eni ne znajo delati unit testov ni protiargument unit testov. Pomeni zgolj, da ne znajo uporabljati tega.

shadeX je izjavil:

Zato pa uporabiš malo bolj "napreden" IDE, npr Jetbrains Rider dela super.

Ne vem jaz pri c++ uporabljam google teste, pa zadeva deluje ok ne glede na IDE.

Zgodovina sprememb…

  • spremenil: Smurf ()

kuall ::

Komentira se zato, da ko bo nekdo za teboj bral kodo in prebral tisti komentar bo znal tisti blok kode na novo napisat. Ne pa da bo znal debuggirat kodo.
Če narediš takle komentar:
// Get x.
je to dober komentar, ker bo drug programer ali ti čez 1 leto točno vedel, kaj je cilj bloka.
Če pa komentiraš kako je nekaj narejeno je to zanič komentar. Komentira se cilj bloka, ne pa mehanizem.
Tole je zanič komentar:
// seštej x in y
Zakaj to delaš mi raje povej.

kuall ::

Smurf je izjavil:

To, da eni ne znajo delati unit testov ni protiargument unit testov. Pomeni zgolj, da ne znajo uporabljati tega.


Kaj pa je tako težko pri pisanju unit testov? Usedeš se in tipkaš kot opica cel dan.

napsy ::

Jaz gledam na unit teste kot nalozba v prihodnost ... All technical debt is due.

Mi je pa vsec argument, da ce ne znas pisat testov se ne dokazuje njihovo neprakticnost.
"If you die, you die. But when you live you live. There is no time to waste."

strawman ::

Največji izziv pri pisanju unit testov je pisanje kode na način, da niso sami sebi namen.

Smurf ::

kuall je izjavil:


// Get x.

Tole je slab komentar. Najverjetneje ga lahko nadomestis s funkcijo GetX().

kuall je izjavil:


Kaj pa je tako težko pri pisanju unit testov? Usedeš se in tipkaš kot opica cel dan.

Pisanje unit testov je priblizno tako zahtevno kot pisanje programov.

Za oboje lahko recemo, da se usedes in tipkas kot opica cel dan.

Samo vprasanje kaj potem na koncu dobis, sam si rekel, da si imel tezave s pridobitvijo smiselnih unit testov. Morda si se necesa narobe lotil?

Zgodovina sprememb…

  • spremenil: Smurf ()

shadeX ::

kuall je izjavil:


Komentira se cilj bloka, ne pa mehanizem.


Ampak tudi "Get X" komentar ne doda neke večje vrednosti, ker ne vemo kakšen je kontekst kot tudi samo ime funkcije. Že samo ime funkcije mora biti samoumevno kot tudi njen namen.

GetX - slabo
GetXRotation - boljše
GetXRotationInDegrees - dost boljše

Smurf ::

shadeX je izjavil:

kuall je izjavil:


Komentira se cilj bloka, ne pa mehanizem.


Ampak tudi "Get X" komentar ne doda neke večje vrednosti, ker ne vemo kakšen je kontekst kot tudi samo ime funkcije. Že samo ime funkcije mora biti samoumevno kot tudi njen namen.

GetX - slabo
GetXRotation - boljše
GetXRotationInDegrees - dost boljše

+1

kuall ::

X seveda nadomestiš z bolj smiselnim imenom.

Ste isti kot una blondinka, kateri daš navodila in ji daš primer "Janez Novak", ona pa se podpiše z "Janez Novak".:D

OrkAA ::

Pomoje si tu ti tisti, ki ni razumel kaj so zgornji posti poskusali sporocit. :)

darkolord ::

Smurf je izjavil:

kuall je izjavil:


// Get x.

Tole je slab komentar. Najverjetneje ga lahko nadomestis s funkcijo GetX().
Ampak potem prideš spet do tega vprašanja drobljenja. Velikokrat zadeva ni več elegantna že zaradi tega, če moraš kup parametrov prenašati v in iz funkcije.

S tem sicer narediš osnovno funkcijo bolj jedrnato, moraš pa za pregled celotne funkcije potem skozi skakati gor in dol po kodi.

Pa če si naredil novo funkcijo, jo moraš itak - ponavadi še bolj natančno - komentirat, tako da nisi nič komentarjev "prišparal". :)

shadeX ::

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?

Smurf ::

darkolord je izjavil:

Ampak potem prideš spet do tega vprašanja drobljenja. Velikokrat zadeva ni več elegantna že zaradi tega, če moraš kup parametrov prenašati v in iz funkcije.

S tem sicer narediš osnovno funkcijo bolj jedrnato, moraš pa za pregled celotne funkcije potem skozi skakati gor in dol po kodi.

Pa če si naredil novo funkcijo, jo moraš itak - ponavadi še bolj natančno - komentirat, tako da nisi nič komentarjev "prišparal". :)

Pomoje, ce imas prevec input parametrov je ze samo to dovolj dober razlog, da razbijes. Vec kot 2-3 input parametre za funkcijo tako in tako po "pravilih" ne bi smel imeti. Meni osebno (no pa tukaj nisem edin) je bolj berljivo ce imam nekaj v smislu Degrees = GetXRotationInDegrees(coordinateX, coordinateY). Take funkcije ne rabim dodatno komentirati, ker se mi zdi, da je ze sama po sebi dovolj opisna. Tudi razmislati mi je bistveno lazje, ce gledam manjse odseke naenkrat.

Zdej spet so tukaj izjeme. Ce bos delal za open source projekt, kjer je 500 developerjev bos verjetno pokomentiral tudi to f-jo. Ce delas znotraj ekipe recimo 10 ljudi pa najverjetneje ne.

Oz. drugace, to da premaknes 5 vrstic v svojo funkcijo samo po sebi ne bi smelo prinesti vecje potrebe po komentarjih, ampak kvecjemu zmanjsati.

Zgodovina sprememb…

  • spremenil: Smurf ()

Zimonem ::

darkolord je izjavil:

Smurf je izjavil:

kuall je izjavil:


// Get x.

Tole je slab komentar. Najverjetneje ga lahko nadomestis s funkcijo GetX().
Ampak potem prideš spet do tega vprašanja drobljenja. Velikokrat zadeva ni več elegantna že zaradi tega, če moraš kup parametrov prenašati v in iz funkcije.

S tem sicer narediš osnovno funkcijo bolj jedrnato, moraš pa za pregled celotne funkcije potem skozi skakati gor in dol po kodi.

Pa če si naredil novo funkcijo, jo moraš itak - ponavadi še bolj natančno - komentirat, tako da nisi nič komentarjev "prišparal". :)

To je bolj stara java šola z properties. Danes se prej ponuca kak iterator 
Map.toDegrees(whatever<T>)

BigWhale ::

Invictus je izjavil:

Če napišeš še toliko komentarjev v kodi, to ne more zamenjati design dokumenta s kako sliko, pa čeprav je tega samo par vrstic...


A je kdo mogoce kje rekel, da so komentarji v kodi zamenjava za design dokument? :>

blay44 je 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.


Senior profesionalci ponavadi vedo, da so to reci s katerimi se bo primarno ukvarjal compiler (ali pa se to ne, ce gre za kaksnega od visjenivojskih jezikov). Tisti, ki pa delamo kdaj pa kdaj tudi s cim drugim kot x86, pa znamo vsake tolk casa kak byte in celo bit prestet, sem ter tja.

Pac taksni robni primeri so smesni in vecinoma nepomembni.

Zgodovina sprememb…

  • spremenil: BigWhale ()

kuall ::

OrkAA je izjavil:

Pomoje si tu ti tisti, ki ni razumel kaj so zgornji posti poskusali sporocit. :)

Mi boš ti razložil?

Vidim, da vam moram narisat, ker imate trde buče. :)

Vi me hočete preričat, da moram nujno takole funkcijo razdelit v podfunkcije in da je ne smem komentirat, kot sem jo:

using System.Net;
using System.Net.Mail;

public void email_send()
{
    // Initialize
    MailMessage mail = new MailMessage();
    SmtpClient SmtpServer = new SmtpClient("smtp.gmail.com");

    // Message
    mail.From = new MailAddress("your mail@gmail.com");
    mail.To.Add("to_mail@gmail.com");
    mail.Subject = "Test Mail - 1";
    mail.Body = "mail with attachment";

    // Attachment
    System.Net.Mail.Attachment attachment;
    attachment = new System.Net.Mail.Attachment("c:/textfile.txt");
    mail.Attachments.Add(attachment);

    // SMTP
    SmtpServer.Port = 587;
    SmtpServer.Credentials = new System.Net.NetworkCredential("your mail@gmail.com", "your password");
    SmtpServer.EnableSsl = true;

    // Send
    SmtpServer.Send(mail);

}


Zgornje je bolj berljivo kot tole:

using System.Net;
using System.Net.Mail;

public void email_send()
{
    MailMessage mail = new MailMessage();
    SmtpClient SmtpServer = new SmtpClient("smtp.gmail.com");
    mail.From = new MailAddress("your mail@gmail.com");
    mail.To.Add("to_mail@gmail.com");
    mail.Subject = "Test Mail - 1";
    mail.Body = "mail with attachment";

    System.Net.Mail.Attachment attachment;
    attachment = new System.Net.Mail.Attachment("c:/textfile.txt");
    mail.Attachments.Add(attachment);

    SmtpServer.Port = 587;
    SmtpServer.Credentials = new System.Net.NetworkCredential("your mail@gmail.com", "your password");
    SmtpServer.EnableSsl = true;

    SmtpServer.Send(mail);

}


Funkcijo sem potegnil naključno iz stackoverflow, je samo primer, da se ne bo spet kdo zaganjal, da bi morala imeti parametre.

Zgodovina sprememb…

  • spremenilo: kuall ()

BigWhale ::

kuall je izjavil:

Enim se ne da razmišljat in potem mislijo, da bo tipkanje milijon unit testov nadomestilo razumevanju tega, kar delajo.

Mogoce bi bilo dobro, da bi nehal govoriti o unit testih, ker zgleda, da resnicno ne razumes kaj je namen unit testov..

kuall je izjavil:


V resnici pa je najbolj važna kvaliteta programerja strmenje k razumevanju stvari in v resnici rabiš samo 1 unit test: glavna funkcija programa.


Glavna funkcija programa? Kako pa stestiras glavno funkcijo programa in kaj sploh je glavna funkcija programa? Pa da vzamemo slovenski etalon programiranja, kaj je glavna funkcija Glavne Knjige(tm)? Kako to rec pokrijes z enim unit testom?

kuall je izjavil:

Če tista faila greš potem kopat, kaj je narobe, ne pa da vnaprej zgubljaš čas s tipkanjem unit testa za čist vsak drek, kjer ni potrebno.


Dejva lepo pocasi ponovit skupaj: unit testi - niso namenjeni - debugiranju - in iskanju napak v programih.

kuall je izjavil:

Drgač je pa kar šokantno, kako ste proti komentarjem. Tu delate veliko napako.

Noben ni proti komentarjem, kje si pa to prebral?

kuall ::

Imam odgovore na vsa tvoja vprašanja ampak debata s teboj je nesmislena, ker streljaš preveč čudne. Take čudake je najbolje ignorirat. :)

BigWhale ::

kuall je izjavil:

in da je ne smem komentirat, kot sem jo:


Pravkar si dal odlicen primer kako se ne komentira funkcij. Jaz za tole rec ne vem v katerem jeziku je pisana in kje se uporablja ampak mi je precej jasno kaj pocne brez tvojih komentarjev v kodi.

Tako pisejo komentarje junior programerji, ki jim je nekdo vbil v glavo "KOMENTARJI SO LAJF!" in zdaj komentirajo za vsako ceno tudi najbolj ocitne zadeve.

Vec srece prihodnjic.

Je pa komentiranje posameznih sklopov funkcij lahko povsem smiselno, samo nikakor pa ne v tem primeru.

kuall ::

Saj sem hotel dopisat, da je primer zelo enostaven, katerega jaz v resničnem življenju najbrž ne bi nič komentiral. Pač pošiljanje emailov je jasna stvar. Ampak sem bil preveč optimističen zgleda, da se ne boste zapiknili v to. To je spet un primer z blondinko, ki ne razume, da je Janez Novak samo primer.

Zgodovina sprememb…

  • spremenilo: kuall ()

SloKin ::

kuall je izjavil:

Saj sem hotel dopisat, da je primer zelo enostaven, katerega jaz v resničnem življenju najbrž ne bi nič komentiral. Pač pošiljanje emailov je jasna stvar. Ampak sem bil preveč optimističen zgleda, da se ne boste zapiknili v to. To je spet un primer z blondinko, ki ne razume, da je Janez Novak samo primer.

A nisi dve strani nazaj ti meni tezil za spremenljivko z imenom i? Heh smesen si.

BigWhale ::

kuall je izjavil:

Saj sem hotel dopisat, da je primer zelo enostaven, katerega jaz v resničnem življenju najbrž ne bi nič komentiral. Pač pošiljanje emailov je jasna stvar. Ampak sem bil preveč optimističen zgleda, da se ne boste zapiknili v to. To je spet un primer z blondinko, ki ne razume, da je Janez Novak samo primer.

Saj nihce ni rekel, da komentiranje razlicnih delov funkcij ni smiselno. Vendar je treba komentirati smiselno in predvsem tiste dele, ki so bolj nejasni. So pa tvoji argumenti, da je funkcija lahk dolga k spaget, ce je ustrezno komentirana, nesmiselni, ker sami komentarji za berljivost klobase ne naredijo prav dosti, ker se moras pri taksni funkciji vprasat kaj pocnes narobe, da si napisal taksno klobaso.

Daljse funkcije se lahko zgodijo na front-end, ko moras na ekran spravit doloceno stevilo elementov in ni druge moznosti, kot da te stvari pac spises. Pa se takrat se splaca razmislit ali se ne bi mogoce splacalo razmisliti o kaksnem orodju za pripravo uporabniskih vmesnikov.

SloKin ::

Aja pa kuall ko ze sprasujes. Inicializacija smtpserverja ne spada v to funkcijo. This will not scale. Zato imas logiko zunaj, ki ti odloca ali smtpserver po poslanem mailu destroya ali ne.

showsover ::

Kuall vas trolla, še vam res ni potegnilo?

SloKin ::

showsover je izjavil:

Kuall vas trolla, še vam res ni potegnilo?

Vemo vemo. Pa ga imamo vseeno radi 😁

Smurf ::

kuall je izjavil:

OrkAA je izjavil:

Pomoje si tu ti tisti, ki ni razumel kaj so zgornji posti poskusali sporocit. :)

Mi boš ti razložil?

Vidim, da vam moram narisat, ker imate trde buče. :)

Vi me hočete preričat, da moram nujno takole funkcijo razdelit v podfunkcije in da je ne smem komentirat, kot sem jo:


 using System.Net;
 using System.Net.Mail;
 
 public void email_send()
 {
 // Initialize
 MailMessage mail = new MailMessage();
 SmtpClient SmtpServer = new SmtpClient("smtp.gmail.com");
 
 // Message
 mail.From = new MailAddress("your mail@gmail.com");
 mail.To.Add("to_mail@gmail.com");
 mail.Subject = "Test Mail - 1";
 mail.Body = "mail with attachment";
 
 // Attachment
 System.Net.Mail.Attachment attachment;
 attachment = new System.Net.Mail.Attachment("c:/textfile.txt");
 mail.Attachments.Add(attachment);
 
 // SMTP
 SmtpServer.Port = 587;
 SmtpServer.Credentials = new System.Net.NetworkCredential("your mail@gmail.com", "your password");
 SmtpServer.EnableSsl = true;
 
 // Send
 SmtpServer.Send(mail);
 
 }


Tako je, to je dober primer nepravilne uporabe komentarjev.

techfreak :) ::

@kuall: Ce smo natancni, je to client, ne server. Torej je koda zavajujoca. Mogoce bi pomagalo ce komentar spremenis v:
//Initialize SMTP client

hruske ::

Kateri odprtokodni projekt ima slog komentiranja, ki vam je ok?

Kakšne pa delate opise commitov?
Kalkulator nove omrežnine 2024 - https://omreznina.karlas.si/Kalkulator

BigWhale ::

hruske je 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

showsover ::

Sam sicer ne komentiram prav veliko (če se ne generira tehnična dokumentacija iz izvorne kode), navadno poimenujem primerno (po standardih), v opis committ referenco na task, včasih dodatek v 1-3, največ 5 pomenskih besedah. Ne delam na odprtokodnih projektih, do sedaj vedno po naročilu in zahtevah naročnika, če jih nima, pa po svojih izkušnjah iz i/t industrije, ni pa to premosorazmerno z gubami ali izugbljenimi lasmi.

Smurf ::

BigWhale, zanemarjas emotikone. Nismo vec v 20. stoletju :>.

BigWhale ::

Smurf je izjavil:

BigWhale, zanemarjas emotikone. Nismo vec v 20. stoletju :>.


Moj 14" CRT VT-52 terminal, jih ne podpira. Sorry!

njyngs ::

BigWhale je izjavil:

hruske je 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

Kar koža se mi ježi. V vsakem podjetju do sedaj so patroni, ki tako komentirajo commite. Ne razumem zakaj je ljudem težko navest vsaj en stavek, ali pa povezan task/ticket.

techfreak :) ::

Zakaj bi vsak commit moral biti smiselno poimenovan? Saj preden zadevo spravis code review korak, lahko brez problema squashnes vse skupaj. Pa se potem lahko squash merge naredis, in bos imel clean history.

FTad ::

          je izjavil:

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.


Tocno tukaj sem istega mnenja. Če je metoda jasno poimenovana, potem me ne zanima, kaj je znotraj nje, ko grem na hitro skozi kodo. Prav tako lažje razumem delovanje celotne kode, če ni ta en dolg špaget, kajti že samo pogled nanjo mi da bruh refleks.
««
3 / 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		12229135 (23489) BigWhale
»

Unit testing - se poslužujete?

Oddelek: Programiranje		335178 (3328) krneki0001
»

Applov nov programski jezik Swift (strani: 1 2 )

Oddelek: Novice / Apple iPhone/iPad/iPod		7234344 (28905) 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