Wątek przeniesiony 2020-11-19 21:12 z C/C++ przez kq.

Krótki artykuł z poradami napisany po 22 latach programowania w C++

0

Sztuka kodowania w C++ jest dostępna w repo:
https://gitlab.com/energokoder/sztuka-kodowania

13

Jak chcesz programować dobre, prawdziwe i profesjonalne aplikacje, to wybór jest tylko jeden: C++.

o cię kiciuś :)

23

Przeczytałem, mam mocno ambiwalentne odczucia. Z częścią (większością?) rad można się zgodzić, ale część brzmi jak bezmyślna aplikacja wzorców wszędzie gdzie tylko się da lub próba narzucenia bezsensownych rozwiązań, bo np. twórca nie wiedział że da się inaczej.

Po lekturze rzuciło mi się w oczy przede wszystkim:

  • plik .odt zapisany w repozytorium zamiast jakiegoś sensowniejszego formatu (pdf? markdown? wymaganie pakietu biurowego to lekka przesada imo)
  • nigdy nie używaj struct
  • nigdy nie używaj private w klasach bibliotecznych
  • wszystkie destruktory powinny być wirtualne
  • notacja węgierska (wtf)
  • zmienne globalne to zło, ale singletony już ok
  • linkuj statycznie bo inaczej nie da się debugować (przyp. kq: da się)
  • nie ucz się innych języków programowania
  • uzależnienie od konkretnych rozwiązań (cmake, snap, Qt)
  • dokument jest połączeniem coding style guide z ogólnymi zasadami programistycznymi. O ile te ogólne zasady są z reguły sensowne, to z perspektywy C++ słabo to wygląda.
  • twardy limit na wielkość funkcji. Sorry, czasem się nie da i podział funkcji spowoduje wyłącznie zaciemnienie jej działania.
  • Kod C++ należy umieszczać w plikach *.h++ i *.c++, a nie w żadnych innych!Wynika to z tego, że przykładowo: pliki *.h i *.cpp to nie jest symbolika C++! wtf
0

I nie daj się nabrać, tym co gadają teksty w stylu: W Jawie wyświetlenie filmu zajmuje 1 linijkę kodu. Bo tylko frajerzy tak mówią: bo myślący programista wie, że to tylko kwestia bibliotek, a nie języka.

Pffff!

8
revcorey napisał(a):

Jak chcesz programować dobre, prawdziwe i profesjonalne aplikacje, to wybór jest tylko jeden: C++.

o cię kiciuś :)

Tu jest trochę więcej perełek:

  1. Jak chcesz być dobry w C++ to programuj w jego stylu we wszystkich jeżykach w jakich jesteś zmuszony programować. Wtedy utrzymasz „zdrowe nawyki” programowania w C++.

  2. Rzeczą trochę nienormalną jest wiele języków narodowych. Ma to jedynie uzasadnienie symboliczne (rozdział symboliczny poszczególnych narodów, tak by miały szansę na indywidualny sukces).

I chyba moja ulubiona:
3. Jak programujesz indywidualnie lub w małym zespole w C++, to jedyną szansą na powodzenie projektu jest biblioteka Qt.

2

• 1, 2 i 3 linijkowe funkcje są nie do przyjęcia.
Jest to chory zwyczaj zapoczątkowany przez j. Java i praktykowany przez j. skryptowe. Jednak poza tym, że jest to trudne do zrozumienia, to jeszcze jest niewydajne, bo każde wywołanie f. jest b. kosztowne.

kurcze, wywalili z C++ inline ?

C++ jest dużo mniej podatny na zmiany ze względu na hierarchię klas.

kurcze myślałam ze jest odwrotnie

i dlaczego ten dokument jest po polsku? przecież jest nim napisane żeby pisać po angielsku

1

a.png

:/

5

• 1, 2 i 3 linijkowe funkcje są nie do przyjęcia.
Jest to chory zwyczaj zapoczątkowany przez j. Java i praktykowany przez j. skryptowe. Jednak poza tym, że jest to trudne do zrozumienia, to jeszcze jest niewydajne, bo każde wywołanie f. jest b. kosztowne.

Zaczynam rozumieć, dlaczego akurat w kodzie C++ znajdowałem kwiatki pokroju klas na 45k linii, metod na 1,5k linii, turbo-enumów na paręset i towarzyszących im, nie mniejszych switchy

1
superdurszlak napisał(a):

• 1, 2 i 3 linijkowe funkcje są nie do przyjęcia.
Jest to chory zwyczaj zapoczątkowany przez j. Java i praktykowany przez j. skryptowe. Jednak poza tym, że jest to trudne do zrozumienia, to jeszcze jest niewydajne, bo każde wywołanie f. jest b. kosztowne.

