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

18

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

dukeofgaming
źródło
6
jak długo używasz standardu, którego „nienawidzisz”? i czy stosujesz inne standardy „równolegle”? Mam na myśli, czy to może być kwestia przyzwyczajenia się do tego? Muszę przyznać, że nienawidziłem tego samego standardu, ale po około roku pisania wyłącznie w ten sposób ta nienawiść całkowicie zniknęła
skomentuj
54
Pomijasz wyraźnie wymagane białe spacje między końcem deklaracji funkcji a nawiasami klamrowymi! Musisz spalić!
pap.
5
Żyj z tym. To naprawdę bardzo niewielki problem. Ciesz się, że to jedyna rzecz, która ci przeszkadza. Jeśli zmienisz język, powinieneś być w stanie dostosować się do nowego stylu. Dlatego praca z nim przez kilka tygodni powinna naprawić wrażenie, że to „źle”.
schlingel
8
Used by people who come from a Microsoft IDE backgroundTo nie jest sprawa Microsoftu, np. Jądro Linux i K&R używają tego samego stylu.
Lucas,
5
Jeśli poświęcisz całą swoją energię na szaleństwo na temat tego, co trywialne, nie pozostanie ci nic na rzeczy, które naprawdę mają znaczenie.
Blrfl

Odpowiedzi:

47

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ć?

scrwtp
źródło
2
Zgadzam się całkowicie. Jeśli rozwiązałeś wszystkie pozostałe problemy i decydujesz, gdzie umieścić loki, najważniejszą rzeczą pozostaje, radzisz sobie lepiej niż każdy inny projekt oprogramowania.
4
Czy twoja baza kodów jest tak nieskazitelna, że ​​jedyne zagadnienie warte czasu, o które warto się kłócić? - To byłoby pytanie retoryczne - taka baza kodów nigdy nie istniała w historii!
MattDavey,
12
Chciałbym dodać, że Linus oszalał, jeśli sformatujesz wiadomości git commit „niepoprawnie” wired.com/wiredenterprise/2012/05/torvalds_github
Giles Roberts
To dlatego, że komentował fakt, że bierzesz udział w projekcie, szanujesz przewodnik po stylu projektu i wysyłasz propozycje jego zmiany ... w przeciwnym razie trzymaj się ich stylu!
Rudolf Olah
1
@GilesRoberts: Linus oszalał, jeśli sformatujesz wiadomości git commit „niepoprawnie”, ponieważ nie działa z ustalonym procesem sprawdzania. Ten, który sprawdza się w projekcie od 20 lat i angażuje setki osób. Niektóre reguły procesów są znacznie ważniejsze niż reguły formatowania kodu.
Jan Hudec
66

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

Cromulent
źródło
5
Myślę, że pyta, jak powinien się z tym pogodzić. Co właściwie jest zupełnie innym pytaniem.
Zachary Yates
18
Nieprzestrzeganie normy stwarza poważniejszy problem i denerwuje wszystkich . Rzeczywiście „ssać”!
Frank Shearar
2
Zgadzam się. Musisz sobie z tym poradzić.
Cody,
3
Szczerze mówiąc, to też mnie frustruje, ale niestety „wyssać to” jest właściwą odpowiedzią.
Sulthan
27

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.
Zachary Yates
źródło
7
+1 za (3), punkty bonusowe, jeśli ustawisz go jako hak po pociągnięciu / przed popchnięciem dla SCM, na którym jesteś.
Martin Green
1
Narzędzia do stylizacji usuwają ten problem i sprawiają, że ludzie wkładają pieniądze w usta. Jeśli naprawdę looooooove kręcone szelki szczególny sposób, to ty idź zmienić konfigurację do stylizacji, aby to wszystko ciepłe i przytulne dla siebie. W przeciwnym razie zamknij usta, aby uzyskać kod.
Calphool,
16

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.

mouviciel
źródło
„tylko” psychologiczny opór przed zmianą? Odporność na zmiany psychiczne może być dość duża.
Giles Roberts,
8

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.

Kyle Jones
źródło
Tak, jestem rozdarty między like_this i likeThis również. Ostatnio skłaniam się ku stylowi pisanemu małymi literami, jest po prostu bardziej czytelny.
doug65536
1
Oczywiście, teraz utknąłem z likeThis w niektórych projektach. No cóż, konwencje nazewnictwa nie są bardzo ważne w wielkim schemacie rzeczy.
doug65536,
1
Dokładnie. Nie ma znaczenia, w jakiej linii znajduje się nawias otwierający. W najmniejszym stopniu nie ma znaczenia, czy piszesz MultiWordIdentifiers czy multi_word_identifiers. Niezależnie od tego, jaki standard stosuje Twoja firma, skorzystaj z niego, a za kilka miesięcy trudno ci będzie pamiętać, że kiedykolwiek chciałeś to zrobić w inny sposób.
Carson63000,
8

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

Pieter B.
źródło
wyraźnie lepsza odpowiedź
Mawg mówi o przywróceniu Moniki
5

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

Andrzej
źródło
4

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.

stuartmclark
źródło
1
-1 Zgadzam się we wszystkich punktach, ale nie sądzę, aby jakakolwiek opinia na temat poszczególnych punktów była szczególnie pomocna.
Caleb
4

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.

Caleb
źródło
„Zaangażuj się w wysiłki na rzecz standaryzacji języka ... Miej rozsądek, aby jak najszybciej odejść od wysiłku na rzecz standaryzacji języka” - norvig.com/21-days.html
Beni Cherniavsky-Paskin
3

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.

Jaydee
źródło
2

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.

Ognisty smok
źródło
1
Jak stwierdzono w pytaniu, pytanie tak naprawdę nie dotyczy konkretnego standardu, więc twój pierwszy akapit nie jest niemądry.
Caleb
2

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

Beni Cherniavsky-Paskin
źródło
0

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

guillaume31
źródło
-2

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

Zaraz
źródło
1
czy mógłbyś wyjaśnić, jak to odpowiada na pytanie?
komar
Czy to nie jest oczywiste?
Mawg mówi o przywróceniu Moniki
-5

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.

Manoj R.
źródło
2
-1 Pytanie dotyczy tego, jak mogę się z tym pogodzić? , ale twoja rada sprowadza się do tego, aby nie próbować przezwyciężyć, po prostu rób to po swojemu. To nie wydaje się pomocne. Nie jest to również zbyt praktyczne - użycie prettyprintera stwarza możliwość wystąpienia dodatkowych szkód, tzn. Po konwersji do preferowanego formatu iz powrotem wiele linii może nie być dokładnie takich samych, nawet jeśli oznaczają dokładnie to samo. Stwarza to wiele problemów dla osób przeglądających różne wersje, próbujących dowiedzieć się, co naprawdę się zmieniło.
Caleb
@Caleb - Możliwe, że Twoje doświadczenie w korzystaniu z Prettyprinter jest inne. Używamy Atristic Style i nikt nie ma na to żadnych skarg.
Manoj R
9
Każde poważne opracowanie oprogramowania będzie korzystało z systemu kontroli źródła. Wprowadzenie różnic, które nie są ważne, spowoduje problemy i sprawi, że ludzie oglądający różnicę (i) będą denerwowani - lub, co gorsza, spowodują konflikty przy odprawie.
doug65536,