Cariera de programator

Cand esti in stare sa ataci proiecte doar limitat la un subset pe care il detine ala care da la pila, ai sanse mult mai mari sa fii sculer-somer. Un inginer poate spala si WCuri la o adica, invers e mai dificil.

Iar ‘lovitura’ e foarte greu de dat cu o aplicatie facuta ‘la pila’. Putem vorbi de foarte putini indivizi dintre miliardele de oameni care ar fi capabili sa dea cu pila. Cativa. Ala care crede ca poate fi printre ei, are sanse mari sa se insele.

Cand insa ai la concurenta nu miliarde de indivizi cu pila, ci mult mai putini, se schimba treaba. Eventual mai dai si cu pila, daca totusi nu-ti iese :slight_smile:

Hehe, sper ca nu-ţi imaginezi ca tu nu esti limitat la un subset :slight_smile:

Si apropo, m-am uitat peste codul tău de pe github şi nu e aşa elevat cum ar putea crede cineva care te citeşte, e plin de bad practices. De exemplu qualifier-ul “const” iti este complet străin. In constructori executi cod care poate da exceptii. Metodele prefixate cu get nu fac ceea ce te-ai astepta sa faca (de exemplu nu returneaza nimic, sunt pur si simplu void). Iar unele get-uri pe langa ce returneaza mai fac si alte chestii interne (normal getter-ii ar trebui sa fie const). Mai zic? :slight_smile: Eu consider astea ca fiind erori de incepator.

Vorba unui fost sef: “Fiecare are locul lui”, adica vroia sa zica ca indiferent de cat de bun sau de muncitor esti, se gaseste si pentru tine un proiect si un client care sa plateasca. Am fost destul de mirat cand am auzit asta dar mi-am dat seama ca asa se justifica faptul ca in IT poate sa lucreze cam oricine. Daca un client imi da 1000 de euro pentru un landing page, de ce sa pun pe un senior care vrea 500 de euro pe 3 zile de munca cand pot sa pun un junior care imi cere 300 de euro pe cateva saptamani?
Asta e realitatea si de asta apar “scoli de IT” peste tot care te transforma din zidar in programator in cateva luni, unele isi merita banii si altele nu, dar oricum te invata chestii mai practice decat in facultate. Eu nu am licenta luata si nici nu mai am de gand pentru ca e o pierdere de timp, dar niciun angajator nu mi-a zis ca ar trebui sa o iau pentru scutirea aia.
Iar legat de limba engleza, stiu programatori foarte buni care nu vorbesc fluent si nu i-a dat nimeni afara pentru asta.
Nu inteleg de ce zici ca e jale cu locurile de munca in Cluj, nu se cauta deloc acolo? In Iasi de exemplu e invers, nu scot facultatile destui studenti pentru firmele care vin si de aia si salariile cresc.
Daca faci freelancing, trebuie sa stii sa te vinzi, si gasesti pe internet o tona de resurse despre asta, n-are rost sa intru in detalii, dar nu te mai gandi la tehnologia pe care lucrezi pentru ca nu conteaza asta ci conteaza cati bani are clientul.

2 Likes

". De exemplu qualifier-ul “const” iti este complet străin"

Ia casca ochii, o sa vezi calificatorul const pe-acolo. Poti sa verifici cand am facut commit, sa nu zici ca am modificat acum. Am explicitat destul de clar ca e vorba de proiecte facute in viteza si ca urmare nu o sa ma obosesc cu detalii. Poti citi la ‘About this blog’ si o sa te lamuresti. Cat despre ‘get’ vorbesti ca un programator Java, nu unul C++ :slight_smile: Chiar nu ma intereseaza ce ‘te astepti’ tu sa faca metodele alea.

In rest, dupa ce am demonstrat ca minti cu tupeu, nu ma mai obosesc cu tine, e foarte clar.

Serios? Ia sa vedem cine minte cu tupeu:

Eu vad cel putin 4 locuri in care ar trebui sa apara const (asta mai ales daca Program::getStatusMessage() ar binevoi sa se rezume la a aduce niste date, nu de a face si modificari).

Ah, şi mă zgârie pe ochi acel glCreateProgram() din constructor. Nu doar ca e o idee proasta sa ai o functie acolo care sa dea o eroare, dar nici macar nu te-ai obosit s-o verifici, probabil aplicatia va crapa pur si simplu, fara nicio explicatie :slight_smile:

“iti este complet străin” Asta ai spus, mincinosule. Faptul ca lipsesc calificatori unde ar putea sa fie (si mai sunt, nothrow, override, etc) nu arata ca ‘imi sunt complet staini’. Faptul ca stai extrem de prost cu logica nu ma surprinde.

Cat despre glCreateProgram() eu zic sa mai meditezi. Nu de alta, dar deja emiti teorii contrare faptelor.

Ho, nu e ambala aşa. N-am afirmat că nu cunoşti keyword-ul const, ci că este bad practice ca nu-l folosesti in mod consecvent. Daca te uiti in SolarSystem lipseste aproape de peste tot, deci e ceva sistematic. Orice referinta si orice pointer pe care n-ai de gand sa-l modifici ar trebui sa fie const. Orice functie care nu modifica nimic ar trebui sa fie const. Nu eşti discplinat când scrii codul, asta-i adevărul :slight_smile:

În documentaţie scrie că poate da eroare, deci trebuie sa testezi daca totul e ok inainte de a merge mai departe. În plus, detest sa trebuiasca sa tratez erori in constructor, pentru ca nu o poti trata decat cu o exceptie si poate nu vreau sa folosesc exceptii.

SI zici ca tot readability te-a facut sa folosesti:

