Nienawidzę jednego z naszych standardów kodowania i doprowadza mnie to do szaleństwa, jak go przetworzyć? [Zamknięte]

Zastrzeżenie : Nie tak przesadzone, jak sugeruje tytuł, ale wciąż sprawia mi to dyskomfort. Zamierzam wyrazić szczerze, więc weź to z odrobiną soli. Udawaj, że mówię o tym standardzie kodowania, z którym nie lubisz pracować.

Edycja : Fakt, że mi się nie podoba, nie oznacza, że ​​go nie używam ani nie egzekwuję.

Postanowiłem zadać to pytanie w duchu, jak przekroczyć standard, który ci się nie podoba, aby nie uzyskać pomocy, jak lepiej argumentować, jak można go zmienić (chociaż docenia się wszelkie komentarze dotyczące tej ostatniej części). Poza tym pracuję w dużej firmie i taka zmiana czegoś, co żyło tak długo i że tak mało się liczy, jest mało prawdopodobna.

Standard to standard otwierający nawiasy klamrowe na linii dedykowanej:

somefunction()
{
    //...
}

Zamiast * wyraźnie lepszego * (zauważ żart / frustrację):

somefunction() {
    //...
}

Moje osobiste argumenty przeciwko standardowi:

• Nadyma kod : dodatkowe niepotrzebne linie
• Trudniej pisać : chociaż prawdopodobnie to tylko ja walczę ze standardem, wiem, że jedno dodatkowe naciśnięcie klawisza nie jest takie złe.
• Niełatwiej czytać : zaczynam czytać deklarację funkcji, instrukcję if lub dowolną inną instrukcję stosu zakresu i już nie muszę szukać nawiasu otwierającego. Zagnieżdżone bloki z tym standardem po prostu denerwują mnie z jakiegoś powodu.
• Używane przez osoby wywodzące się z Microsoft IDE : myślę, że za standardem powinna być uzasadniona (lub więcej) argumentacja, a nie tylko przyjęcie paradygmatu.

Ich argumenty (i mój sposób wewnętrznej retorty):

• Łatwiejszy do odczytania, ponieważ od razu widać, gdzie zaczynają się i kończą bloki : nie rozumiem tego, jaki jest pożytek z bloku, jeśli nie wiesz, do czego należy, więc musisz czytać wstecz.
• Użyłem go w Microsoft IDE i podobało mi się : Uhh ... ok?
• Jest w standardzie : * cringes *

Czy jestem jedyną osobą, która zmaga się z upartym stanowiskiem wobec określonego standardu? Jak sobie z tym poradziłeś? Jakie jest Twoje zdanie na temat tego, jaki powinien być ten konkretny standard (dla zabawy)?

Jeśli chcesz sobie z tym poradzić - cytat Torvaldsa:

Źli programiści martwią się o kod. Dobrzy programiści martwią się strukturami danych i ich relacjami.

Zastanówmy się teraz, gdzie stawiają programiści, którzy martwią się tak drobiazgami, jak styl wzmocnienia wymuszony przez ich standard kodu? Czy twoja baza kodów jest tak nieskazitelna, że ​​jedyne zagadnienie warte czasu, o które warto się kłócić?

Niektórzy ludzie lubią to po swojemu, a inni nie. Tak czy inaczej, ktoś będzie zirytowany. Tym razem jest twoja kolej. Zrób to i zacznij pracę.

Czy standard zespołu jest udokumentowany? Jeśli tak, czy istnieją jakieś powody w przewodniku po stylu? Szczerze mówiąc, musiałem to ssać mnóstwo razy i wykonać prawdziwą pracę. Są jeszcze gorsze problemy, ale czuję, że wciąż jesteś rozdrażniony (przy okazji, zgadzam się z tobą co do stylu).

Co pomogło mi przez to przejść:

1. Zdałem sobie sprawę, że pojedynczy styl ma realne korzyści (bez względu na to, co to jest). A przynajmniej tak myśli grupa ludzi .
2. Dokładnie to, co właśnie zrobiłeś, napisz, dlaczego jest to złe, abyś mógł dobrze argumentować w przyszłości.
3. Użyj narzędzia do stylizacji na miłość boską , to uratuje twoje zdrowie psychiczne. Resharper , CodeMaid , StyleCop , JSLint , Checkstyle , itd ... nawet Visual Studio zrobi to za Ciebie .
4. Skop tyłek temu projektowi i bądź gotowy na następny, kiedy będziesz mógł ustanowić standardy.

