Jakie popularne „najlepsze praktyki” nie zawsze są najlepsze i dlaczego? [Zamknięte]

„Najlepsze praktyki” są wszędzie w naszej branży. Wyszukiwania Google na „Kodowanie najlepszych praktyk” pojawia się prawie 1,5 miliona wyników. Pomysł wydaje się przynosić komfort wielu; postępuj zgodnie z instrukcjami, a wszystko się ułoży.

Kiedy czytam o najlepszych praktykach - na przykład ostatnio czytałem kilka z Clean Code - denerwuję się. Czy to oznacza, że zawsze powinienem stosować tę praktykę? Czy są jakieś warunki? Czy są sytuacje, w których może to nie być dobrą praktyką? Skąd mam wiedzieć, dopóki nie dowiem się więcej o problemie?

Kilka praktyk wymienionych w Clean Code nie zgadzało się ze mną, ale szczerze mówiąc, nie jestem pewien, czy to dlatego, że są potencjalnie złe, czy to tylko moja osobista uprzedzenie. Wiem, że wielu wybitnych ludzi w branży technologicznej wydaje się myśleć, że nie ma najlepszych praktyk , więc przynajmniej moje dokuczliwe wątpliwości umiejscawiają mnie w dobrym towarzystwie.

Liczba najlepszych praktyk, o których czytałem, jest po prostu zbyt duża, by je tutaj wymienić lub zadać indywidualne pytania, dlatego chciałbym sformułować to jako ogólne pytanie:

Które praktyki kodowania, które są powszechnie określane jako „najlepsze praktyki”, mogą być nieoptymalne, a nawet szkodliwe w pewnych okolicznościach? Jakie są te okoliczności i dlaczego sprawiają, że praktyka jest kiepska?

Wolałbym usłyszeć o konkretnych przykładach i doświadczeniach.

Myślę, że trafiłeś w sedno tym stwierdzeniem

Nienawidzę brać rzeczy za dobrą monetę i nie myśleć o nich krytycznie

Ignoruję prawie wszystkie najlepsze praktyki, gdy nie ma wyjaśnienia, dlaczego istnieje

Raymond Chen najlepiej mówi w tym artykule, gdy mówi

Dobra rada ma uzasadnienie, dzięki czemu można stwierdzić, kiedy stanie się złą radą. Jeśli nie rozumiesz, dlaczego coś należy zrobić, wpadłeś w pułapkę programowania kultowego ładunku i będziesz to robić, nawet jeśli nie jest to już konieczne lub nawet staje się szkodliwe.

Równie dobrze może rzucić to w pierścień:

Premature optimization is the root of all evil.

Nie, nie jest.

Pełny cytat:

„Powinniśmy zapomnieć o małej wydajności, powiedzmy w około 97% przypadków: przedwczesna optymalizacja jest źródłem wszelkiego zła. Jednak nie powinniśmy tracić naszych możliwości w tak krytycznych 3%”.

Oznacza to, że korzystasz ze specjalnych, strategicznych ulepszeń wydajności w całym procesie projektowania. Oznacza to, że korzystasz ze struktur danych i algorytmów zgodnych z celami dotyczącymi wydajności. Oznacza to, że zdajesz sobie sprawę z rozważań projektowych mających wpływ na wydajność. Ale oznacza to również, że nie frywolna optymalizacja, gdy to zrobi, da ci niewielkie korzyści kosztem utrzymania.

Aplikacje muszą być dobrze zaprojektowane, aby nie spadały na końcu, gdy nałożysz na nie trochę obciążenia, a potem skończysz je przepisywać. Niebezpieczeństwo związane ze skróconym cytatem polega na tym, że zbyt często programiści używają go jako wymówki, aby w ogóle nie myśleć o wydajności do końca, kiedy może być za późno, aby cokolwiek z tym zrobić. Lepiej jest budować w dobrej wydajności od samego początku, pod warunkiem, że nie skupiasz się na drobiazgach.

