Jak ważny jest dobry styl kodowania dla decyzji o zatrudnieniu programisty? [Zamknięte]

15

Już jako student jestem proszony o przejrzenie kodu programistów, którzy (nie) zdali test (utwórz listę liczb Fibonacciego na Androidzie).

Chociaż jestem bardzo surowy w stylu kodowania, po prostu czytam o stylu „blokowym”, którego ktoś używał (czytaj komentarze!) .

Na moim stanowisku poleciłbym nie zatrudniać faceta stosującego ten styl. Kod jest całkowicie przeciwny do stylu kodowania stosowanego w mojej firmie.

Szukając stylu kodowania i radzenia sobie z jego brakiem, jestem ciekawy jednej rzeczy: czy powinienem zatrudnić faceta, który będzie miałpoważne kłopoty dostosowujesz styl kodowania stosowany w firmie?

Proszę: To nie powinna być dyskusja na temat ogólnego stylu kodowania i która jest lepsza. Chodzi o znaczenie stylu kodowania dla decyzji o zatrudnieniu!

Więcej informacji:

Nie jestem facetem, który podejmuje decyzję, po prostu wyrażam swoją opinię na podstawie kodu. Facet musi przejść rozmowę kwalifikacyjną, w której nasz szef sprawdza umiejętności miękkie. Jeśli zdał ten egzamin, musi zdać nasz mały test umiejętności i wtedy czasami proszony jestem o przejrzenie napisanego kodu. Nie jestem w stanie powiedzieć tak lub nie. Chcę tylko wiedzieć, jak ważny powinien być styl kodowania dla mojej recenzji ...

WarrenFaith
źródło
9
Sprytny. Zamiast usunąć „poważne problemy z przystosowaniem się” (które nie są poparte faktami), przeprowadź przez to linię. Jakby to faktycznie zmienia bezpodstawne twierdzenie o czyimś nastawieniu.
S.Lott,
2
Styl kodowania to najmniej ważna rzecz, na którą powinieneś zwrócić uwagę. W końcu to tylko kod.
SK-logic
7
Próbowałem odczytać twoje pytanie, ale trudno mi było śledzić twoje formatowanie. Czy możesz dodać tiret początkowe do akapitów. „K THX BAI
dietbuddha
2
Spójność kodu (lub jej brak) jest wskaźnikiem. Na przykład, jeśli ktoś nie ma czasu na uporządkowanie swojego kodu, prawdopodobnie również nie ma czasu na znalezienie odpowiedniego miejsca do zatwierdzenia nowego projektu w wersji wywrotowej. Prawdopodobnie nie mają czasu na refaktoryzację. I tak dalej.
Kevin
10
Styl kodowania jest absurdalnie łatwy do dostosowania. To tak, jakby zapytać: „Ta osoba nosi czarne garnitury, ale w naszej firmie wolimy, aby pracownicy nosili ciemnoszare garnitury. Mam je zatrudnić?” Po prostu powiedz im zasady stylu, które obowiązują w Twojej firmie. Problem rozwiązany.
soczysty Lucy

Odpowiedzi:

41

Skąd wiesz, że będzie miał problemy z przystosowaniem się? Tylko dlatego, że używają innego stylu kodowania? To dość zarozumiałe. Od dawna jestem kontrahentem i dostosowujesz się bez względu na używany styl kodowania. Może to trochę potrwać, ale nawyki kształtują się dość szybko.

Mam nadzieję, że styl kodowania nie oznacza jedynie wcięcia i układu kodu. Można to łatwo rozwiązać za pomocą formatyzatora kodu i zintegrowania go z systemem kontroli wersji.

Biorąc pod uwagę styl kodowania, np. Nazewnictwo, ogólne porządkowanie, separację jednostek i wszystko inne, co dotyczy czytelności i łatwości konserwacji, najważniejsze w stylu kodowania jest to, że masz taki kod. Nie który Brak stylu kodowania jest zdecydowanie czerwoną flagą.

Drugą najważniejszą rzeczą w jakimkolwiek stylu kodowania ktoś używa, jest to, że używa go konsekwentnie. Gdy ktoś wydaje się używać stylu kodowania, ale często „grzeszy” przeciwko niemu, jest to kolejna wyraźna czerwona flaga.

