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

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 ...

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.

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.

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.

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.

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ń.

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.

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.

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.

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.)

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.