Załóżmy, że budujesz aplikację w czasie rzeczywistym na systemie wbudowanym. Wybierasz Python jako język programowania, ponieważ „Optymalizacja przedwczesna jest źródłem wszelkiego zła”. Teraz nie mam nic przeciwko Pythonowi, ale jest to język interpretowany. Jeśli moc przetwarzania jest ograniczona, a pewna ilość pracy musi być wykonana w czasie rzeczywistym lub prawie w czasie rzeczywistym, a ty wybierasz język, który wymaga większej mocy przetwarzania niż masz, jesteś po królewsku wkręcony, ponieważ teraz muszę zacząć od nowa z dobrym językiem.

Jeden zwrot na funkcję / metodę.

Nie wymyślaj na nowo koła to powszechnie stosowany dogmat. Jego idea polega na tym, że jeśli istnieje odpowiednie rozwiązanie, użyj go zamiast tworzyć własne; oprócz oszczędności, istniejące rozwiązanie jest prawdopodobnie lepiej wdrożone (wolne od błędów, wydajne, przetestowane) niż to, co początkowo wymyślisz. Na razie w porządku.

Problem polega na tym, że rzadko istnieje 100% odpowiednie rozwiązanie. Może istnieć 80% odpowiednie rozwiązanie i prawdopodobnie jest w porządku. Ale w jaki sposób około 60% jest odpowiednie? 40%? Gdzie rysujesz linię? Jeśli nie narysujesz linii, możesz w końcu włączyć do projektu rozdętą bibliotekę, ponieważ używasz 10% jej funkcji - tylko dlatego, że chcesz uniknąć „ponownego wynalezienia koła”.

Jeśli wymyślisz koło na nowo, otrzymasz dokładnie to, czego chcesz. Dowiesz się również, jak robić koła. Uczenie się poprzez działanie nie powinno być niedoceniane. Ostatecznie niestandardowe koło może być lepsze niż standardowe koło standardowe.

„Testuj wszystko”.

Słyszałem, jak często mówiono, że cały kod powinien zawierać testy jednostkowe, z czym się nie zgadzam. Jeśli masz test dla metody, wszelkie zmiany danych wyjściowych lub struktury tej metody muszą zostać wprowadzone dwukrotnie (raz w kodzie, raz w teście).

Jako takie, testy jednostkowe powinny moim zdaniem być proporcjonalne do stabilności strukturalnej kodu. Jeśli piszę system warstwowy od podstaw, moja warstwa dostępu do danych przetestuje wazoo; moja warstwa logiki biznesowej będzie dość dobrze przetestowana, moja warstwa prezentacji będzie miała kilka testów, a moje widoki będą miały niewiele lub nie będzie żadnych testów.

Zawsze programuj do interfejsów.

Czasami będzie tylko jedna implementacja. Jeśli opóźnimy proces wyodrębniania interfejsu do czasu, gdy zauważymy jego potrzebę, często stwierdzimy, że nie jest to konieczne.

Nie używaj żadnych programów typu open source (lub innych firm niż Microsoft dla programistów .NET)

Jeśli Microsoft go nie opracował - nie używamy go tutaj. Chcesz użyć ORM - EF, chcesz użyć IOC - Unity, chcesz się zalogować - blok aplikacji do rejestrowania w przedsiębiorstwie. Istnieje wiele lepszych bibliotek - a jednak zawsze utknąłem przy zamówieniach z menu dolara świata programistów. Przysięgam, że za każdym razem, gdy słyszę najlepsze praktyki firmy Microsoft, myślę „Wytyczne żywieniowe McDonalda”. Pewnie, będziesz żył, jeśli będziesz ich przestrzegać, ale będziesz także niedożywiony i z nadwagą.

• Pamiętaj, że to może nie być twoja najlepsza praktyka, ale jest to powszechna praktyka stosowana niemal wszędzie, gdzie pracowałem.

Orientacja obiektowa

Istnieje założenie, ponieważ kod jest „obiektowy”, jest magicznie dobry. Ludzie dzielą funkcjonalność na klasy i metody, aby być zorientowanym obiektowo.