Marjan Venema
źródło
5
+1, które go nie mają lub nie używają go konsekwentnie, są „czerwonymi flagami”, a inny styl nie.
jv42
1
Całkowicie zgadzam się z „przynajmniej konsekwentnym stosowaniem”. To jest najważniejsze, kiedy przeglądam kod. Ale musisz przyznać, że styl / format kodu jest pierwszym wrażeniem, jakie masz, gdy spojrzysz na obcy kod ...
WarrenFaith
3
@WarrenFaith: więc oceniasz książkę po okładce? :-) Poważnie, tak, to robi pierwsze wrażenie, ale zakładam, że podczas wywiadu starałbyś się wyjść poza to i nie pominąć doskonale zdolnego programisty tylko dlatego, że jego obecny styl nie pasuje do twojego.
Marjan Venema
+1 za spójność: brak stylu ogólnie wskazuje, że nie napisali dużo. Kiedy piszesz, wybierasz nawyki.
Matthieu M.
1
Nienawidzę formatowania kodów automatycznych, ale mogę zaakceptować ich potrzebę. Wydaje się, że wybierają łamanie linii we wszystkich niewłaściwych miejscach. Tak, mówię o zaćmieniu.
Kevin
27

Programując setki różnych projektów dla prawie stu różnych klientów, chciałbym podkreślić jeden punkt.

Styl kodowania (i kłótnie o styl kodowania) to kompletna strata czasu.

Pogódź się z tym.

Przeczytałem dużo kodu od wielu różnych programistów. (Załóżmy, że mediana wielkości zespołu to 5 i 100 różnych zespołów. To 500 współpracowników.) Styl nie ma znaczenia.

Widziałem ładny, ale patologicznie niepoprawny kod.

[Jest limit. Umyślne zaciemnianie jest podstawą do rozwiązania umowy. Poza tym styl to strata czasu.]

Styl kodowania to „ostateczna granica”

Jeśli rozwiązałeś wszystkie problemy związane z tworzeniem oprogramowania; czy możesz natychmiast wygenerować bezbłędny kod mniej więcej; jeśli twój poziom jakości jest tak wysoki, nie masz już kolejki naprawiania błędów; jeśli Twoja użyteczność jest tak wspaniała, nie masz już biura pomocy; jeśli jesteś w stanie bezwzględnie optymalizować do tego stopnia, że ​​nie masz farmy serwerów, ale uruchamiasz przedsiębiorstwo z iPada ...

Gdy nie ma już nic do naprawienia, możesz w końcu skupić się na stylu kodowania.

Do tego czasu istnieje wiele problemów, które są większe i cenniejsze niż styl.

S.Lott
źródło
2
@WarrenFaith: Nie mogę powiedzieć tego wystarczająco mocno. Nie ważne. Powtórzę mój punkt. Przeczytałem (profesjonalnie, za opłatą, płatne godziny) kod od setek programistów. Nie ważne. To nie pierwsze wrażenie: poprawność i przejrzystość to pierwsze wrażenia.
S.Lott,
2
@WarrenFaith: Celowe zaciemnianie jest rzadkie. „jeśli po prostu nie umiesz czytać kodu” jest czymś, co może być tak samo problemem czytelnika, jak pisarza. Powtórzę mój punkt. Przeczytałem (profesjonalnie, za opłatą, płatne godziny) kod od setek programistów. „Po prostu nie mogę czytać” nigdy się nie wydarzyło. Styl nie ma znaczenia.
S.Lott,
2
Styl kodowania (i kłótnie o styl kodowania) to kompletna strata czasu. - Zgadzam się w 100% z drugim punktem i około 40% z pierwszym. Styl kodowania ma znaczenie - jeśli kodowanie w ogóle nie ma stylu. Jeśli tak, to nie ma znaczenia, jak to wygląda.
Treb
4
@WarrenFaith: Patrzyłem na próbkę i nie widzę tam niczego, co nie byłoby jasne. Nie jest sformatowany w sposób, w jaki mógłbym go sformatować, ale nic nie wskazuje na to, że kod nie będzie działał. Nie ma w tym nic niejasnego. Nic nie sugeruje, że osoba, która napisała, nie byłaby w stanie lub nie byłaby w stanie dostosować się do standardu zespołu. @ S.Lott ma rację. To nie ma znaczenia
Joel Etherton,
4
I używając //Importantna każdej linii. Ahem. Każdy wiersz kodu jest ważny lub należy go usunąć.
S.Lott,
7

Ocenianie programistów na podstawie stylu kodowania to 50% snobizmu i 50% niepewności.

