Czytając ten wątek przypomina mi się historia pewnego Stefka (imię zmienione) w pewnej poprzedniej firmie gdzie kiedyś pracowałem. Stefek był zagorzałym fanem clean code. Miał też na świeżo bazy danych gdzie nauczyli go normalizacji do 5 NF. Otóż ów Stefek dołączył do naszego projektu jako nty programista i już w pierwszym tygodniu nie mógł powstrzymać się od komentarzy jaki to ten kod popieprzony jest i że tak się nie pisze i w ogóle, że nasza baza nie trzyma nawet 3 NF a przecież powinno być 5 NF i w ogóle co to za jełop projektował. No i któregoś razu stefek siedział przy kompie i rzucił bluzga w swoim stylu
- Kto to k*a zaprojektował ten komponent, jeeezu jakie to jest pop**ne"!
- Ja zaprojektowałem - odezwał się prezes stojący w drzwiach do pokoju. - Stefan, zapraszam do mojego gabinetu.
Dobra pasta, szacun :)
Wracając do tematu - nie patrzyłem na ten kod
To widać po całym Twoim poście :)
ale czy w tym kodzie są nieprawidłowo użyte sockety albo inna fundamentalna rzecz którą ten kod miał ilustrować?
Tak i dotyczy to praktycznie całego kodu.
Należy wziąć pod uwagę, że wykładowcy zwykle nie są i nie muszą być programistami pracującymi z kodem na co dzień
Podstawy wypadałoby znać, zwłaszcza gdy uczy się programowania innych.
i nie muszą znać absolutnie wszystkich trendów z ostatniego miesiąca.
Kolega zdaje sobie sprawę z tego, że #include to nie jest ostatni krzyk mody, tylko jest prawie tak stare jak Unix, około 1973 :)
<string.h> - chyba 1985, trend z ostatniego miesiąca, jak nic!
<unistd.h> - okolice 1991, nie za krótki ten ostatni miesiąc, taki 31-letni :)
Oni są od tłumaczenia rzeczy ponadczasowych.
Wołanie funkcji bez deklaracji ponadczasowe? Chyba jednak nie.
gethostbyname(3) ponadczasowa? XD
A Ty @pifko przyczepiles się do tego że gostek używa exit a nie err, co w sumie nie jest żadnym błędem.
Zachęcam Cię do przeczytania całego posta (ze zrozumieniem).
Co do brakujących include, to jest to akurat jedna z głupich rzeczy w C - mianowicie headery mogą robić include innych headerow i bardzo łatwo stworzyć kod w którym brakuje include, a który będzie się kompilował i działał przez przypadek.
Jak się nie wie, że jest coś takiego jak choćby -Wall i -Werror to rzeczywiście łatwo jest stworzyć kod działający przez przypadek.
Tyle, że od wykładowcy nie oczekuje się działania przez przypadek. Od wykładowcy oczekiwałbym jednak działania na podstawie posiadanej solidnej wiedzy oraz umiejętności przekazania tej wiedzy studentom.
A tym bardziej CEO poważnej firmy nie powinien działać przez przypadek, tylko opierać się na wiedzy i doświadczeniu, choćby z uwagi na ogromną władzę nad firmą i wynikającą odpowiedzialność.
Możliwe, że na jego wersji kompilatora i systemu kiedyś działało, ale potem nie zaktualizował.
Coś tam pewnie działało.
Sztuka w tym, żeby wiedzieć co może pójść nie tak, jak napisać dobrze i jak dobrze przetestować.
Możliwe też że przykłady są obcięte i nie są w ogóle kompletnym kodem a od studenta wymaga się że include doda sobie sam.
Wymyślasz okoliczności pod tezę :)
Ja personalnie na takie rzeczy bardzo zwracam uwagę, ale realia pracy na uczelni są takie jakie są i nie dziwię się że dla wielu wykładowców takie rzeczy są kwestią o znikomej wadze, na poziomie literówki.
A później absolwenci tak samo piszą produkcyjnie lub przynajmniej przychodzą na rozmowy i chcą na seniora bo ukończyli informatykę na prestiżowej uczelni technicznej, najlepszej w Polsce :)
Btw: dokumentacja BSD stwierdza:
The err() and warn() families of functions are BSD extensions. As such
they should not be used in truly portable code.
Kolega słyszał o czymś takim jak standard de facto?
Funkcje z rodziny err(3) i warn(3) są obecnie właśnie jednym z takich standardów w branży.
Więc nie dość że się czepiasz pierdół
Kolega wie, że w deklaracji funkcji nie bez powodu podajemy informację o typach parametrów i zwracanej wartości?
Dobrze, że w starszych standardach jest jakiś implicit int, ale nawet to Cię nie uratuje, gdy przypadkiem zawołasz funkcję zwracającą wskaźnik na typowym 64-bitowym systemie i klops, wynik zostanie obcięty do 32 bitów i będzie crash na produkcji :(
Jeszcze "ciekawiej" będzie, gdy w ten sposób zawołasz funkcję zwracającą strukturę przez wartość :(
Więc nie, nie uważam, żeby dbałość o odpowiednie #includy była "pierdołą", zwłaszcza dla kogoś, kto na swoje nieszczęście będzie później ten kod utrzymywał :(
to jeszcze nie masz racji.
Mam rację, co potwierdza jakieś 25 lat w branży, takim jestem starym dinozaurem :)