Czy powinienem stosować zły styl kodowania, aby przestrzegać ustalonych konwencji w moim miejscu pracy?

Pracuję w pracy od około roku. Pracuję przede wszystkim w interfejsie GUI, który wykorzystuje metody z zaplecza C, ale generalnie nie muszę sobie z nimi radzić, z wyjątkiem zwracanych wartości. Nasze GUI ma dość rozsądną strukturę, biorąc pod uwagę nasze ograniczenia.

Zadanie polegało na dodaniu funkcji do części wiersza poleceń programu. Większość z tych funkcji ma około 300 linii i jest trudna w użyciu. Próbuję zebrać ich fragmenty, aby uzyskać określone informacje o alarmie i mam problem z utrzymaniem porządku. Wiem, że komplikuję testowanie, wykonując je w jednej długiej funkcji.

Czy powinienem po prostu utrzymywać wszystko w wielkiej funkcji zgodnie ze stylem istniejących funkcji, czy też powinienem zawrzeć alarmy we własnych funkcjach?

Nie jestem pewien, czy należy postępować wbrew obecnym konwencjom kodowania, czy też powinienem po prostu ugryźć kulę i sprawić, że kod będzie dla mnie bardziej mylący.

Podsumowując, porównuję

showAlarms(){
    // tons of code
}

przeciwko

showAlarms(){
   alarm1();
   alarm2();
   return;
}

alarm1(){
    ...
    printf(...);
    return;
}

EDYCJA: Dziękuję za radę wszystkim, zdecydowałem, że zaprojektuję mój kod z uwzględnieniem faktów, a następnie zapytam, czego chcą, a jeśli chcą tego wszystkiego w jednym, mogę po prostu wyciąć z mojego kodu i przekształcić go z powrotem w 1 duża funkcja. To powinno pozwolić mi napisać i przetestować go łatwiej, nawet jeśli chcą całego kodu w jednej definicji.

AKTUALIZACJA: W końcu byli zadowoleni z faktorowanego kodu i więcej niż jedna osoba podziękowała mi za ustanowienie tego precedensu.

To naprawdę jest między tobą a kolegami z drużyny. Nikt inny nie jest w stanie udzielić właściwej odpowiedzi. Jeśli jednak odważę się czytać między wierszami, fakt, że nazywacie ten styl „złym”, daje pewne informacje, które sugerują, że lepiej jest robić to powoli. Bardzo niewiele stylów kodowania jest w rzeczywistości „złych”. Są takie, których sam bym nie użył, ale zawsze mają rym lub powód. Sugeruje mi to, że w tej historii jest coś więcej niż do tej pory. Zapytanie byłoby bardzo mądrym telefonem. Ktoś może wiedzieć coś, czego ty nie wiesz.

Natknąłem się na to, osobiście, na mojej pierwszej wyprawie w kierunku kodowania krytycznego w czasie rzeczywistym. Widziałem taki kod:

lockMutex(&mutex);
int rval;
if (...)
{
    ...
    rval = foo();
}
else
{
    ...
    rval = bar();
}
unlockMutex(&mutex);
return rval;

Będąc jasnym i błyszczącym programistą OO C ++, od razu wezwałem ich na ryzyko błędów, które mieli, ręcznie blokując i odblokowując muteksy, zamiast używać RAII . Nalegałem, żeby było lepiej:

MutexLocker lock(mutex);
if (...)
{
    ...
    return foo();
}
else
{
    ...
    return bar();
}

O wiele prostsze i bezpieczniejsze, prawda ?! Po co wymagać od programistów pamiętania o odblokowaniu muteksów na wszystkich ścieżkach przepływu sterowania, gdy kompilator może to zrobić za Ciebie!

Cóż, dowiedziałem się później, że istnieje ku temu powód proceduralny. Musieliśmy potwierdzić, że tak, oprogramowanie działało poprawnie i istniała skończona lista narzędzi, których wolno nam było używać. Moje podejście mogło być lepsze w innym środowisku, ale w środowisku, w którym pracowałem, moje podejście z łatwością pomnożyłoby ilość pracy związanej z weryfikacją algorytmu dziesięciokrotnie, ponieważ właśnie włączyłem koncepcję RAII w C ++ do sekcji kodu trzymano się standardów, które były naprawdę bardziej podatne na myślenie w stylu C.