Podoba mi się mój kod, żeby wyglądał schludnie i czysto, i wygląda na to, że facet, którego OP był naznaczony linkem, też. Nasz kod nie wygląda tak samo, ale oboje używamy stylu, który pomaga nam zrozumieć kod, gdy wrócimy do niego. Nie miałem absolutnie żadnych problemów ze zrozumieniem jego kodu i wątpię, żeby OP też to zrobił. „Rada” w stylu kodowania to nic innego, jak łatwy, tani strzał, w którym możesz przekazać swoją ogromną wiedzę na temat tego, dlaczego nawiasy klamrowe powinny znajdować się w następnej linii. To w ogóle nie ma znaczenia. Co sprawia, że ​​kod jest trudny do odczytania:

  • szalone konwencje nazewnictwa (lub ich brak), które nie opisują tego, co reprezentują.
  • szalony przepływ programu, który utrudnia stwierdzenie, co się dzieje (goto, try / catch z logiką biznesową itp.).
  • niesamowicie długie funkcje, które wykonują więcej rzeczy, niż mózg jest w stanie śledzić.

Mam problem z wyobrażeniem sobie jakiegokolwiek kodu, który nie zrobiłby żadnej z wyżej wymienionych rzeczy, ale nadal był trudny do odczytania, szczególnie za pomocą narzędzia takiego jak Style Cop.

Morgan Herlocker
źródło
7

To niedorzeczne, że format kodu jest czynnikiem decydującym o zatrudnieniu.

  1. Należy wziąć pod uwagę wiele innych ważnych czynników.
  2. Większość programistów może dostosować swój styl.
  3. Jeśli format jest tak ważny, użyj reformatera kodu i kontrolera kłaczków.

Nie zatrudnienie dobrego programisty, ponieważ nie dodaje spacji po przecinku, jest głupie.

dietbuddha
źródło
4

Podejrzewam, że masz oficjalny styl formatowania w firmie.

Następnie bardzo łatwo sformatuj dowolne źródło do oficjalnego stylu i najlepiej, aby stało się to automatycznie za każdym razem, gdy plik źródłowy jest zapisywany.

Każdy programista wart swojej soli pokocha to, ponieważ zapewnia wyższą jakość poprzez minimalizację różnic dla zatwierdzeń.


źródło
zapomniałem problemów z zatwierdzaniem ... i tak, mamy oficjalny styl formatowania, a także automatyczne formatowanie przed zapisaniem.
WarrenFaith
@ Warren, cóż, powiedz to podczas wywiadu i upewnij się, że programista rozumie, że jest to ważne. Wtedy to do niego należy spełnienie obietnicy, jeśli chce utrzymać pracę.
4

Użyj StyleCop

Jeśli korzystasz z programu Visual Studio, zawsze możesz wymusić reguły StyleCop w swojej kompilacji, dzięki czemu Twój kod będzie przynajmniej czytelny.

Odrzucam nieczytelny kod, prawdopodobnie niestandardowy , ponieważ w przyszłości będzie on trudny do utrzymania - nawet przez samych autorów. Zostało to udowodnione wiele razy w przeszłości.

Zintegrowane formatowanie kodu CVS = optymalne rozwiązanie

Byłoby naprawdę wspaniale, gdyby któryś z CVS obsługiwał automatyczne formatowanie kodu przy zameldowaniu. Właśnie ustawiłeś swoje priorytety stylu, kod zostanie sformatowany przed zapisaniem. To sprawiłoby, że styl specyficzny dla programistów stałby się przestarzały w zakresie formatowania kodu. Widzę problem, jeśli niektórzy programiści używają różnych znaków wcięcia. Patrzenie na inny kod (i mogę go łatwo i szybko sformatować ponownie) nie jest dla mnie problematyczne, ale DIFF staje się trudniejszy w obsłudze. Wiele fałszywych alarmów w narzędziu DIFF.

Robert Koritnik
źródło
Więc ... jeśli jakaś firma wynalazła własne standardy kodowania C #, czy byłaby to czerwona flaga?
Job
1
@Job: Niekoniecznie, ponieważ StyleCop pozwala na dodawanie dodatkowych reguł. Wiem, że napisałem dwa z nich, które wymuszały stosowanie TAB w stosunku do PRZESTRZENI, których w ogóle nie było. Ale chodzi o to, że można wymusić styl kodowania, co znacznie ułatwi jednolitość kodu.
Robert Koritnik
Co by było, gdyby ich styl powrócił do stylu StyleCop i gdyby w ogóle nie korzystali ze StyleCop - czy tak byłoby?
Job
@Praca. Chyba że ktoś nie pisze kodu C # tak, jakby to był stary Fortran (ktoś ma ustalony układ 80 kolumn?), Ale nadal uważam, że można poprosić o przestrzeganie stylu kodowania. Jeśli ktoś jest świetnym programistą, możesz mu przypomnieć o ulepszeniu swojego stylu (lub pozwolić mu uzasadnić swój styl w stosunku do naszego ). Do tego służy przegląd kodu. Każdy kod można szybko sformatować, ale należy przestrzegać przynajmniej konwencji nazewnictwa. Ale w żadnym wypadku nie jest to czerwona flaga do wynajęcia. Nie powinno być.
Robert Koritnik
3

