Ostatnio przełączam się między kilkoma projektami i środowiskami programistycznymi. Oczekiwania co do stylu kodowania w każdym są inne.
Moje pytanie składa się z trzech części, po pierwsze z ciekawości:
Odpowiedzi:
№1. # Jak zdefiniowałeś i znalazłeś swój styl kodowania?
Poprzez próbki kodu najpierw w książkach, potem w tekstach i artykułach MSDN, a następnie na blogach i innych stronach internetowych.
№2. Jak ciągle go ulepszasz i poprawiasz?
Mam oko otwarte na wszelkie sugestie ludzi. Wypróbowuję je, jeśli pracują dla mnie, zostają. Od czasu do czasu eksperymentuję, a to, co wydaje się poprawiać, pozostaje we mnie.
№3. Jak to utrzymujesz? (Z notatek, prowadzenia dokumentu, korzystania z narzędzi takich jak StyleCop itp.)
W pewnym sensie pamiętam swój styl i stosuję go automatycznie wszędzie.
Uwaga 1. Utrzymywanie otwartego oka i ostrego ucha jest niezwykle ważne, aby pozostać na bieżąco. Wiele lat temu dowiedziałem się od innych, że notacja Węgier była koniecznością, więc poszedłem za nią. Kiedy społeczność zdała sobie sprawę, że to nie takie wspaniałe, zmieniłam się ze wszystkimi.
Uwaga 2. Często nie jest tak ważne, jakie konkretne elementy stylu przyjmujesz, ale raczej, aby zachować spójność stylu przez wszystkie kody. To samo dotyczy zespołu. Wybierz styl, ale trzymaj się go.
Uwaga 3. Style kodowania dla różnych języków mogą się różnić. C ++ zasługuje na jeden styl, Java na drugi. HTML i CSS mają swoje cechy, które wymagają nieco innego stylu.
Uwaga 4. Jakikolwiek styl wybierzesz, zrozum i zaakceptuj, że nie zadziała w 100%. Czasami masz jakiś kod, który wymaga innego stylu po prostu na miejscu, albo podzielony multilinię, inne wyrównanie lub cokolwiek, aby ten fragment kodu był bardziej czytelny. Nie popychaj swojego stylu wszędzie, skup się na czytelności kodu. Jeśli to oczywiste, styl nie działa w tym konkretnym miejscu, zrób wyjątek.
Uwaga 5. Nie rób wyznania stylu kodu religii. Narzędzia wymuszające styl kodu są dobre, ale czasem mogą doprowadzić Cię do szału. Na przykład wyłączyłem automatyczne formatowanie kodu Visual Studio, ponieważ doprowadzało mnie to do szału. Jeśli narzędzie stanie się przeszkodą, po prostu dodaj wyjątek i nie martw się, że Twój kod nie jest w 100% zgodny. To naprawdę nie jest tak ważne, a doskonałość jest nieosiągalna.
Nie sądzę, że był czas, kiedy powiedziałem: „Ok, to będzie mój styl”. Skoncentruj się na określonym środowisku lub języku. Twój styl powinien odzwierciedlać sposób, w jaki napotykasz pewien problem.
Pracowałem w zespole z zamkniętą wersją źródłową, którą kochałem, a główny programista mnie mentorował i pomógł mi poprawić swoje umiejętności, gdy go o to poprosiłem.
Zasugerował, a ja przyjąłem styl kodowania Zend Framework (http://framework.zend.com/manual/en/coding-standard.html)
W końcu przyjąłem cechy różnych stylów - w tym style odzwierciedlone w MSDN. Następnie konfiguruję szablony w VS, które zapewniają moje #region/#endregionbloki i wszystko, co jest preferowane.
Kontynuuję naukę innych stylów, które spotykam poprzez badania i czytanie. Jeśli myślę, że jest coś, co wyróżnia się i może poprawić mój styl w zakresie czytelności, konserwacji lub organizacji, wypróbuję to. Jeśli nowe dostosowanie stylu jest w porządku, zaktualizuję szablony w VS lub zrobię notatki w myślach.
Gdy koduję sam, dążę do zwięzłości; Programowanie Spartan może być kompletne, szaleństwo z szaleństwem ... Ale to chyba najbliższa znajoma rzecz do mojego wyznania.
Podczas kodowania z innymi, szczególnie kodowania konserwacyjnego, staram się być kameleonem - moje zmiany powinny poprawić to, co modyfikują, nie patrząc nie na miejscu.
Jak zdefiniowałeś i znalazłeś swój styl kodowania?
Koncentrując się na prostocie i czytelności (czytelność! == zrozumiałość, patrz Programowanie Spartan )
Jak ciągle go ulepszasz i poprawiasz?
Przeglądając kod innych i mój własny (a nawet same standardy kodowania).
Jak to utrzymujesz? (Z notatek, prowadzenia dokumentu, korzystania z narzędzi takich jak StyleCop itp.)
Używam dokuwiki , łatwej do skonfigurowania (bez bazy danych), hierarchicznej struktury, szczegółowej kontroli (ACL po wyjęciu z pudełka), naprawdę ładnego wyglądu, no i jest to wiki, więc każdy może się przyłączyć. Ponadto wkłady / zmiany są zawsze zgodne i uzasadnione, oparte na prostocie i czytelności.
To trochę dziwna odpowiedź, ale zajęło mi naprawdę dużo czasu, aby zacząć programować. Sporo czasu poświęciłem na pracę w „sztuce”, zanim uznałem się za programistę.
Podczas kodowania zwykle myślę w jednostkach takich jak pisanie - akapity, frazy itp. Z tego powodu rozłożę kod na więcej wierszy, aby uczynić go czytelnym jak opowiadanie / esej / itp. Jestem naprawdę zirytowany, gdy programiści próbują wcisnąć jak najwięcej w jedną linię lub w małą przestrzeń, ponieważ nie osiąga niczego poza tym, że pisarz czuje się sprytny i irytujący przyszłych czytelników.
Jeśli muszę zrobić coś dziwnego ze względu na wydajność, skomentuję to, aby wyjaśnić, dlaczego tak jest.
Prawdopodobnie nie otrzymam żadnych pozytywnych opinii na ten temat, ale być może i tak wywoła to dyskusję.
Jeśli chodzi o stronę techniczną, jak umieszczanie nawiasów i tym podobne, trzymam je w jednej linii, ponieważ wynikiem jest zwiększona czytelność.
1. How did you define and find your coding style?
Postanawiam przyjąć już opracowany przewodnik po stylu, który został w dużej mierze opracowany i powszechnie zaakceptowany lub spopularyzowany przez dużą firmę / projekt.
Robię to z wielu powodów, ale głównie dlatego, że takie przewodniki po stylu mogą zostać natychmiast przyjęte przez programistów. Przewodnik po stylu jest wart tyle, ile programiści chcą go trzymać.
Przykłady takie są Pythona PEP 8 , przewodnik redakcyjny Android Java , jQuery Rdzeń przewodnik redakcyjny lub Python Podręcznik stylu Google'a .
2. How do you keep augmenting and improving it?
Największym argumentem za takimi przewodnikami stylowymi jest to, że nie zostały one wymyślone tutaj i nie wymyślone przeze mnie. Zajęło to dziesiątki programistów, zastraszające linie kodu i więcej czasu, niż Twoja firma / zespół kiedykolwiek byłby skłonny zainwestować w opracowanie i utrzymanie przewodnika po stylu.
Jeśli chodzi o ulepszenia, nigdy nie było przewodnika stylu, który natychmiast odpowiada na wszystko , co możesz potrzebować wiedzieć. Ale w większości przypadków ulepszenia, które widziałem, że były popychane do przodu, były po prostu bardziej szczegółową wersją tego, co przewodnik po stylu już ułożył dzięki podejściu do pisania kodu.
W takich przypadkach, gdy natrafisz na blok dziwactwa, powinieneś wkleić go do gist lub innego odpowiedniego narzędzia do dzielenia fragmentów kodu ze wsparciem składni kolorów i omówić go gdzieś z innymi programistami. Świetną rzeczą jest to, że w takich przypadkach nie jesteś zainteresowany tym, co robi kod, ale tylko jak wygląda kod, dzięki czemu możesz usunąć ten blok z kontekstu i omówić, jak powinieneś go ulepszyć, porównując go z tym, co już określono w przewodnik po stylach jako główny punkt wyjścia do dyskusji.
3. How do you maintain it?
Cóż, wspaniałe jest to, że masz już istniejące dokumenty, które są publicznie utrzymywane online.
Jeśli chodzi o formatowanie kodu, możesz także zrobić wiele więcej i zapewnić swojemu zespołowi konfiguracje formatyzatora dla ich ulubionego edytora, co powinno wyeliminować niepotrzebne i zgadywanki w utrzymaniu doskonałego wyglądu. Właściwie nie nazwałbym tego wyjściem dodatkowej mili, ale integralną częścią rozwoju - nie ma nic gorszego niż zrobienie różnicy, w której 90% zmian kodu było czyimś zameldowaniem poprawnie sformatowanego / stylizowanego kodu, ponieważ ktoś zapomniał posprzątać, zanim wprowadzili ogromną nową funkcję.
Jeśli należysz do zespołu, powinieneś zawsze uzupełniać standard zespołu. Można powiedzieć, że używasz ogólnego układu, a nie własnego. To sprawia, że Twój kod jest łatwiejszy do odczytania i zrozumienia przez innych, co jest niezbędne.