Cały kod należy skomentować.

Nie powinno tak być. Kiedyś masz oczywisty kod, na przykład seterów nie należy komentować, dopóki nie zrobią czegoś specjalnego. Ponadto, dlaczego powinienem to komentować:

/** hey you, if didn't get, it's logger. */
private static Logger logger = LoggerFactory.getLogger(MyClass.class);

Metodologie, szczególnie scrum. Nie mogę zachować prostej twarzy, gdy słyszę, że dorośli używają frazy „Scrum Master”. Jestem tak zmęczony słyszeniem protestów programistów, że jakiś aspekt Metodologii X nie działa w ich firmie, ale Guru So-and-So informuje go, że powodem, dla którego nie działa, jest fakt, że nie są oni prawdziwymi praktykami Metodologii X. „Scrum mocniej, musisz, mój uczeń Padawan!”

W zwinnych metodologiach są bryłki mądrości --- wiele z nich --- ale często są one osadzone w takiej ilości nawozu, że nie mogę walczyć z odruchem wymiotnym. Weź to ze strony scrum Wikipedii :

Wiele ról jest zdefiniowanych w Scrumie. Wszystkie role dzielą się na dwie odrębne grupy - świnie i kury - w zależności od charakteru ich zaangażowania w proces rozwoju.

Naprawdę? Świnie i kurczaki, mówisz? Fascynujący! Nie mogę się doczekać, aby przekazać ten mój szefowi ...

Object Relational Mapping ... http://en.wikipedia.org/wiki/Object-relational_mapping

Nie chcę nigdy abstrahować od moich danych, ani nie chcę stracić tej precyzyjnej kontroli i optymalizacji. Moje doświadczenie z tymi systemami było bardzo słabe ... Zapytania generowane przez te warstwy abstrakcji są jeszcze gorsze niż to, co widziałem podczas offshoringu.

Pisanie nazw funkcji tak, jakby były angielskimi zdaniami:

Draw_Foo()
Write_Foo()
Create_Foo()

itp. Może to wyglądać świetnie, ale nauka interfejsu API jest uciążliwa. O ile łatwiej jest wyszukać indeks „Wszystko, co zaczyna się od Foo”?

Foo_Draw()
Foo_Write()
Foo_Create()

itp.

MVC - często stwierdzam, że przy wielu problemach z projektowaniem stron internetowych w podejściu MVC chodzi bardziej o to, aby uczynić ramę (szyny itp.) Szczęśliwymi niż o prostotę lub strukturę. MVC jest ulubieńcem „astronautów architektury”, którzy wydają się cenić nadmierne rusztowania nad prostotą. ymmv.

oparty na klasach OO - moim zdaniem sprzyja złożonym strukturom stanu zmiennego. jedynymi przekonującymi przypadkami, które znalazłem na przestrzeni lat w oparciu o klasy OO, są banalne przykłady „kształt-> prostokąt-> kwadrat”, które tworzą rozdział 1 dowolnej książki OO

YAGNI

( Nie będziesz go potrzebował )

To podejście kosztowało mnie wiele godzin, kiedy musiałem zaimplementować funkcje w istniejącej bazie kodu, gdzie staranne planowanie obejmowałoby te funkcje wcześniej.

Moje pomysły były często odrzucane z powodu YAGNI i przez większość czasu ktoś musiał później zapłacić za tę decyzję.

(Oczywiście można argumentować, że dobrze zaprojektowana baza kodu pozwoli również na dodanie funkcji w późniejszym czasie, ale rzeczywistość jest inna)

Dla SQL

1. Nie używaj wyzwalaczy
2. Zawsze chowaj tabele za widokami

W porządku:

1. Są funkcją, która ma swoje miejsce. Masz wiele ścieżek aktualizacji do tabeli lub potrzebujesz 100% kontroli?

2. Dlaczego? Zrobiłbym to, gdybym refaktoryzował się, aby utrzymać kontrakt, ale nie wtedy, gdy czytam, że ludzie zmieniają widok, aby pasował do wszelkich zmian na stole