Przewaga jednej konwencji nad drugą jest * wyraźnie arbitralna * .

Problemy z czytelnością, które napotkasz, lub Twoi koledzy z drużyny zmierzą się z twoim standardem, są tylko psychologicznym oporem przed zmianami.

Argument obiektywnej czytelności przemawia za * spójnością * całej bazy kodu.

Wróć do czasów, gdy byłeś pewien, że miałeś rację i przez pewien czas zdałeś sobie sprawę, że się myliłeś lub przynajmniej przesadzałeś przez te wszystkie lata temu. Zastanów się nad możliwością ponownego błędu i daj nowy standard kodowania lub czas na przekonanie Cię.

Moje własne standardy szalały, kiedy byłem całkiem nowy w programowaniu (powiedzmy pięć lat w mojej karierze), to czy identyfikatory wielowątkowe powinny być WrittenLikeThisczy written_like_this. Nie powiem nawet, który z nich polubiłem, ale chodzi o to, że po pewnym czasie zmieniłem strony, a po pewnym czasie mnie to nie obchodziło.

Standardowa różnica opisywana za pomocą nawiasów klamrowych jest w dużej mierze arbitralna. Oba sposoby są równie dobre i dla firmy, o ile wszyscy robią to samo, wszystko jest dobre.

„Wyraźnie lepszy”, o którym mówisz, to rodzaj przełożonego, o którym mówią ludzie, gdy mówią o rzeczach „przyzwyczajonych”.

Wkrótce się do tego przyzwyczaisz i za rok, w inny sposób, będzie „wyraźnie lepszy”.

Krótko mówiąc: sobie z tym poradzić.

Ten konkretny temat stanowi Wojnę Religijną między tymi, którzy wolą jeden styl od drugiego. Bardzo niewiele osób jest ambiwalentnych ...

Ostatecznie żadne nie jest dobre i żadne nie jest złe.

Przewodniki po stylach i standardy kodowania istnieją z wielu powodów - a jednym z kluczowych aspektów jest zapewnienie jednolitości układu, co ma na celu zmniejszenie liczby oczywistych błędów i poprawę konserwacji.

Czy jestem jedynym, który zmaga się z upartym stanowiskiem wobec określonego standardu?

Krótka odpowiedź brzmi „nie”, nie jesteś jedyny. Ale są ważniejsze rzeczy, o które należy się martwić. Nawet w standardach, do których się wkładasz, zawsze będzie kompromis - zobacz niektóre aspekty, które doprowadziły do ​​C99 i C12, które nie mają dla mnie sensu.

Nawet MISRA-C (na którą mam bezpośredni wpływ) zawiera przedmioty, z którymi osobiście się nie zgadzam - ale rozumiem, dlaczego inni uważają to za uzasadnienie.

jak sobie z tym poradziłeś?

I na tym polega odpowiedź - zamiast skupiać się na tym, dlaczego osobiście jej się nie podoba, spróbuj zrozumieć, dlaczego osoba / osoby, które się zgodziły, zrobiły to.

Zazwyczaj wprowadza się reguły (w zamykających się drzwiach po tym, jak koń zatrzasnął sposób), aby rozwiązać poprzedni problem. A jeśli reguła jest nadal bezsensowna, porozmawiaj ze standardowym właścicielem i spróbuj je „edukować”.

Myślę, że po prostu musisz sobie z tym poradzić. Postaram się zająć twoimi notatkami własnymi opiniami:

• Nadyma kod

  Jedna dodatkowa linia kodu wcale nie jest rozdęta, chyba że napiszesz 100 metod w jednej klasie, co doda setki dodatkowych linii. Z drugiej strony, jeśli masz setki metod w jednej klasie, to masz zupełnie inny problem.

• Trudniej pisać

  Nie mogę się z tobą więcej nie zgadzać, musisz wcisnąć klawisz powrotu, aby przejść do następnej linii. Co jest trudniejsze do pisania?