Więc to, co wyglądało na zły, wręcz niebezpieczny, kodujący styl, było właściwie dobrze przemyślane, a moje „dobre” rozwiązanie było w rzeczywistości niebezpieczne, które mogło powodować problemy na drodze.

Więc zapytaj. Na pewno jest starszy programista, który może z tobą współpracować, aby zrozumieć, dlaczego robią to w ten sposób. Lub istnieje starszy programista, który może pomóc Ci zrozumieć koszty i zalety refaktora w tej części kodu. Tak czy inaczej, zapytaj!

Szczerze mówiąc, czy uważasz, że posiadanie trudnych w użyciu funkcji z 300 liniami to tylko kwestia stylu? Więc pójście za złym przykładem może utrzymać ogólny program w lepszym stanie ze względu na spójność? Chyba w to nie wierzysz, inaczej nie zadałbyś tego pytania tutaj.

Domyślam się, że te funkcje są tak długie, ponieważ w naszej firmie jest wielu miernych programistów, którzy po prostu nakładają funkcje na funkcje, nie dbając o czytelność, jakość kodu, prawidłowe nazewnictwo, testy jednostkowe, refaktoryzację i nigdy nie nauczyli się tworzyć odpowiednich abstrakcji . Musisz sam zdecydować, czy chcesz śledzić to stado, czy chcesz być lepszym programistą.

Dodatek, z uwagi na komentarze: „300 linii” i „trudny w użyciu” są silnymi wskazaniami IMHO na zły kod. Z mojego doświadczenia wynika, że ​​jest bardzo mało prawdopodobne, aby istniał jakiś „ukryty techniczny powód”, dla którego takiego kodu nie można zaimplementować w bardziej czytelny sposób, porównywalny z przykładem odpowiedzi Cort Ammon. Zgadzam się jednak z Cortem, że powinieneś omówić to z odpowiedzialnymi w zespole - nie po to, by znaleźć niejasne powody, dla których kod lub ten „styl” nie może zostać zmieniony, ale aby dowiedzieć się, w jaki sposób można bezpiecznie refaktoryzować kod bez zepsucia rzeczy .

Nie.

W książce Pragmatic Programmer autor mówi o teorii rozbicia okna .

Ta teoria stwierdza:

Rozważ budynek z kilkoma wybitymi oknami. Jeśli okna nie zostaną naprawione, wandale mają tendencję do wybijania kilku kolejnych okien. W końcu mogą nawet włamać się do budynku, a jeśli nie jest zajęty, może stać się squatters lub zapalić ogień w środku.

Lub rozważ chodnik. Niektóre śmieci gromadzą się. Wkrótce gromadzi się więcej śmieci. W końcu ludzie zaczynają nawet zostawiać torby z odpadkami z restauracji na wynos lub nawet włamać się do samochodów.

W książce autor pisze analogię między tą teorią a kodem. Gdy znajdziesz taki kod, przestajesz zadawać sobie to samo pytanie.

Odpowiedź brzmi: nie.

Gdy opuścisz to zepsute okno - w naszym przypadku zły kod - spowoduje to, że każdy pozostawi po sobie zepsute okno.

I pewnego dnia kod się zawali.

Daj wszystkim kopię Clean Code i Clean Coder .

Podczas gdy jesteś w temacie, kopia TDD jest również dobra.

Tak, idź po to. Struktura! = Styl

Mówisz o strukturze, a nie o stylu. Wytyczne stylu (zwykle) nie określają struktury, ponieważ struktura jest wybierana na ogół ze względu na jej odpowiedniość dla konkretnego problemu, a nie odpowiedniość dla organizacji.

Bądź ostrożny

Po prostu bądź pewien, że nie wywołujesz negatywnych konsekwencji w innych obszarach, które mogły ci nie przynieść. Na przykład,