Edytować:

Numer 3: Unikanie * z ISTNIENIEM. Spróbuj 1/0. To działa. Lista kolumn nie jest oceniana zgodnie ze standardem SQL. Str. 191

Wzory projektowe głównie. Są nadmiernie wykorzystywane i niedostatecznie wykorzystywane.

Zasada jednolitej odpowiedzialności

^{(„każda klasa powinna mieć tylko jedną odpowiedzialność; innymi słowy, każda klasa powinna mieć jeden i tylko jeden powód do zmiany”)}

Nie zgadzam się. Myślę, że metoda powinna mieć tylko jeden powód do zmiany, a wszystkie metody w klasie powinny mieć logiczny związek ze sobą , ale sama klasa może faktycznie robić kilka (powiązanych) rzeczy.

Z mojego doświadczenia wynika, że ​​ta zasada zbyt często stosuje się zbyt gorliwie, co kończy się wieloma drobnymi klasami opartymi na jednej metodzie. Zrobiły to oba zwinne sklepy, w których pracowałem.

Wyobraź sobie, że twórcy interfejsu API .Net mieli taką mentalność: zamiast List.Sort (), List.Reverse (), List.Find () itp. Mielibyśmy klasy ListSorter, ListReverser i ListSearcher!

Zamiast sprzeczać się już z SRP (co samo w sobie nie jest okropne) , podzielę się kilkoma moimi odwiecznymi anegdotycznymi doświadczeniami:

W jednym miejscu, w którym pracowałem, napisałem bardzo prosty solver o maksymalnym przepływie, który składał się z pięciu klas: węzła, wykresu, kreatora grafów, solvera grafów i klasy do używania kreatora grafów / solverów do rozwiązywania problem w świecie rzeczywistym. Żadna z nich nie była szczególnie złożona ani długa (solver był zdecydowanie najdłuższy przy ~ 150 liniach). Zdecydowano jednak, że klasy mają zbyt wiele „obowiązków”, więc moi współpracownicy przystąpili do refaktoryzacji kodu. Kiedy skończyli, moje 5 klas zostało poszerzonych do 25 klas, których łączna liczba linii kodu była ponad trzykrotnie większa niż pierwotnie. Przepływ kodu nie był już oczywisty, podobnie jak cel nowych testów jednostkowych; Trudno mi było zrozumieć, co zrobił mój własny kod.

W tym samym miejscu prawie każda klasa miała tylko jedną metodę (jej jedyna „odpowiedzialność”). Postępowanie w ramach programu było prawie niemożliwe, a większość testów jednostkowych polegała na testowaniu tej klasy kodu z innej klasy , których oba cele były dla mnie równie tajemnicą. Były dosłownie setki klas, w których powinno być (IMO) tylko kilkadziesiąt. Każda klasa zrobiła tylko jedną „rzecz” , ale nawet przy konwencjach nazewnictwa, takich jak „AdminUserCreationAttemptorFactory” , trudno było określić związek między klasami.

W innym miejscu (które miało również mentalność klas, które powinny mieć tylko jedną metodę ), próbowaliśmy zoptymalizować metodę, która zajęła 95% czasu podczas pewnej operacji. Po (raczej głupiej) optymalizacji, zwróciłem uwagę na to, dlaczego nazywano to bajillion razy. Został wywołany w pętli w klasie ... której metoda została wywołana w pętli w innej klasie .. która również została wywołana w pętli ..

W sumie pięć poziomów pętli rozłożonych na 13 klas (poważnie). To, co właściwie robiła jedna klasa, było niemożliwe do ustalenia na podstawie samego jej spojrzenia - trzeba było naszkicować mentalny wykres tego, jakie metody wywołał i jakie metody te metody wywołały i tak dalej. Gdyby wszystko zostało połączone w jedną metodę, miałby tylko około 70 linii długości, a nasza metoda problemowa byłaby osadzona w pięciu natychmiast oczywistych poziomach pętli.

Moja prośba o przekształcenie tych 13 klas w jedną klasę została odrzucona.

