Czy obsesja na punkcie sprawiania, że ​​kod „wygląda ładnie”, ma jakieś zalety?

Czasami spędzam absurdalnie dużo czasu (godzin) na zadręczaniu się, aby kod „wyglądał ładnie”. Chodzi mi o to, aby wszystko wyglądało symetrycznie. W rzeczywistości szybko przewijam całą klasę, aby zobaczyć, czy coś wyskoczy jako nie wyglądające „ładnie” lub „czysto”.

Czy marnuję czas? Czy takie zachowanie ma jakąś wartość? Czasami funkcjonalność lub wygląd kodu nawet się nie zmieni, po prostu go przebuduję, aby wyglądał ładniej.

Czy jestem po prostu całkowicie chory na zaburzenia obsesyjno-kompulsyjne, czy kryje się w tym jakaś korzyść?

Użyj automatycznego formatowania. Jeśli naprawdę spędzasz tyle czasu ręcznie edytując kod, chętnie zgadnę, że nie jesteś zbytnio wyzwany / znudzony, ponieważ nie ma absolutnie żadnego powodu. Ctrl + K, Cntrl + D w VS sformatuje cały dokument. Możesz użyć czegoś takiego jak Style Cop, jeśli chcesz czegoś cięższego.

Dobrze jest mieć dumę ze swojego kodu, ale nie wtedy, gdy dzieje się to kosztem bycia inteligentnym (szukanie najbardziej wydajnego rozwiązania. W tym przypadku za pomocą narzędzia do automatyzacji żmudnego procesu) i robienia rzeczy (co innego mogłoby to zrobić pracowałeś w tych godzinach?).

Jeśli nie zmieniasz niczego, co pozwala na lepsze zrozumienie, to tak, marnujesz swój czas.

Nic ukrytego, ładny kod jest łatwy do odczytania i utrzymania.

„Godziny” wydają się trochę nadmierne, chyba że masz dużą bazę kodów. Nie wszystko musi być idealne, po prostu musi być dobre

To kwestia osądu; jeśli spędzasz godziny, powiedziałbym, że przesadzasz. Są jednak rzeczy, które człowiek może zrobić, a których nie potrafi automatyczny formatator, i rzeczy, które możesz zrobić, aby uczynić kod bardziej czytelnym, a które trudno jest uchwycić w korporacyjnych standardach kodowania.

Na przykład, kiedy deklaruję zmienne w klasie, lubię mieć logiczne grupowanie - ułatwia to podążanie za logiką.

Kod jest zwykle uważany za „pisz raz, czytaj wiele”, więc sprawienie, by czytanie było przyjemne, jest dobrym nawykiem - ale moim zdaniem układ jest znacznie mniejszy niż wyraźne konwencje nazewnictwa, czyste abstrakty i dobrze ustrukturyzowane podpisy metod.

Widziałem pięknie sformatowany kod, który powodował poważne momenty WTF, ponieważ leżący u jego podstaw proces myślowy był wadliwy. Jeśli masz godziny do spędzenia, spędziłbym to na projektowaniu i refaktoryzacji, a nie na układzie ....

Nie, nie jesteś całkowicie OCD. Największym komplementem, jaki kiedykolwiek słyszałem jako programista, było: „Twój kod jest tak czysty, że mój młodszy brat mógł go zrozumieć”.

Pewnego dnia ktoś będzie musiał obsługiwać Twój kod. Czysty kod jest znacznie łatwiejszy do obsługi. I któregoś dnia możesz być tobą. Za 6 miesięcy lub roku nie będziesz pamiętać, co zrobiłeś. Ale jeśli będzie czysty i łatwy do odczytania, szybko wróci.

To powiedziawszy, jeśli kod jest śmieciem, nie pomaga być ładnym śmieciem. Ale jeśli jest dobrze skonstruowany i ma tylko problemy z funkcjonalnością, znacznie łatwiej będzie poprawić funkcjonalność.

Nie - obsesja na punkcie upiększania kodu nie ma sensu .

Oto kilka mądrości, które uznałem za przydatne:

Zapytaj, dlaczego kod musi być uporządkowany.

Możesz lub nie marnować czasu w zależności od twojej definicji ładnej.