• Upewnij się, że nie komplikujesz różnic ani scalania kodu, ponieważ zatarłeś wszelkie podobieństwa do istniejącego kodu.
• Upewnij się, że przepływy wyjątków poprawiają się, a ślady na stosie nie są zanieczyszczone ogromną kupką nieczytelnych bzdur.
• Upewnij się, że nie ujawniasz przypadkowo publicznych punktów wejścia, które wywołałyby problemy, gdyby zostały wywołane bezpośrednio (nie umieszczaj ich na mapie i / lub nie eksportuj ich).
• Nie zaśmiecaj globalnej przestrzeni nazw, np. Jeśli wszystkie twoje mniejsze funkcje wymagają pewnego rodzaju globalnego kontekstu, który został wcześniej zadeklarowany w zakresie funkcji lokalnych.
• Pamiętaj, aby spojrzeć na dowolne dzienniki i zadać sobie pytanie, czy byłeś w zespole wsparcia, czy dzienniki wygenerowane przez Twój kod byłyby mylące, gdyby były widoczne wplecione w dzienniki z dowolnego kodu, którego nie dotykasz.
• Upewnij się, że stosujesz się do istniejącego stylu, np. Nawet jeśli używają oldskulowej notacji węgierskiej i powoduje to krwawienie oczu, pozostań spójny z ogólną bazą kodu. Jedyną rzeczą bardziej bolesną niż czytanie notacji węgierskiej jest czytanie kodu, który wykorzystuje tuzin różnych rodzajów notacji w zależności od tego, kto co napisał.

Bądź łagodny

Pamiętaj, że należysz do zespołu i chociaż dobry kod jest ważny, bardzo ważne jest również, aby członkowie Twojego zespołu mogli zachować to, co napisałeś podczas wakacji. Staraj się trzymać strumienia, który będzie miał sens dla osób przyzwyczajonych do starego stylu. To, że jesteś najmądrzejszym facetem w pokoju, nie oznacza, że ​​powinieneś mówić ponad głowami wszystkich!

Nie uważam tego za konwencję kodu. Widzę to jako kogoś, kto nie rozumie, jak napisać łatwy do utrzymania kod, który można łatwo utrzymać. Rozbiłbym twój kod na różne funkcje, gdy sugerujesz i edukuję Twój zespół w zakresie korzyści płynących z tego, próbując zrozumieć, dlaczego ich zdaniem funkcje 300-liniowe są dopuszczalne. Byłbym bardzo zainteresowany usłyszeniem ich uzasadnienia.

Odpowiedź znajduje się w przeglądzie kodu.

Prawdziwe pytanie brzmi: czy jeśli wprowadzisz dobrze zindywidualizowany kod, czy będziesz jedynym, który będzie chciał z nim pracować?

Ja, jak większość ludzi tutaj, wierzę, że 300 funkcji linii jest obrzydliwością. Jednak zabranie Windex na wysypisko nie przyniesie wiele dobrego. Problemem nie jest kod, to kodery.

Sama racja nie wystarczy. Musisz sprzedawać ludzi w tym stylu. Przynajmniej po przeczytaniu. Jeśli nie skończysz jak ten biedny facet: zwolniony, ponieważ twoje umiejętności są zbyt daleko ponad twoich współpracowników

Zacznij od małego. Zapytaj i dowiedz się, czy ktoś preferuje mniejsze funkcje. Lepiej jeszcze przeszukuj bazę kodu i sprawdź, czy możesz dowiedzieć się, kto pisze te najmniejsze (może się okazać, że najbrzydszy kod to najstarszy kod, a obecni koderzy piszą lepszy kod). Porozmawiaj z nimi na ten temat i sprawdź, czy masz sojusznika. Zapytaj, czy znają kogoś, kto czuje to samo. Zapytaj, czy znają kogoś, kto nienawidzi małych funkcji.

Zbierz tę małą grupę i porozmawiaj o wprowadzaniu zmian. Pokaż im kod, który chcesz napisać. Upewnij się, że potrafią to przeczytać. Potraktuj poważnie wszelkie zastrzeżenia. Dokonaj zmian. Uzyskaj kod zatwierdzony. Masz teraz moc spotkania za sobą. Jeszcze kilka takich i możesz stworzyć jednostronicowy dokument, który wyraźnie zaakceptuje nowy styl, który wprowadziłeś.

Spotkania to zaskakująco potężne rzeczy. Mogą wytwarzać siłę przebicia. Siła służy do walki z przeciwnikami tego ruchu. I to właśnie w tym momencie. Ruch. Walczysz o prawo do poprawy status quo. Ludzie boją się zmian. Będziesz musiał słodko porozmawiać, zachęcić i prod. Ale przy odrobinie szczęścia zmienisz się w prawo do bycia zaakceptowanym.