Teraz, gdy wspomniałeś o Czystym Kodzie, choć zawiera on kilka dobrych pomysłów, myślę, że jego obsesja polegająca na przekształceniu wszystkich metod w metody podrzędne, a także w metody podrzędne, jest zbyt daleko posunięta. Zamiast kilku dziesięcioliniowych metod powinieneś preferować dwadzieścia (podobno dobrze nazwanych) jedno-liniowych. Oczywiście ktoś myśli, że jest czysty, ale dla mnie wydaje się znacznie gorszy niż oryginalna wersja.

Ponadto, zastępując proste elementarne rzeczy, takie jak

0 == memberArray.length

w klasie z wywołaniem własnej metody klasy, takiej jak

isEmpty()

jest wątpliwym „ulepszeniem” IMHO. Dodatek: Różnica polega na tym, że pierwsze sprawdzenie wykonuje dokładnie to, co mówi: sprawdza, czy długość tablicy wynosi 0. Ok, isEmpty()może również sprawdzić długość tablicy. Ale można to również zaimplementować w następujący sposób:

return null != memberArray ? 0 == memberArray.length : true;

Oznacza to, że zawiera ukrytą kontrolę zerową! Może to być dobre zachowanie w przypadku metody publicznej - jeśli tablica jest pusta, to z pewnością coś jest puste - ale kiedy mówimy o wewnętrznych elementach klasy, nie jest tak dobrze. Podczas gdy hermetyzacja na zewnątrz jest koniecznością, elementy wewnętrzne klasy muszą dokładnie wiedzieć, co się dzieje w klasie. Nie można hermetyzować klasy od siebie samej . Jawne jest lepsze niż niejawne.

Nie oznacza to, że przełamywanie długich metod lub logiczne porównania nie są dobre; Oczywiście, że tak, ale w jakim stopniu to zrobić - tam, gdzie jest to najsłodsze miejsce - jest oczywiście kwestią gustu. Złamanie długiej metody skutkuje powstaniem większej liczby metod, co nie przychodzi za darmo. Musisz skakać po kodzie źródłowym, aby zobaczyć, co się naprawdę dzieje, kiedy możesz to zobaczyć na pierwszy rzut oka, jeśli wszystkie te rzeczy są w jednej metodzie.

Chciałbym nawet posunąć się nawet do stwierdzenia, że ​​w niektórych przypadkach metoda 1-liniowa jest zbyt krótka, aby zasłużyć na bycie metodą.

„Bądź liberalny dzięki komentarzom”

Komentarze są zdecydowanie dobre, ale zbyt wiele jest tak samo złych, jeśli nie gorszych niż niewystarczające. Dlaczego? Cóż, ludzie zwykle ignorują komentarze, jeśli widzą zbyt wiele niepotrzebnych. Nie twierdzę, że możesz mieć doskonale samodokumentujący się kod, ale lepiej jest kod, który wymaga komentarza do wyjaśnienia.

GoTo uważany za szkodliwy

Jeśli implementujesz maszynę stanową, instrukcja GOTO może mieć większy sens (czytelność i efektywny kod) niż podejście „programowania strukturalnego”. Naprawdę martwiło to niektórych współpracowników, gdy pierwszy fragment kodu, który napisałem w nowej pracy, zawierał nie tylko jedną, ale kilka instrukcji goto. Na szczęście byli wystarczająco inteligentni, aby zdać sobie sprawę, że w tym konkretnym przypadku było to najlepsze rozwiązanie.

Każda „najlepsza praktyka”, która nie dopuszcza rozsądnych i udokumentowanych wyjątków od jej zasad, jest po prostu przerażająca.

Poświęcamy się, aby kod był testowalny

Przeskakuję przez wiele obręczy, aby mój kod był testowalny, ale nie udaję, że nie zrobiłbym tego, gdyby miał wybór. Często jednak słyszę, jak ludzie popierają pomysł, że są to „najlepsze praktyki”. Praktyki te obejmują (napisane w języku .Net, ale dotyczą również innych języków) :