Fundamentalne twierdzenie o formatowaniu mówi, że dobry układ wizualny pokazuje logiczną strukturę programu. Sprawienie, by kod wyglądał ładnie, jest coś warte, ale jest mniej warte niż pokazanie struktury kodu. [str. 732, Code Complete 2nd Edition, Steve McConnell]

Jeśli używasz systemu współbieżnych wersji do śledzenia zmian w kodzie - nie mieszaj zmian formatowania kodu ze zmianami funkcji logicznych / dodawanych w ramach tego samego zatwierdzenia.

Utrudni to dostrzeżenie zmian i spowoduje niepotrzebne konflikty scalania, jeśli inni członkowie zespołu będą edytować plik. Jeśli musisz wprowadzić zmiany formatowania, sprawdź, czy inni członkowie zespołu nie pracują nad tym plikiem. [Parafrazowane, str. 93, Pragmatyczna kontrola wersji za pomocą Subversion, wydanie drugie]

Również Martin Fowler mówi o „noszeniu dwóch czapek” i przełączaniu się między nimi w ciągu dnia. Jeden kapelusz do dodawania funkcji, jeden kapelusz do refaktoryzacji.

1. Zastanawiasz się nad dodaniem nowej funkcji (Feature Hat)
2. Sprawdzasz istniejący kod, aby uzyskać zrozumienie, sprzątając w miarę postępów. (Refaktoryzacja)
3. Zatwierdź zmiany.
4. Dodaj funkcję. (Feature Hat) i tak dalej ....

[Parafrazowane str. 57ish, Refaktoryzacja, Martin Fowler]

Więc nie marnuj godzin, próbując upiększać całą bazę kodu. Wystarczy, że dodasz wystarczającą ilość kodu, aby dodać następną funkcję.

W skrócie ... zostaw każdy fragment kodu w ładniejszym stanie niż w momencie pierwszego przybycia.

Jeśli jest to tylko formatowanie, prawdopodobnie lepiej poświęcić trochę czasu na nauczenie ładnej drukarki, jak chcesz sformatować kod. Jest to dość kosztowne z góry, ale wyobrażam sobie, że odzyskasz ten zegar w 2-3 zastosowaniach.

Jeśli to jest faktyczne refaktoryzacja, być może nie. Koncepcyjnie czysty kod ma tendencję do łatwiejszej modyfikacji w przyszłości, a „zawsze czyste” zmniejsza pokusę przepuszczenia czegoś tylko dlatego, że wokół jest inny śmierdzący kod.

To trochę pomaga, ale nie warto poświęcać temu dużo czasu. Upewnij się także, że twoje ulepszenia dodają również zakres zmiennych, RAII, kopiowanie grupowe / wklejanie kodu itp. Jeśli to wszystko zrobisz, staje się 1000 razy łatwiejsze, gdy musisz zrozumieć, co robi kod po około roku.

Powinieneś stworzyć czysty kod, ale nie powinno to zająć godzin.

W przypadku C istnieje gnu-program gnu-indent gnu-indent , w zaćmieniu jest przynajmniej formatforma dla Javy i myślę, że istnieją narzędzia dla większości innych języków. Powinno być kilka kliknięć, aby wcięcie pliku było prawidłowe, i kilka minut, jeśli chcesz naruszyć reguły w określonych celach - tak jak w przypadku krótkich instrukcji case-switch:

 switch (foo) {
      case a:  foo (a);             break; 
      case b:  foob ();             break;
      case c:  /* intent. empty */
      case d:  foocd ();            break; 
      default: allPrettyAligned (); break; 
 }

co jest trudne do określenia.

Jeśli uważasz, że coś wygląda czysto, przeglądając go, koncentrujesz się na czymś powierzchownym, co można zautomatyzować.

Przeczytaj ten klasyczny artykuł na temat „Sprawiania, że ​​zły kod wygląda źle”, a zobaczysz, dlaczego ludzie często myślą, że wcięcie (które można wykonać automatycznie) jest banalne:

http://www.joelonsoftware.com/articles/Wrong.html

W szczególności ta lista:

OK, do tej pory wspominałem o trzech poziomach osiągnięć jako programista:

1. Nie znasz czystego od nieczystego.

2) Masz powierzchowną ideę czystości, głównie na poziomie zgodności z konwencjami kodowania.

3) Zaczynasz wyczuwać subtelne ślady nieczystości pod powierzchnią, a one robią ci błąd, aby wyciągnąć rękę i naprawić kod.

Jest jednak jeszcze wyższy poziom, o którym naprawdę chcę rozmawiać:

4 Celowo projektujesz swój kod w taki sposób, aby twój nos z powodu nieczystości zwiększał prawdopodobieństwo poprawności kodu.

To jest prawdziwa sztuka: tworzenie solidnego kodu poprzez dosłowne wymyślanie konwencji, dzięki którym błędy wyróżniają się na ekranie.

"Godziny"? Cóż, powiedziałbym, że twoja odpowiedź brzmi „i”, nie „lub”: tak, cierpisz na zaburzenia obsesyjno-kompulsyjne, ale ma to pewne zalety.

Prawdopodobnie.

Czy ułatwia to szybki odczyt kodu? Czy ułatwia to przeglądanie, ustalanie, co się kończy i gdzie zaczyna, aby znaleźć funkcje, zmienne itp.? Czy to sprawia, że ​​kod działa lepiej? Czy proces upiększania zmusza cię do ponownego rozpatrzenia niektórych decyzji projektowych i przycinania martwego kodu lub usuwania częściowo wypalonych rozwiązań, które ostatecznie porzuciłeś? Jeśli tak, to absolutnie ma wartość.

Z drugiej strony, jeśli wymyśliłeś przewrotny sposób odwoływania się do własnego poczucia estetyki bez faktycznego ułatwiania pracy z kodem, to tak, to wielka strata czasu.

Jeśli chodzi o mnie, mam skłonność do tego, by samemu upaść na koniec OCD - ale nie przestanę. Udostępnianie dokumentacji dla klasy lub funkcji zmusza mnie do myślenia o tym, jak to naprawdę działa - piszę to, aby w końcu ktoś, kto nie jest mną, mógł to zrozumieć. A jeśli rzucę się na kilka ostrzeżeń, ostrzeżeń i przeprosin za to, że kod działa tak, jak działa, to dość mocne ostrzeżenie, że potrzebuje jeszcze jednej rundy poprawek, zanim ogłosi, że jest skończony.

Po pierwsze, nic złego w upiększaniu kodu, ponieważ w końcu chcesz być dumny z tworzenia i prezentacji / formatowania kodu.

Byłbym jednak ostrożny, aby nie przeskalować kodu ze względu na współpracowników lub przyszłych programistów. Ładna dla ciebie może nie być dla mnie ładna. :)

Rozpoznajesz problem (zachowanie kompulsywne) i objaw (obsesyjne formatowanie).

Co z przyczyną i lekarstwem?

• Czy pracujesz za dużo godzin?
• Czy jesteś sfrustrowany, znudzony, niespokojny?
• Jakie jest twoje następne zadanie? Czy to coś, czego nie chcesz robić?
• Kiedy ostatnio miałeś wakacje? Awans? Uznanie za osiągnięcie?
• Czy to problem związany z wypaleniem?
• Czy jesteś w marszu śmierci?

Czasami te objawy są znakiem, że nadszedł czas na odważne zmiany lub przejść dalej.

Mimo niższego tytułu książka Yourdona zawiera wiele pomocnych sugestii, a dla wielu organizacji jest całkiem realnym opisem.

http://dev.co.ua/docs/Edward%20Yourdon%20-%20Death%20March.pdf

Wydajesz się dość wnikliwy i myślę, że możesz znać odpowiedź.

Teraz daj sobie pozwolenie na działanie.

Holy Bovine!
Wy, ludzie, nigdy nie słyszeliście o wcięciach?

jest to narzędzie do formatowania kodu, które istnieje już od ponad 20 lat. Ma mnóstwo wiader opcji, dzięki czemu kod można sformatować w dowolnym momencie, automatycznie.

ermm - ale działa tylko na C i na niektórych, ale nie na wszystkich C ++ .... (wtf? dlaczego GNU go nie aktualizuje?)