Zaczynam rozumieć, dlaczego akurat w kodzie C++ znajdowałem kwiatki pokroju klas na 45k linii, metod na 1,5k linii, turbo-enumów na paręset i towarzyszących im, nie mniejszych switchy

Dobry kompilator powinien takie krótkie funkcje zoptymalizować. Ale nie wiem czy obecnie są dla C++ są jakieś dobre kompilatory.
Jak coś to z tego co pamiętam można kompilatorowi pomóc gdzie się da, przez użycie inline.

Generalnie nie skreślałbym niczego z góry (no może poza javą...). Wszędzie są tradeoffy. W C/C++ na pewno warto z tym uważać. W Ruby z przyjemnością piszę takie krótkie metody i wydajność mam gdzieś.

2

Do autora, jak chcesz zobaczyć jak naprawde takie dokumenty powinny wyglądać cyz co tam powinno być zacznij od:
https://github.com/lefticus
szczególnie
https://github.com/lefticus/cppbestpractices

5
superdurszlak napisał(a):

• 1, 2 i 3 linijkowe funkcje są nie do przyjęcia.
Jest to chory zwyczaj zapoczątkowany przez j. Java i praktykowany przez j. skryptowe. Jednak poza tym, że jest to trudne do zrozumienia, to jeszcze jest niewydajne, bo każde wywołanie f. jest b. kosztowne.

Zaczynam rozumieć, dlaczego akurat w kodzie C++ znajdowałem kwiatki pokroju klas na 45k linii, metod na 1,5k linii, turbo-enumów na paręset i towarzyszących im, nie mniejszych switchy

Popieram superdurszlak.
Piszę głownie w C++ i moje funkcje najczęściej mają 3 linijki i zdarzają się też jednotykowce. Jak mają +5 linii to gryzie mnie sumienie. Jednak moją preferowaną miarą długości funkcji jest liczba instrukcji sterujących (maks 2, preferowane 1).
To jest efekt uboczny przeczytania "Clean Code" Robert C. Martin i paru innych źródeł.

3
revcorey napisał(a):

Jak chcesz programować dobre, prawdziwe i profesjonalne aplikacje, to wybór jest tylko jeden: C++.

o cię kiciuś :)

Ktoś chyba przespał pojawienie się Rusta XD

3

Czyzby jakis senior przez zasiedzenie? :P

2
stivens napisał(a):

Czyzby jakis senior przez zasiedzenie? :P

W naszej branży dobre jest to, że każdy może sobie wybrać jedną z wielu dostępnych technologii, być przekonanym że wybrał najlepiej i nikt mu nie udowodni że wybrał kupę. Bo każdy język ma tam jakieś zalety, do których możesz być mocniej przywiązany.
Ja mogę pisać, że bardzo lubię Ruby czy Zig, czy nawet ES6, ale pewnie żadnego javowca, .NETowca czy tym bardziej haskellowca nie będę w stanie przekonać dopóki im płacą za pisanie w tych rzeczach i szczerze mówiąc raczej nie chcę przekonywać.

4
revcorey napisał(a):

Do autora, jak chcesz zobaczyć jak naprawde takie dokumenty powinny wyglądać cyz co tam powinno być zacznij od:
https://github.com/lefticus
szczególnie
https://github.com/lefticus/cppbestpractices

Wcale nie musi tak wyglądać - gdzie to jest napisane jak ma wyglądać? Istnieje już jakiś ponadczasowy oderwany od narzędzi standard? Nie słyszałem - w pojedynczych obszarach tak ( np. UML) ale z niego nie wynika cała masa innych rzeczy. Format MarkDown istnieje dopiero od 2004 roku a uwierz, że na świecie działają dużo starsze systemy. W sumie poza tym czym to się różni od Word?
Ponad 15 lat temu też się tak wymądrzałem przed kierownikami zmuszając ich do tworzenia UML w jakimś narzędziu, które już z 10 lat nie istnieje. Oni jednak twardo pisali w Wordzie i dzięki temu projekt działa do dzisiaj od lat 90'tych - przeniesiony z DB4 do Delphi potem z Delphi do SAP - na bazie właśnie tych Wordów. Gdyby ich nie spisali to ktoś musiałby wszystko pisać od nowa 2 razy a to była GIGANTYCZNA praca projektowa - pełna wzorów, zależności także takich niewyjaśnionych - czyli tak miało być bo tak to działało od 100 lat.

Istotna jest treść oraz idea, która w tej treści jest niesiona a nie forma.