• Tworzenie interfejsu dla każdej klasy. To podwaja liczbę klas (plików) do czynienia, i kod duplikatów. Tak, programowanie interfejsu jest dobre, ale do tego właśnie służą specyfikatory publiczne / prywatne.
• Każda klasa, która nie została utworzona przy uruchomieniu, potrzebuje fabryki. Oczywiście new MyClass()jest to o wiele prostsze niż pisanie fabryki, ale teraz metody, która ją tworzy, nie można przetestować osobno. Gdyby nie ten fakt, zrobiłbym tylko 1/20 liczby klas fabrycznych, które teraz robię.
• Upublicznij każdą klasę, co przeczy celowi posiadania specyfikatorów dostępu do klas w ogóle. Jednak do klas niepublicznych nie można uzyskać dostępu (a tym samym przetestować) z innych projektów, więc jedyną inną opcją jest przeniesienie całego kodu testowego do tego samego projektu (a zatem zwolnienie go z produktem końcowym).
• Wstrzykiwanie zależności. Najwyraźniej muszę podawać co drugiej klasie, której używam pola i parametru konstruktora, to znacznie więcej pracy niż tylko tworzenie ich, kiedy ich potrzebuję; ale wtedy nie mogę już przetestować tej klasy w izolacji.
• Zasada Jednej Odpowiedzialności, która spowodowała tak wiele bólów głowy, doprowadziłem ją do własnej odpowiedzi .

Co więc możemy zrobić, aby to naprawić? Potrzebowalibyśmy radykalnej zmiany w architekturze językowej:

• Potrzebowalibyśmy umiejętności kpienia z zajęć
• Potrzebowalibyśmy możliwości testowania prywatnych metod klas wewnętrznych z innego projektu (może się to wydawać luką w zabezpieczeniach, ale nie widzę problemu, jeśli testowany jest zmuszony nazwać swoje klasy testerów) .
• Wstrzykiwanie zależności (lub lokalizacja usługi), a także coś równoważnego z naszym istniejącym wzorcem fabrycznym, musiałoby być podstawową częścią języka.

Krótko mówiąc, potrzebujemy języka zaprojektowanego od podstaw z myślą o testowaniu .

Rozdzielanie aplikacji na poziomy; Warstwa danych, warstwa biznesowa, warstwa interfejsu użytkownika

Głównym powodem, dla którego mi się to nie podoba, jest to, że większość miejsc, które stosują tę metodę, używają bardzo kruchych ram, aby to zrobić. Warstwa interfejsu IE jest ręcznie kodowana do obsługi obiektów warstwy biznesowej, obiekty warstwy biznesowej są ręcznie kodowane do obsługi reguł biznesowych i bazy danych, baza danych jest SQL i jest już dość krucha i zarządzana przez grupę „DBA”, która nie lubi zmian.

Dlaczego to takie złe? Najczęstszym żądaniem rozszerzenia jest prawdopodobnie „Potrzebuję pola na ekranie X, które ma Y”. Huk! Masz tylko nową funkcję, która wpływa na każdą warstwę, a jeśli oddzielisz warstwy za pomocą różnych programistów, stało się to dużym problemem z udziałem wielu osób i grup, dla bardzo prostej zmiany.

Ponadto nie wiem, ile razy brałem udział w kłótniach, które dotyczą czegoś takiego. „Pole nazwy jest ograniczone do maksymalnej długości 30, czy jest to warstwa interfejsu użytkownika, warstwa biznesowa lub warstwa danych?” I jest sto argumentów i nie ma właściwej odpowiedzi. Odpowiedź jest taka sama, wpływa na wszystkie warstwy, nie chcesz, aby interfejs użytkownika był głupi i musisz przejść przez wszystkie warstwy i zawieść w bazie danych, tak aby użytkownik odkrył, że jego wpis jest za długi. Jeśli to zmienisz, wpłynie to na wszystkie warstwy itp.