• Trudniej czytać

  Wydaje mi się, że każda linia w kodzie powinna mieć określoną funkcję. Następnie musisz zdefiniować nazwę metody w jednym wierszu, a następnie otwieraj i zamykaj nawiasy klamrowe na osobnych wierszach.

• Używany przez osoby pochodzące z MS IDE

  Uhh ..... ok?

Podsumowując, wygląda na to, że podchodzisz do bycia programistą .Net w przeciwieństwie do jakiegokolwiek innego rodzaju programisty, jakby był gorszy, ponieważ używał IDE, który domyślnie przyjmuje ten standard.

Czy jestem jedynym, który zmaga się z upartym stanowiskiem wobec określonego standardu?

Oczywiście nie. Spotkania w celu ustalenia standardów kodowania są okropne! Ciągną się godzinami, a uczestnicy osobiście inwestują w zdobycie swoich ulubionych (i niezmiennie błędnych, z wyjątkiem moich) osobliwości zapisanych w standardzie. Do końca nikt nie jest zadowolony z wyniku. Jeśli coś może być gorsze niż spotkanie standardów kodowania, to formalne spotkania przeglądowe kodu w ciągu kilku miesięcy, które następują po ustaleniu standardu: niektóre osoby próbują przyjąć standard, podczas gdy inne (celowo lub nie) ignorują go, a ty dostajesz godziny informacji zwrotnych, takich jak: W liniach 132, 142, 145, 181, 195 i 221 SillyFileConverter.cpp umieść nawias otwierający na tej samej linii, gdy standard kodowania wyraźnie mówi, że powinien on znajdować się w kolejnej linii!

jak sobie z tym poradziłeś?

Na swój sposób spotkania pomagają. Nawet jeśli całkowicie sympatyzujesz z facetem, który zostawił otwierający nawias klamrowy na tej samej linii co warunek, czy cokolwiek innego, i tak będziesz na niego zirytowany za marnowanie czasu, nie tylko ssąc go i przestrzegając głupiego standardu. Jeśli facet jest curmudgeon i robi to samo w kółko, staje się jeszcze bardziej denerwujący. Zirytowanie takim zachowaniem sprawia, że ​​o wiele łatwiej jest usprawiedliwić pisanie w stylu nieco innym niż to, co wolisz - na pewno nie chcesz być tym facetem .

Nawet jeśli nie poddajesz się niekończącym się formalnym przeglądom kodu, możesz spróbować przejrzeć własny kod specjalnie pod kątem zgodności ze standardem. Nie ma znaczenia, co myślisz o standardzie, po prostu porównujesz to, co napisałeś z tym, co mówi standard. Jeśli odrzucisz się za każdym razem, gdy nie zastosujesz się do zaleceń, może to dostarczyć negatywnych informacji zwrotnych potrzebnych do przyjęcia normy.

Z tego rodzaju rzeczami pamiętam Guliwera w Lilliput. Lilliputianie walczyli w wojnie, której końcem było otwarcie gotowanego jajka. (Oryginalna duża walka endianów, mała walka endianów).

Wykorzystaj to jako okazję do śmiechu z siebie, bo tak naprawdę nie przychodzą wystarczająco często w interesach.

Twój szczególny przykład jest niefortunny, ponieważ niektórzy się z nim zgodzą, a niektórzy nie. Nie zgadzam się na przykład z twoimi argumentami i jestem pewien, że wielu innych, podobnie jak jestem pewien, że wielu innych się z nimi zgodzi. Prawie każe mi myśleć, że pytanie powinno zostać zamknięte, ponieważ jest tak subiektywne.

Jednak pytanie, w jaki sposób postępować ze standardem, z którym się nie zgadzasz, jest bardziej prawdopodobne. Myślę, że odpowiedź brzmi: tam, gdzie istnieją wytyczne dotyczące stylizacji, które zostały uzgodnione i zostały zastosowane, odpowiedzią jest po prostu uśmiechać się, znosić i po prostu sobie z tym poradzić. Pomyśl, że spójność jest ważniejsza. Jeśli wytyczne są niedokładne lub błędne, może istnieć argument za zmianą, ale jest to stylistyczny, więc nie ma tak naprawdę argumentu poza osobistymi preferencjami.