Dokumenty z wytycznymi jakie zapodał OP oraz podobne spotykałem niemal wszędzie gdzie mamy systemy powstające od kilkunastu albo nawet kilkudziesięciu lat. Kiedyś reagowałem na nie alergicznie ale dziś raczej cieszę się, że ktoś pomyślał i takowe stworzył dając szanse wgłębić się w tematykę w oderwaniu od technologii. Wbrew pozorom często to lepsze rozwiązanie niż dokumentowanie za pomocą "współczesnych" narzędzi, które zwyczajnie "przemijają" a nasz system ciągle trwa i jest rozbudowywany.
Też mam okazję pisać system od 2001 roku i jest w nim ciągłość. Mój znajomy pisze system od 1990 i też mają ciągłość bibliotek ( tak wciąż korzystają z kodu napisanego w latach 90'tych ). Systemy były przemyślane - nikt nie nazywał tego DDD a jedynie dobrze zaprojektowaną aplikacją, która przetrwała próbę czasu.

Ile ja już przeżyłem złotych poradników w postaci wypunktowanych list "jak programować poprawnie" ... chyba sam nie zliczę.

było 9 programming rules, 12 programming rules, było 5 programming rules, były złote zasady programisty i wiele innych.
Wszystko jednak sprowadzało się do:

  • modułowości,
  • konsekwencji formatowania i nazewnictwa,
  • wersjonowania kodu,
  • dokumentowania,
  • pisania krótkich funkcji ( są wyjątkowe przypadki, że to wcale nie jest dobre ),
  • no i czasem czasem ktoś tam jeszcze próbował przemycić jakąś własną filozofię ...

Niemal wszystko co najistotniejsze / wspólny mianownik tych poradników znalazł się w dokumencie, który wrzucił OP.

Ja wiem, że dzisiaj programiści uwielbiają przepisywać kod z jednego języka do drugiego, tylko po to by z projektem nadal stać w miejscu ale na nowej technologii.
Czytając jednak dokument OP'a, wygląda na to, że programuje raczej "niskopoziomowo" / tworzy "samodzielne aplikacje", które rozbudowywane są od wielu lat. W tym obszarze zgadzam się jego dokumentem niemal w 90%. Należy jednak dopisać, że jest to propozycja szczególna a nie ogólna.

Z dokumentem nie zgadzam się w punktach:

4.25 Całą dokumentację generuj skryptami. Brak ogólnej dokumentacji to błąd nawet jeśli jest to projekt na 8051.
10. Jak wyżej ... Dokumentacja w samym kodzie owszem ale brak dokumentacji ogólnej to wg mnie bardzo poważny błąd ( oczywiście zależy też od wielkości projektu ).

... oraz w sposobie nazewnictwa ale to już wg mnie kwestia gustu, wyboru standardu i bycia konsekwentnym w jego stosowaniu.

5

W plikach nagłówkowych przestrzeń nazw należy podawać przed każdym używanym elementem biblioteki. Natomiast w plikach z definicjami należy używać:
using namespace std;

Raczej nie należy używać. Problemy z możliwą niejednoznacznością nazw pozostaną, choć nie będą się tak szybko rozprzestrzeniać, jak w przypadku nagłówków.

1
katakrowa napisał(a):

Istotna jest treść oraz idea, która w tej treści jest niesiona a nie forma.

I tak i nie. Fajnie, żeby forma byłą "odczytywalna" za 15 lat i wskazuje na to, że na plain text jest do tego najlepszym wyborem. Wszystkie pliki binarne mają ten minus, że: źle się je porównuje (nie da się tego zrobić), musisz mieć to jedno magiczne narzędzie, żeby je odtworzyć. Dlatego całkiem niegłupie jest używanie md czy innego XMLa, bo to będzie można otworzyć w byle czym i odczytać treść.

2

musisz mieć to jedno magiczne narzędzie, żeby je odtworzyć.

Nie prawda. Pliki typu RTF, ODT czy DOC są otwierane przez tyle różnych programów biurowych, że nie ma szans, żeby kiedyś stały się one niekompatybilne i nieodczytywalne. Przynajmniej w ciągu najbliższych kilkudziesięciu lat.

2
cerrato napisał(a):

Nie prawda. Pliki typu RTF, ODT czy DOC są otwierane przez tyle różnych programów biurowych, że nie ma szans, żeby kiedyś stały się one niekompatybilne i nieodczytywalne. Przynajmniej w ciągu najbliższych kilkudziesięciu lat.

Nie jestem do tego przekonany, dalej uważam, że plain text jest lepszy.

2

Kwestia rozsądnego kompromisu. Tekst otworzysz wszędzie, ale tam nie masz formatowania, nie wstawisz grafik, tabelek itp.

Więc kompromisem między jakimś specjalistycznym narzędziem a plikiem TXT jest właśnie ten wyśmiany powyżej DOC.

4

Albo HTML albo PDF, które są znacznie lepsze do tego, a ten pierwszy nawet jak cię mogę działa z vcsami ;​)

1
cerrato napisał(a):

Kwestia rozsądnego kompromisu. Tekst otworzysz wszędzie, ale tam nie masz formatowania, nie wstawisz grafik, tabelek itp.