„Warstwy” również mają tendencję do wycieku; Jeśli jakakolwiek warstwa jest fizycznie oddzielona granicami procesu / maszyny (interfejs internetowy IE i logika zaplecza biznesowego), reguły są duplikowane, aby wszystko działało całkiem dobrze. Tzn. Logika biznesowa kończy się w interfejsie użytkownika, nawet jeśli jest to „reguła biznesowa”, ponieważ użytkownik potrzebuje interfejsu użytkownika, aby móc reagować.

Jeśli zastosowana struktura lub zastosowana architektura jest odporna na niewielkie zmiany i wycieki, tj. W oparciu o metadane i jest dynamicznie dostosowywana we wszystkich warstwach, może być mniej bolesna. Ale większość frameworków jest królewskim bólem, wymagającym zmian interfejsu użytkownika, zmian warstwy biznesowej i zmian bazy danych dla każdej drobnej zmiany i powodującym więcej pracy i mniej pomocy niż ta technika powinna przynieść.

Prawdopodobnie zostanę o to zatrzaśnięty, ale oto on :)

JavaBeans

Wykorzystanie JavaBeans w Javie. Zobacz moje pytanie Dlaczego nie powinienem używać niezmiennych POJO zamiast JavaBeans? na StackOverflow.

Historie użytkowników / Przypadki użycia / Personas

Rozumiem ich potrzebę, gdy programujesz dla branży, której nie znasz, ale myślę, że kiedy zostaną wdrożone w pełni, stają się zbyt korporacyjne i tracą czas.

Limity 80 znaków / linii są głupie

Rozumiem, że należy wprowadzić pewne kompromisy, aby dopasować tempo najwolniejszego programu uruchamiającego po stronie GUI (ograniczenia rozdzielczości ekranu itp.), Ale dlaczego ta reguła dotyczy formatowania kodu?

Zobacz ... Był mały wynalazek zwany poziomym paskiem przewijania, który został stworzony w celu zarządzania wirtualnym miejscem na ekranie poza skrajną prawą granicą pikseli. Dlaczego programiści, którym udało się stworzyć świetne narzędzia zwiększające produktywność, takie jak podświetlanie składni i automatyczne uzupełnianie, nie używają go?

Jasne, istnieją edytory CLI religijnie używane przez dinozaury * nix, które przestrzegają starych, zmęczonych ograniczeń terminali VT220, ale dlaczego reszta z nas ma ten sam standard?

Mówię, przykręć limit 80 znaków. Jeśli dinozaury są wystarczająco epickie, aby hakować emacs / vim przez cały dzień, dlaczego nie mogą być w stanie stworzyć rozszerzenia, które automatycznie otacza linie lub daje możliwości przewijania w poziomie ich IDE CLI?

Monitory pikselowe 1920 x 1080 staną się w końcu normą, a programiści na całym świecie nadal będą podlegać tym samym ograniczeniom, nie mając żadnego wpływu na to, dlaczego tak robią, z wyjątkiem tego, że powiedzieli im to starsi, gdy dopiero zaczynali programować.

Limity 80 znaków nie są najlepszą praktyką, ale niszową praktyką dla bardzo mniejszości programistów i powinny być traktowane jako takie.

Edytować:

Jest zrozumiałe, że wielu programistów nie lubi poziomego paska przewijania, ponieważ wymaga gestu myszy, więc ... Dlaczego nie zwiększyć limitu szerokości kolumny do wyższej liczby (niż 80) dla tych z nas, którzy używają nowoczesnych wyświetlaczy.

Kiedy monitory komputerowe 800x600 stały się normą dla większości użytkowników, twórcy stron internetowych zwiększyli szerokość swoich witryn, aby pomieścić większość ... Dlaczego programiści nie mogą zrobić tego samego.

Mierz, mierz, mierz

Tak dobrze, odmierzaj, ale do izolowania błędów wydajności, mierzenia efektów, a także sukcesywnej eliminacji. Oto metoda, której używam.

Próbowałem wyśledzić źródło „mądrości” miary. Powiedział to ktoś z wystarczająco wysokim mydłem, a teraz podróżuje.