Pochodzę z środowiska Java, więc postępowałem zgodnie ze wspomnianym standardem. Następnie przeniosłem się do C ++ i C #, gdzie używany jest styl, którego nienawidzisz. Ale nie ma dobrej lub złej odpowiedzi. Co ważniejsze, każdy powinien przestrzegać normy. Jeśli standard kodowania jest taki stylistyczny i nie jest wyraźnie zły, wówczas próba argumentowania, że ​​spowoduje tarcie w zespole.

Formater + haczyk do odprawy to dobry początek. Ale to nie wystarczy, ponieważ to, co piszesz, nie jest tak ważne, jak to, na co gapisz się przez cały dzień. W niektórych sytuacjach podejście do trybu Okulary Emacsa - utrzymuj pliki w ich stylu, ale wyświetlaj je bliżej swojego stylu - jest atrakcyjne.

Moje doświadczenie z tym - w obliczu dokładnie tego, dla którego zostało napisane, CamelCapsprzeciwko underscore_separated- było to, że szybko stało się bardziej irytujące niż pomocne, ale przez kilka tygodni wygładziłem moje przejście do (niechętnie) zaakceptowania stylu firmy, a także zapewniłem ujście aby skierować swój gniew („ah, nienawidzę tego, pozwól mi ponownie zmienić ustawienia ... tam przynajmniej coś zrobiłem ”) ;-)

W każdym razie tryb Okulary nie obsługuje umieszczania nawiasów klamrowych, prawdopodobnie nie używasz Emacsa i nie czytasz kodu wyłącznie w swoim edytorze :-(
Ale ostatni punkt to także okazja - jeśli czytasz kod przez większość czasu w oddzielne narzędzie, które możesz zhakować w celu konwersji stylów, nie martwiąc się o hałas formatowania w obie strony - ponieważ jest to tylko do odczytu! W szczególności, jeśli czytasz kod w niektórych interfejsach sieciowych, użyj Greasemonkey.

Oto kilka łatwiejszych pomysłów na łagodne łagodzenie:

• Wybierz szerszą, ale niezbyt wysoką czcionkę, aby odzyskać utracone linie ekranu.

  • Używaj pełnoekranowego częściej, jeśli jest dostępny.

• Skonfiguruj nawiasy klamrowe, które będą wyróżniane subtelnym kolorem (i mniejszą czcionką?), Dzięki czemu będą mniej widoczne niż reszta kodu. Wcięcie powinno wystarczyć do czytania, szczególnie. z pustą przestrzenią od {linii ...

• Upewnij się, że Twój redaktor wyróżnia pasujące otwieranie klamry, gdy skończysz }- może trochę pomóc, gdy twoje oczy instynktownie trafią w złe miejsce.

• Re „trudniejszy do wpisania”: pobierz prawdziwy edytor, skonfiguruj go, aby automatycznie otwierał nowy wiersz po naciśnięciu {.

Żyj z tym.

Jest to z pewnością kosmetyk i nie zmienia niczego w zakresie jakości kodu lub produktywności programisty. Nic nie warto zaczynać kłótni.

Dla tego rodzaju standardu kodowania wybrałbym spójność w całej podstawie kodu i czytelność w stosunku do każdego konkretnego (nawet dobrze uzasadnionego) podejścia „religijnego” każdego dnia.

Myślenie o tym jako o demokratycznej decyzji większości członków zespołu w sprawie nie tak ważnego problemu może pomóc ci przezwyciężyć ten problem.

To standard:

http://doh-san.blogspot.com/2005/10/five-monkeys.html

Większość z tych, którzy mówią „to standard”, kieruje się zasadą „pięciu małp”.

Po prostu idź dalej i używaj stylu, który chcesz. Następnie użyj programu do upiększania kodu, aby zmienić kod w standardowym formacie, lub popraw własną małą aplikację, która przekonwertuje kod ze Twojego stylu na podany styl standardowy. Użyj beautifier przed wpisaniem kodu.
Możesz także wykonać odwrotną czynność, aby zmienić kod wpisany ze standardowego formatu na format podczas pracy nad nim.