Daleko poniżej następujące znacznie ważniejsze szczegóły:

  • Team Fit
  • Umiejętności rozwiązywania problemów
  • Komunikacja

Style kodowania mogą nauczyć się większość osób, które mają dwa ostatnie wymienione powyżej.

Jednak generalnie widzę próbkę kodu przed końcową rozmową, a jeśli styl kodowania jest daleki od tego, którego używamy, skupię się na pytaniach, które ujawniają ich zdolność do adaptacji.

pdr
źródło
W moim przypadku jest to często jedyna rzecz, którą widzę od faceta ...
WarrenFaith
@WarrenFaith - Ok, ale nigdy nie podejmiesz decyzji o zatrudnieniu kogoś na podstawie tak małej ilości informacji, prawda? Jesteś proszony o opinię.
pdr
Prawdziwe. Wydaję opinię z technicznego punktu widzenia, a umiejętności miękkie są również ważne. I testujemy tylko tych facetów, którzy przynajmniej zdali „test” umiejętności miękkich w wywiadzie. Ale jestem ciekawy, jaki wpływ powinien mieć styl kodowania na moją opinię ...
WarrenFaith,
@WarrenFaith - na twoim miejscu wspomniałbym o tym, ale raczej jako sidenote niż coś o ogromnym znaczeniu.
pdr
Zasadniczo sporządzam listę pro i contra oraz wyjaśniam i uzasadniam to dla naszego CTO. Ostateczna decyzja należy do niego ...
WarrenFaith
3

Tak długo, jak styl jest spójny i ta osoba jest w stanie dostosować się (zmienić) do innego stylu, nie widzę żadnych problemów.

Jeśli obecny styl różni się od tego, którego używasz, nie oznacza to, że jest zły. Dla kandydata może to mieć pełny sens.

Tak jak inni mówili, problem z adaptacją może być jedynym problemem.

Victor Hurdugaci
źródło
0

Nie powiedziałbym, że jest to zdecydowanie brak zatrudnienia, ale jest to silny argument przeciwko tej osobie.

Właściwie to nie martwiłbym się stylem kodowania, ale niemożnością przystosowania się, będącą objawem ogólnego problemu. Obawiałbym się, że kandydatowi może być trudno przystosować się również do innych aspektów kultury zespołowej.

Jeśli nie możesz otoczyć umysłu, używając stylu pascal zamiast obudowy w stylu wielbłąda, możesz mieć problemy z pamiętaniem o rozpoczęciu nowej porcji kawy, jeśli miałbyś wziąć ostatnią filiżankę. Takie rzeczy mogą być naprawdę szkodliwe dla zespołu.

(I tak, jestem uzależniony od kofeiny.)

Treb
źródło
Problemem związanym ze „złym stylem kodowania” jest często brak doświadczenia. Kiedy widzę najbardziej początkujących, często brakuje im czegoś, co można nazwać stylem kodowania.
WarrenFaith
?? „silny argument przeciwko tej osobie”… „tak naprawdę nie martw się o styl kodowania”. Który to jest? Czy to ważne czy nie? Z odpowiedzi trudno powiedzieć, jaka jest twoja rada. Proszę o wyjaśnienie?
S.Lott,
@ S.Lott: Co to jest? - Cóż, oczywiście oba. Zły styl kodowania to zły nawyk, większość ludzi może nauczyć się go rzucać. To wtedy, gdy nie mogą (lub nie chcą) dowiedzieć się, że masz problem.
Treb
0

Moim zdaniem dobry styl kodu jest niezbędny do pracy programisty.

Dobry styl kodu jest kwestią rozwoju osobistego. Jest to wskaźnik, który poziom osiągnął już ten programista.

Pytanie brzmi, czy Twoja firma chce „wysokich specjalistów” czy „wysokich potencjałów”. Jeśli potrzebujesz „wysokiej klasy specjalistów” i nie ma miejsca na naukę i rozwój - styl kodu jest nokautującym kryterium.

Jeśli jest miejsce na rozwój i rozwój programistów, lepiej zadbaj o jego zdolność do szybkiego uczenia się lub kreatywnego myślenia.

florianb
źródło