QDictIterator< Object > it(m_objects); while(it.current()) { if(uuid == it.current()->uuid()) return it.current(); ++it; }

in loc de un for? Mie mi s-ar fi parut mai readable cu for, dar de gustibus…

Habar n-am de ce am ales asa pe vremea aia, acum ar fi folosit o varianta cu range-for. Oricum, e o varianta de implementare, nu e bad-practice despre care discutam mai devreme.

Curios mod in care decizi tu ce e si ce nu e ‘bad practice’.


:slight_smile:

10 Likes

Criteriul meu e simplu: bad-practice e atunci cand modul in care scrii codul poate cauza confuzii sau permite utilizare neadecvata sau returneaza rezultate neasteptate. Sau functiile nu fac ceea ce promit, de exemplu doRed() sa coloreze ceva in albastru. Sau o functie prefixata cu get sa fie de tip… void. Chestii de tipul asta.

De exemplu, de ce pretind sa fie const peste tot unde trebuie sa fie. Sa zicem ca avem o metoda Ceva::faCeva(std::string &str). Ce naiba sa cred in cazul asta? Ca functia imi va modifica string-ul? Va trebui sa-mi iau masuri de precautie in cazul asta? Sa fac o copie a string-ului inainte sa apelez functia aia? Dar ce fac daca string-ul meu e constant? Nu pot sa-l pasez direct, o sa am eroare de compilare.

La fel cand, cand metoda in sine nu are qualifier-ul const trebuie sa ma intreb: oare functia aia va modifica vreo variabila pe undeva? Oare trebuie sa verific ca dupa apelul functiei respective totul este in aceeasi stare ca inainte de apel?

Dupa cum vezi, o gramada de intrebari din simplul motiv ca nu a fost pus qualifier-ul acolo unde trebuie.

EDIT: si mai exista si chestii care nu sunt bad-practice, dar exista o metoda alternativa mai buna. De exemplu m-am obisnuit sa scriu if(0 == ceva) in loc de if(ceva == 0). Chestia asta m-a salvat de nenumarate ori de erori bizare, pur si simplu aruncand o eroare de complilare daca scriam cumva if(0 = ceva).

Cred ca am putea muta o parte din raspunsuri intr-un nou post: Good practice in writing code, etc

:slight_smile:

2 Likes

@anon31094663 o să stea două săptămâni pe bară, până se calmează. La următoarea abatere ne va părăsi permanent :slight_smile:

Ce dracu băi, altă ocupație mai bună decât aruncatul cu căcat pe internet nu există?

8 Likes

Ca si moderator pe un subreddit, pot sa iti confirm ca nu exista.

5 Likes

Mda, mai degrabă ar trebui şters thread-ul cu totul. Stăteam şi mă gândeam cum naiba m-am lăsat atras în discuţia asta penibilă. Bănuiesc că nu rezist să nu le dau peste nas aroganţilor :slight_smile: Îmi cer scuze, nu se va repeta.

1 Like

nu neaparat

daca luam franturi din raspunsuri putem face o postare cu niste chestii interesante de C++

:slight_smile:
ps: nu am idee depre conceptele din C++(template si altte chestii mai avansate)

Nu se sterge nimic, trebuie sa invatam din ceea ce facem, sa ne asumam nu sa dam inapoi… si stergem chiar tot :smiley:

1 Like

Aha :slight_smile: Păi… în cazul ăsta particular, qualifier-ul const de regula indică ca variabila aia NU va fi modificata de catre functie. Daca lipseste const, cel mai probabil programatorul care a creat-o intentioneaza s-o modifice (de exemplu o foloseste ca output).

Exemplu:

void ceva(const std::string &str)
{
    // diverse operatii
    // dar nici una nu poate modifica str
    // pur si simplu va da eroare de compilare
    ....
}

std::string mystr = "blabla";
ceva(mystr);

// output-ul va fi "blabla"
std::cout << mystr << endl;

În cazul asta sunt (destul de) sigur ca functia ceva() va lasa mystr in pace, nu-l va modifica. E un soi de “promisiune”.

Insa, in cazul urmator situatia poate sta complet diferit.

void ceva(std::string &str)
{
    // deorece a fost pasat prin referintă, putem schimba
    // continului lui mystr
    str = "BUM";
}

std::string mystr = "blabla";
ceva(mystr);

// output-ul va fi "BUM"
std::cout << mystr << endl;

În cazul de mai sus, functia ceva() va putea manipula string-ul nostru şi e destul de probabil că o va face. Când un programator defineste o functie in felul asta de fapt ne informeaza ca intenţionează sa modifice acel argument. Nici macar nu e nevoie sa citesc documentatia, stiu la ce trebuie sa ma astept.

Well, cand programatorul NU tine cont de conventiile astea se poate considera ca nu prea e “team player”, nici macar cu el insusi. Si nu ţine scuza cu “ma grabeam si n-aveam timp sa scriu const peste tot”. Asta devine un automatism si nici macar nu te mai gandesti ca ai face economie de timp daca nu tastezi cele 5 caractere. E ca si cum ai alege sa scrii int in loc de double doar pentru ca primul e mai scurt :slight_smile:

EDIT: uite ce urat face compilatorul daca incerci sa modifici o variabila constanta.

test1.cpp: In function ‘void ceva(const string&)’:
test1.cpp:8:11: error: passing ‘const string {aka const std::__cxx11::basic_string<char>}’ as ‘this’ argument discards qualifiers [-fpermissive]
     str = "BUM";
           ^~~~~
In file included from /usr/include/c++/7/string:52:0,
                 from test1.cpp:1:
/usr/include/c++/7/bits/basic_string.h:692:7: note:   in call to ‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(const _CharT*) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]’
       operator=(const _CharT* __s)
1 Like