No i dlatego powstało coś takiego jak MD (kiedyś XML) które jest kompromisem pomiędzy trzymaniem treści w plain text i możliwości dorobienia formatowania jak ci się podoba bez konieczności ingerowania w treść.

1

Tylko LaTeX.

2
part napisał(a):

Tylko LaTeX.

hmmm ... re-parsowanie pliku LaTeX w celu innym niż "poligrafia", np w celu selektywnego wyciągania informacji ... jednak Markdowny / XML / whatever skupione na semantyce a nie wyglądzie są lepsze (co nie znaczy że w mojej opinii LaTeX nie ma prawa żyć, fajny software)

LaTeX bardzo wyraźnie wyznacza kierunek od składającego do drukowanej (w różnych formach, ale zawsze dla ludzkich oczu) informacji

4

Czy w dziale C++ jest odśmiecacz?

4

Niezły zbiór kwiatków, artykuł w kolejnych akapitach przeczy radom napisanym w wcześniejszych działach.
Pisz modułowo! ale Wszystko linku statycznie. Funkcje na trzy linie są złe bo wywołanie funkcji kosztuje, ale za to tylko Qt i każdy desktruktor musi być wirtualny (czego doradzanie już dawno przestało mnie śmieszyć).

Trzeba jednak autorowi oddać, że był lepszy od Herba Suttera i Bjarne Stroustrupa w efektywnej kompresji tekstu, nowoczesny C++ tylko w 25 stronach a wymienieni Panowie wraz ze społecznością potrzebowali kilkanaście razy tyle by stworzyć CppCoreGuidelines.

ps. Jestem pewien, że o "nieśmiesznych wirtualnych desktruktorach" pisałem już kilka lat temu, ale nie potrafię znaleźć tego posta.

9

Ooo....
"4.21 Kodowanie plików źródłowych musi być w UTF-8. A końce linii w formacie UNIX.
Wynika to z tego, że dla zwykłego programisty prawdziwą platformą programistyczną jest Linux
."
W życiu nie napisałem programu na linuxie, zatem nie jestem programistą :(

Ale: "*Windows nie wspiera wszystkich rozwiązań serwerowych (np. Docker-a). *"
Że co?!
No to krótko:
https://docs.microsoft.com/pl-pl/dotnet/architecture/microservices/container-docker-introduction/docker-defined

"Wydaje się, że jedynym argumentem za Windows-em są gry i stare aplikacje biznesowe pisane w nie przenośny sposób (przy okazji: M$ bardzo dba by jego rozwiązania były nieprzenośne)."
Autor mimo tego, że napisał to raptem miesiąc temu, to raczej nie wychodził ze swojej szafy przez dekadę.
Wiesz autorze kto jest największym donatorem Dockera?
Albo kto ma najwięcej repo na Githubie z dużych komercyjnych korporacji?
Właśnie. Microsoft.
To taka sama prawda jak z Dockerem pod Windows - znaczy g**no o prawda.

Ale super-duper kwiatkiem jak dla mnie jest to:
"11 Czy uczyć się innych języków?
11.1 Generalnie odpowiedź brzmi: nie.
"
Ja mimo że programuję od mniej więcej 24 lat i przez większość czasu głównie w jednym języku, to uważam tę "radę" za totalny idiotyzm.
Równie dobrze można powiedzieć, że zwiedzanie świata nie ma sensu, poznawanie ludzi nie ma sensu i poznawanie nowych języków (rozwiązań, bibliotek, itd.) też sensu nie ma.
Nie dość że to jest zwyczajnie głupie, to na dodatek po prostu szkodliwe.
Nie ma nic gorszego jak utknięcie w jednym otoczeniu.
Co nie znaczy, ze masz człowieku znać wszystko - nie. Ale masz mieć świadomość istnienia innych rozwiązań, które zwyczajnie mogą ci pomóc.

Więcej nie czytam, szkoda prądu.
Wolę poznawać nowe języki i technologię, znaczy czas wrócić do nauki Svelte :)

2
Wydaje się, że jedynym argumentem za Windows-em są gry i stare aplikacje biznesowe pisane w nie przenośny sposób (przy okazji: M$ bardzo dba by jego rozwiązania były nieprzenośne).

Co za belkot xd

5

przyznam ze podziwiam troche ludzi ktorzy robia takie podsumowania, chec do dzielenia sie wiedza jest zawsze w cenie i z pewnoscia mozna sie z tego tekstu czegos nauczyc.
niestety dokument jest naszpikowany watpliwymi merytorycznie poradami i propagandowym belkotem, przez co moze byc szkodliwy dla kogos kto nie podejdzie do tego z dystansem.

1

też bym se poczytał, ale pobieranie randomowych doców to no-go :(

1 użytkowników online, w tym zalogowanych: 0, gości: 1