Mój nauczyciel wymaga, aby wszystkie moje identyfikatory (bez stałych) zaczynać małymi literami, np myVariable.

Wiem, że wydaje się to drobnostką, ale wiele języków programowania wymaga zmiennych, które zaczynają się od wielkich liter. Cenię sobie spójność, więc moim zwyczajem jest zaczynać wszystko od wielkich liter.

Użyj singletonów

Kiedy powinieneś mieć tylko jedną instancję czegoś. Nie mogę się nie zgodzić . Nigdy nie używaj singletonu i po prostu przydziel go raz i w razie potrzeby omiń wskaźnik / obiekt / referencję. Nie ma absolutnie żadnego powodu, aby tego nie robić.

Używanie unsigned int jako iteratora

Kiedy dowiedzą się, że używanie podpisanego int jest znacznie bezpieczniejsze i mniej podatne na błędy. Dlaczego tak ważne jest, aby indeks tablicy mógł być tylko liczbą dodatnią, aby każdy z przyjemnością przeoczył fakt, że 4-5 to 4294967295?

Metody nie powinny być dłuższe niż pojedynczy ekran

Całkowicie zgadzam się z zasadą jednej odpowiedzialności, ale dlaczego ludzie postrzegają ją jako „funkcję / metodę, która może ponosić tylko jedną odpowiedzialność na najwyższym poziomie logicznej szczegółowości”?

Pomysł jest prosty. Funkcja / metoda powinna wykonać jedno zadanie. Jeśli części tej funkcji / metody można użyć gdzie indziej, należy ją pokroić na własną funkcję / metodę. Jeśli można go użyć w innym miejscu projektu, przenieś go do własnej klasy lub klasy użyteczności i spraw, aby był dostępny wewnętrznie.

Posiadanie klasy zawierającej 27 metod pomocniczych, które są wywoływane tylko raz w kodzie, jest głupie, marnuje miejsce, niepotrzebny wzrost złożoności i ogromny czas. Brzmi bardziej jak dobrą zasadę dla osób, które chcą wyglądać na zajętego refaktoryzacją kodu, ale nie produkują dużo.

Oto moja zasada ...

Napisz funkcje / metody, aby coś osiągnąć

Jeśli masz zamiar skopiować / wkleić jakiś kod, zadaj sobie pytanie, czy lepiej byłoby utworzyć funkcję / metodę dla tego kodu. Jeśli funkcja / metoda jest wywoływana tylko raz w innej funkcji / metodzie, czy naprawdę jest sens, aby mieć ją na pierwszym miejscu (czy będzie ona wywoływana częściej w przyszłości). Czy warto dodawać więcej skoków do / z funkcji / metod podczas debugowania (tj. Czy dodany skok ułatwia lub utrudnia debugowanie)?

Całkowicie się zgadzam, że funkcje / metody większe niż 200 linii wymagają analizy, ale niektóre funkcje wykonują tylko jedno zadanie w tylu liniach i nie zawierają żadnych użytecznych części, które można by wyodrębnić / wykorzystać w pozostałej części projektu.

Patrzę na to z perspektywy deweloperów API ... Gdyby nowy użytkownik spojrzał na diagram klasowy twojego kodu, ile części tego diagramu miałoby sens w większej całości projektu i ile istniałoby wyłącznie jako pomocnicy do innych części wewnętrznych projektu.

Gdybym miał wybierać między dwoma programistami: pierwszy ma tendencję do pisania funkcji / metod, które próbują robić zbyt wiele; drugi łamie każdą część każdej funkcji / metody do najdrobniejszego poziomu szczegółowości; Wybrałbym pierwsze rozdania. Pierwszy osiągnąłby więcej (tj. Napisałby więcej aplikacji), jego kod byłby łatwiejszy do debugowania (ze względu na mniejszą liczbę skoków do funkcji / metod podczas debugowania) i traciłby mniej czasu na pracowitą pracę, doskonaląc jak kod wygląda vs doskonalenie jego działania.

Ogranicz niepotrzebne abstrakcje i nie zanieczyszczaj autouzupełniania.