Szczegółowość podczas analizy kodów źródłowych

Question

Witam,

Często jesteśmy poddani walidacji naszych kodów źródłowych. Zauważyłem, iż często ludziom zdarza się zapomnieć o tak banalnych sprawach jak przecinki, średniki, literówki. Zauważyłem również, że są tacy, którzy tylko spojrzą na coś i od razu potrafią "wychwycić" co jest nie tak. Według mnie jest to bardzo potrzebna umiejętność, szczególnie podczas programowania. Chodzi o to, iż ja (i zapewne większość z nas) przynależy do pierwszej opisanej przeze mnie grupy ludzi. Co tak naprawdę różni pierwszą grupę od drugiej? Czy można nauczyć się czegoś takiego? Zauważyłem, że skupianie się "na siłę" nie działa, ponieważ wtedy ignorujemy wiele innych aspektów, przez co zrozumienie kodu staje się trudniejsze. Czy wiecie może/czy macie jakieś "tipy" jak można właśnie dostrzegać takie szczegóły, zachowując przy tym zrozumienie czytanego kodu?

Z góry dziękuję za pomoc. 

Answer 1

o tak banalnych sprawach jak przecinki, średniki, literówki

W tym przypadku akurat chwała kompilatorowi C++, że sporo takich błędów wyłapuje.

A tak na marginesie problem brakującego średnika sugeruje, że piszesz w jakimś notatnikiu :P. Zaopatrz się w porządny linter to Ci na żywo podkreśli i podpowie, że panie programisto chyba pan zapomniał średniczka.

Ogólnie problem troszkę na wyrost. Umiejętność takiej analizy przychodzi z czasem. Po prostu programuj. Im więcej takich błędów zobaczysz i wytropisz tym będziesz w tym lepszy.

Comments

Bardzo Ci dziękuję :)

Answer 2

Szczerze to niezbyt rozumiem problem... jeśli chodzi o formatowanie kodu, to chłopie, od tego są narzędzia :) Sam nieraz łapię się na tym, że piszę sobie parę linijek kodu nie patrząc jakoś szczególnie na wcięcia itp. a potem jeden klik na klawiaturze i prettier zrobi całą magię i ładnie sformatuje :)

Stosowanie takich narzędzi ma też tę zaletę, że każdy programista w danym projekcie będzie wypluwał kod sformatowany w jeden sposób. Dodatkowo wystarczy sobie zapiąc jakiegoś hooka np. na pre commicie aby mieć pewność, że nic nie wleci do mastera bez "obróbki".

Co do literówek np. w nazwach funkcji/metod itp. no to powinno to wychodzić na CR... tutaj dużo zalezy od tego jak faktycznie podchodzi się w firmie do jakości CR... u mnie np. w wielu projektach jest wymóg minimum 2 CR aby zmergować coś do mastera i jest to w dłuższej perspektywie spoko bo naprawdę wiele pierdół potrafi wyjść w czasie review.

Także wszędzie tam, gdzie można sobie ułatwić życie jakimś gotowym rozwiązaniem to naprawdę warto się nad tym zastanowić... Można toczyć dyskusje "taby czy spacje", ale takie dyskusje powinny dotyczyć tylko i wyłącznie ustawień auto formattera, a nie tego, w jaki sposób programista ma faktycznie pisać swój kod...

Comments

i jeszcze taka uwaga do CR... to jest to miejsce, gdzie Ci bardziej doświadczeni programiści powinni nie tylko sprawdzić jakoś głównego kodu ale również przeanalizować czy np. w testach jednostkowych ująłeś wszystkie możliwe przypadki itp. Moim zdaniem bez UT nie ma kodu produkcyjnego, ale tutaj są różne argumenty za i przeciw... choć w moim odczuciu są tylko i wyłacznie zalety.

---

Raczej nie chodziło mi o "wygląd" kodu.

Chodziło mi o takie gafy typu int liczba = 'g' albo char znak = "x" (no albo coś typu, że na końcu wiersza zamiast ';' wstawia się ','  -> to jest tylko przykładzik)

Chciałbym jeszcze dodać, iż raczej jestem początkującym programistom i dużo rzeczy, które napisałeś, po prostu nie rozumiem, zatem czy można by trochę prościej opisać?

---

generalnie od takich rzeczy są tzw. lintery kodu i narzędzia do formatowania. Na przyklad w świecie JS masz eslint, tslint, prettier (z tych korzystam na co dzień). W zależności od języka musisz poszukać odpowiednich dla siebie narzędzi. I tak jak pisałem, przede wszystkim CR, nie bój się podejść do jakiegoś seniora i poprosić o CR Twojego PR, na początku pewnie będzie wiele uwag, ale z czasem nabierzesz wprawy. Na wszystko przyjdzie czas.

---

A co to jest to PR?

---

pull request, ale oki, skoro tego nie wiedziałeś to domyślam się, że nie pracujesz jeszcze zawodowo jako programista bo pull requesty byłyby dla Ciebie codziennością. Ucz się w takim razie spokojnie kodowania, poczytaj sobie o linterach kodu i pracuj z jakimś dobrym IDE, który pomoże Ci w wielu przypadkach i łatwo integruje się z linterami itp.

---

Dzięki ;)

---

bo pull requesty byłyby dla Ciebie codziennością

Mógłby spokojnie pracować używając gerrita do CR gdzie nie ma pull requestow :p