Wpis z mikrobloga

@Jailer: "That thing makes the world actively a worse place to live" xDDD Uwielbiam Linusa!

A prawda jest taka, że umiłowanie do takich helperów wzięło się z tej całej filozofii clean code i innych wynalazków.
  • Odpowiedz
@Jailer zadziwia mnie, jak człowiek "tak delikatny" jak Linus może być dla kogokolwiek autorytetem. A sama funkcja pewnie mogła by być lepiej nazwana ale ułatwia czytanie kodu.

@groman43 owszem, jeśli dobrze to robisz to kod czyta się dobrze. Jeśli funkcja swoją nazwą odzwierciedla to, co robi to zamiast analizować o co chodzi w c = a + b od razu wiesz, że masz do czynienia z tym i tym. Nie
  • Odpowiedz
@SkorpionX: Jeśli potrzebujesz nazwanej funkcji, żeby zrozumieć kod w stylu "(a << 16) + b", to czas odłożyć klawiaturę i nie programować więcej.

@ly000 Kernel to jeden z najlepiej napisanych projektów open-source na świecie.
  • Odpowiedz
  • 3
kod w repo linuxa to syf


@ly000: nie wiem, czy piszesz na serio, czy trollujesz, więc ograniczę się do komentarza, który pasuje do obu przypadków:

  • Odpowiedz
@SkorpionX:

A sama funkcja pewnie mogła by być lepiej nazwana ale ułatwia czytanie kodu.


No problem w tym że w tym przypadku akurat nie ułatwia i dlatego Linus się odpalił:

if you write makeu32fromtwou16(a,b) you have not a f%^5ing clue what the word order is
  • Odpowiedz
@groman43 nie, nie potrzebuję do tego, żeby wiedzieć, co to robi ale uważam, że pomaga to szybciej złapać, po co to robi. Nazywanie fragmentów kodu naprawdę ma sens ( ͡~ ͜ʖ ͡°)
  • Odpowiedz
@Jailer: stworzenie funkcji make_u32_from_two_u16 powoduje, że finalna binarna jest mniejsza, bo kompilator przechowuje raz w kodzie tę operację niż pierdyliard razy, i sobie skacze po kodzie (jmp)
  • Odpowiedz
stworzenie funkcji make_u32_from_two_u16 powoduje, że finalna binarna jest mniejsza, bo kompilator przechowuje raz w kodzie tę operację niż pierdyliard razy, i sobie skacze po kodzie (jmp)


@new-object lol, co? Który kompilator? Bo jest ich trochę i każdy może przyjąć inną strategię optymalizacji. Może kod zostanie potraktowny podobnie do inline? Jeszcze mocno zależy to od wybranego poziomu optymalizacji. Poza tym pomijam, że operacja skoku może być kosztowna z wielu względów, jak np.
  • Odpowiedz
@Jailer: Można pisac helpery i robic to sensownie i mozna robic to zle. Ten kod jest zly bo to jest dokladnie to co clang opisuje jako "bugprone-easily-swappable-parameters"
https://clang.llvm.org/extra/clang-tidy/checks/bugprone/easily-swappable-parameters.html

Rozwiazanie na "you have not a f%^5ing clue what the word order is" to zrobic strukture i nazwac sensownie parametry. Helpery pomagaja jak jest jakas bardziej rozbudowana logika niz + i <<, inny plus "helperow" to mozna je unit testować, czego jesli
  • Odpowiedz
@kontodotestowania helpery ciężko się testuje bo zwykle są statyczne, albo wprost inline definiowane w nagłówkach.
A C jest w ogóle dość nietrywialne w testowaniu. Tj. wstrzykiwanie musisz robić jawnie linkerem itp. cuda.
Nie jest to może jakoś ultra trudne, ale jak biorą się za to ludzie którzy nie mają żadnego pojęcia co robią to kończy się tak jak kiedyś z naszymi projektowymi majfrendami, że testy napisali tak, że istniały w ogóle
  • Odpowiedz
stworzenie funkcji makeu32fromtwou16 powoduje, że finalna binarna jest mniejsza


@new-object: chyba z konia spadłeś. Wywołanie + oraz << to dwie operacje w assemblerze. A żeby wywołać funkcje, to trzeba żonglować stosem i robić goto. O ile kompilator nie zoptymalizuje tego jako inline - wtedy na jedno wyjdzie.
  • Odpowiedz
@Jailer: Aaah, aż przypomniało mi się jak w jednym projekcie napotkałem funkcję isSecondHigher(a, b), która po prostu zwracała b > a. Oczywiście rozpisana z pełnym if'em na 4 linijki xD
  • Odpowiedz
@SkorpionX @groman43

takie głupie pytanie, ale czy precyzyjne nazywanie funkcji i dodawanie komentarzy opisujących co robi dany fragment kodu, czasem nie pomaga trenować ai, która w zamian redukuje moeksca pracy dla programistów?
  • Odpowiedz
@dreadingit: AI wgle powinni zakazać lub programiści zbojkotować to bo zabierze nam to miejsca pracy. Lecz niestety programiści jedno co zrobili źle to nie ochronili swoich miejsc pracy tak jak inne niektóre zawody do, których trzeba mieć jakiś "papier" lub "zaświadczenie" czy dyplom. Są jeszcze inne błędy, które programiści popełnili, ale to raczej większa część pracująca dla open source lub w czasie boom zarobkowego i pracy zdalnej wie
  • Odpowiedz