Czasami musisz iść z prądem.

Tak jak powiedziałeś, masz za zadanie zaimplementować funkcję w istniejącej bazie kodu.

Niezależnie od bałaganu i rozumiem, że to kuszące, aby go posprzątać. ale w świecie biznesu nie zawsze masz szansę na zmianę kodu.

Powiedziałbym, po prostu rób to, o co cię poproszono i przejdź dalej.

Jeśli uważasz, że warto je przeredagować lub przepisać, to musisz porozmawiać z zespołem.

Przed stwierdzeniem, że praktyki są złe, najpierw zrobię krok w kierunku zrozumienia przyczyny dużych metod i innych praktyk, które mogą okazać się złe.

Następnie musisz upewnić się, że zasięg testu jest dość wysoki lub naprawdę wysoki (o ile możesz to zrobić bez większego refaktoryzacji). Jeśli tak nie jest, starałbym się, aby zasięg był naprawdę wysoki, nawet jeśli nie napisałeś kodu. Pomaga to budować relacje, a nowy zespół traktuje cię poważniej.

Gdy te bazy zostaną już omówione, nikt przy zdrowych zmysłach nie rzuci ci wyzwania. Jako przedmiot dodatkowy wykonaj mikro-testy porównawcze, które naprawdę dodadzą ci efektu.

Często sposób, w jaki to wypowiadasz, znacznie zmienia kulturę kodu. Dawaj dobry przykład. Albo jeszcze lepiej, poczekaj na kawałek kodu, który możesz napisać - refaktoryzacja i testowanie jednostki, do diabła - i usłyszysz altówkę - usłyszysz.

Tego rodzaju pytanie jest w zasadzie „ proszę, przeczytajcie moich kolegów z zespołu ”. Losowi ludzie w Internecie nie mogą tego zrobić, więc wszystkie odpowiedzi, które otrzymasz, to tylko osobiste opinie na temat stylu kodowania. Konsensus jest taki, że preferowane są krótsze metody, ale wydaje się, że już tak myślisz, więc nie musisz tego powtarzać.

Tak więc obecna baza kodu wydaje się używać innego stylu kodowania niż ten, który preferujesz. Co powinieneś zrobić? Najpierw musisz dowiedzieć się:

1. Czy jest to celowa decyzja projektowa poparta przez Twój obecny zespół?
2. Czy chcą, żebyś postępował zgodnie z tym stylem?

Jest tylko jeden sposób, aby się przekonać. Zapytać .

Może istnieć wiele przyczyn posiadania długich funkcji. Może tak być, ponieważ zespół uważa, że ​​długie funkcje są lepsze niż wiele krótkich funkcji. Może to być również spowodowane tym, że jest to starszy kod, a zespół woli, aby nowy kod był bardziej przejrzysty. Więc albo wybór może wylądować cię w kłopoty jako deweloper, jeśli nie rozmawiać z zespołem i zrozumieć ich rozumowania.

Istnieją różne poziomy „stylu”.

Na jednym poziomie, zwykle będącym częścią konwencji kodowania, oznacza to, gdzie należy umieścić białe spacje, puste linie, nawiasy i jak nazywać rzeczy (małe litery, podkreślenia itp.).

Na innym poziomie znajduje się model programowania, czasem rzeczy takie jak unikanie statyki lub używanie interfejsów zamiast klas abstrakcyjnych, jak ujawniać zależności, a może nawet unikać niektórych ezoterycznych cech języka.

Potem są biblioteki i frameworki używane w projekcie.

Czasami będzie maksymalny limit wielkości funkcji. Ale rzadko istnieje minimalny limit! Powinniście więc dowiedzieć się, które z tych mocy należy uznać za ważne, i starać się to uszanować.

Musisz dowiedzieć się, czy zespół nie chce zrefaktoryzować istniejącego kodu, co należy zrobić niezależnie od dodania nowego kodu, jeśli to możliwe.

Jednak nawet jeśli nie chcą one refaktoryzować istniejącego kodu, możesz być w stanie wprowadzić niektóre warstwy w abstrakcjach dla nowego kodu, który dodajesz, co oznacza, że ​​z czasem możesz opracować lepszą bazę kodu i migrować stary kod jako jego utrzymanie wymaga.