Czy są jakieś techniki programowania, które okażą się nadużywane (IE są używane o wiele bardziej niż powinny) lub nadużywane, lub używane trochę do wszystkiego, nie będąc jednocześnie dobrym rozwiązaniem wielu problemów, które ludzie próbują rozwiązać z tym.

Mogą to być wyrażenia regularne, jakiś wzorzec projektowy, a może algorytm lub coś zupełnie innego. Może uważasz, że ludzie nadużywają wielokrotnego dziedziczenia itp.

Komentarze w kodzie

Chciałbym tylko, żeby profesorowie uniwersyteccy zrozumieli, że nie muszą uczyć swoich studentów pisania 10 wierszy komentarzy stwierdzających, że poniższy kod jest pętlą for, iterującą od 1 do liczby x. Widzę to w kodzie!

Naucz je, jak najpierw napisać kod samokontrujący, a następnie odpowiednio komentować to, co nie może być odpowiednio samo-dokumentujące. Świat oprogramowania byłby lepszym miejscem.

Wzór singletonu.

Oczywiście, jest to użyteczny wzorzec, ale za każdym razem, gdy nowy programista dowiaduje się o tym wzorcu, zaczyna próbować zastosować go do każdej tworzonej przez siebie klasy.

Najbardziej zła rzecz, aby chronić głupie programowanie. próbując złapać wszystko i nic nie robiąc z chwytem

        try
        {
            int total = 1;
            int avg = 0;
            var answer = total/avg;
        }
        catch (Exception)
        {

        }

Drżę, gdy widzę próbę złapania, która nic nie robi i jest zaprojektowana do obsługi głupiej logiki. Zasadniczo połowy próbne są nadmiernie wykorzystywane, jednak w niektórych przypadkach są bardzo przydatne.

Zaufaj StackOverflow, aby rozwiązać swoje problemy, zamiast rozwiązywać problemy.

Nowi programiści, którzy (zbyt często) znajdują bogactwo wiedzy na temat SO, zanim zaczną myśleć i wypróbowywać różne rzeczy.

W moich czasach musieliśmy kodować z książek, bez internetu, bez SO. A teraz zejdź z mojego trawnika.

Oczywiście OOP. Jest bardzo cenny, ale w przypadku niewłaściwego użycia może całkiem łatwo ukryć czysty kod (niektóre przykłady programowania S4 w R przychodzą na myśl), i może powodować ogromny narzut, który jest niepotrzebny i może kosztować dużo czasu na wydajność.

Inną rzeczą jest to, że (np. Perl) OOP często sprowadza się do pisania tego samego na odwrót: result = $object ->function(pars)zamiast result = function(object, pars)To czasami ma sens, ale w połączeniu z programowaniem proceduralnym może powodować, że czytanie kodu jest dość mylące. Poza tym po prostu wprowadzasz więcej kosztów ogólnych tam, gdzie nie poprawia to projektu. Sprowadza się to również do tego, co mówi się o wzorze singletonu: należy go stosować, ale nie we wszystkim.

Sam korzystam z OOP, ale w mojej dziedzinie (obliczenia naukowe) wydajność jest dużą sprawą, a OOP jest często nadużywane, ponieważ wszyscy studenci otrzymują obecnie Javę. Doskonale nadaje się do radzenia sobie z większymi problemami, do konceptualizacji i tak dalej. Ale jeśli pracujesz np. Z sekwencjami DNA w BioPerl, używanie obiektów za każdym razem i konsekwentna praca z modułami pobierającymi i ustawiającymi może dziesięciokrotnie wydłużyć czas obliczeń. Kiedy Twój kod działa kilka dni zamiast kilku godzin, ta różnica naprawdę ma znaczenie.

Spędziłem kilka lat w formularzach internetowych ASP.NET, musiałbym powiedzieć jednoznacznie:

Inteligentny interfejs użytkownika

Chociaż tworzenie formularzy internetowych z możliwością testowania warstwowego jest całkowicie możliwe, Visual Studio ułatwia programistom jednokrotne kliknięcie w celu utworzenia formularzy ściśle powiązanych ze źródłem danych, z logiką aplikacji zaśmieconą wokół całego kodu interfejsu użytkownika.

Steve Sanderson wyjaśnia ten anty-wzór znacznie lepiej niż ja w swojej książce Pro ASP.NET MVC:

Aby zbudować aplikację Smart UI, programista najpierw tworzy interfejs użytkownika, zwykle przeciągając serię widgetów interfejsu użytkownika na obszar roboczy, a następnie wypełnia kod obsługi zdarzeń dla każdego możliwego kliknięcia przycisku lub innego zdarzenia interfejsu użytkownika. Cała logika aplikacji znajduje się w tych procedurach obsługi zdarzeń: logika do akceptowania i sprawdzania poprawności danych wejściowych użytkownika, wykonywania dostępu do danych i ich przechowywania oraz przekazywania opinii poprzez aktualizację interfejsu użytkownika. Cała aplikacja składa się z tych programów obsługi zdarzeń. Zasadniczo właśnie to wydaje się domyślnie, gdy umieścisz nowicjusza przed Visual Studio. W tym projekcie nie ma oddzielenia problemów. Wszystko jest połączone, ułożone tylko pod względem różnych zdarzeń interfejsu użytkownika, które mogą wystąpić. Gdy reguły logiczne lub biznesowe muszą być stosowane w więcej niż jednym module obsługi, kod jest zwykle kopiowany i wklejany, lub niektóre losowo wybrane segmenty są podzielone na statyczne klasy użyteczności. Z wielu oczywistych powodów ten rodzaj wzoru jest często nazywany anty-wzorem.

Widzę to od czasu do czasu i zwykle wynika to z niepełnego zrozumienia wyrażeń boolowskich.

if (someCondition == true)

Ponowne wdrożenie podstawowej (lub w inny sposób zapewnionej) funkcjonalności, albo z powodu niewiedzy o jej istnieniu, albo z powodu postrzeganej potrzeby dostosowywania.

Dziedzictwo.

Nie egzekwuj, to nie ma sensu.

Dostosowywanie gotowego oprogramowania.

Chociaż mogę przyznać, że może to być przydatne, zastanawiam się, ile pieniędzy wydaje się na drobiazgi w celu uzyskania wątpliwych korzyści. W tym miejscu firma może wydawać setki tysięcy, jeśli nie miliony dolarów na licencje na niektóre oprogramowanie, które następnie dostosowuje się, ponieważ jest tak konfigurowalne, edytowalne i elastyczne, że tak naprawdę nie robi wiele domyślnie. Ostatecznie jest to aplikacja niestandardowa, ponieważ cały nowy kod dodaje to, co pierwotnie kupiono.

Używanie kompilatora jako debuggera.

Ignorowanie ostrzeżeń użytkownika lub wyłączenie ich całkowicie.

Zmienne globalne.

Wszystkie wzory projektowe.

Są jak sól lub cukier. Niektóre z nich sprawiają, że jest to świetne, wiele z nich sprawia, że ​​jedzenie jest do kitu.

Nie zrozum mnie źle. Wzory projektowe to wspaniałe techniki. Często ich używałem. Ale czasami znajduję programistów (niektórzy z nich byli moi szefowie), którzy mieli takie „musisz użyć wzorca projektowego”, nawet jeśli nie pasuje to do problemu !!!

Jednym z przykładów jest „Wzorzec gościa”, który jest bardziej ukierunkowany na „Kolekcje liniowe / sekwencyjne”. Raz musiałem pracować ze strukturą danych drzewa. Aby „odwiedzić” każdy element, koduję metodę wzoru innego niż projektowy, a były szef nalega na użycie lub dostosowanie „Wzorca gościa”. Następnie przeglądam sieć w celu uzyskania drugiej opinii. Cóż, inni programiści mieli tę samą sytuację i to samo rozwiązanie. I nazwij to „Drzewnym / Hierarchicznym Wzorem Odwiedzającym”, jako NOWY Wzorzec Projektu

Mam nadzieję, że został dodany jako nowy wzór do istniejących, w nowej wersji książki „Wzory projektowe”.

Wykorzystanie wyjątków jako kontroli przepływu. Trochę podobne do tej odpowiedzi , ale różne.

Przełykanie wyjątków jest złą formą, ponieważ wprowadza tajemnicze, trudne do znalezienia błędy w kodzie. Z drugiej strony stosowanie wyjątków jako kontroli przepływu jest złe, ponieważ powoduje, że kod jest znacznie bardziej nieefektywny niż mógłby być i jest koncepcyjnie niechlujny.

Obsługa wyjątków powinna być wykorzystywana tylko do obsługi naprawdę wyjątkowych (duh), nieprzewidzianych scenariuszy, a nie do rzeczy takich jak użytkownik wpisujący alfabet, gdzie oczekiwana jest liczba. Ten rodzaj nadużywania wyjątków jest niezwykle powszechny wśród złych programistów w świecie Java.

Idę z nieelastycznością poprzez nadmierne ukrywanie danych.

Wszyscy wiemy, że abstrakcja i ukrywanie implementacji są dobre, ale więcej nie zawsze jest lepsze. Przesadzone, możesz uzyskać nieelastyczny wynik, który nie poradzi sobie ze zmianami wymagań. Aby poradzić sobie ze zmianą, musisz nie tylko zmodyfikować klasę, która musi poradzić sobie z tą zmianą, ale także stworzyć sposób, aby informacje, które nigdy wcześniej nie były potrzebne, były dostępne pomimo warstw ukrywania danych.

Problem polega na tym, że podobnie jak w przypadku wszystkich problemów związanych ze znalezieniem właściwej równowagi dla każdego kontekstu, potrzeba doświadczenia.

Odsłanianie wewnętrznych tablic

    public class Data {
    int[] x;

    public void setArray(int[] x) {

        this.x = x;
    }

    public int[] getArray() {

        return x;
    }
}

Według http://www.oracle.com/technetwork/java/seccodeguide-139067.html

kopiuj zmienne obiekty przed powrotem, chyba że intencją jest współużytkowanie stanu.

Zmienny stan i pętle. Prawie nigdy ich nie potrzebujesz i prawie zawsze dostajesz lepszy kod bez nich.

Na przykład jest to pobierane bezpośrednio z wątku StackOverflow:

// ECMAScript
var thing, things_by_type = {};
for (var i = 0; i < things.length; i++) {
    thing = things[i];
    if(things_by_type[thing.type]) {
        things_by_type[thing.type].push(thing);
    } else {
        things_by_type[thing.type] = [thing];
    }
}

# Ruby
things_by_type = {}
things.each do |thing|
  (things_by_type[thing.type] ||= []) << thing
end

Oboje robią to samo. Ale nie mam pojęcia, co oni robią. Na szczęście pytanie faktycznie wyjaśnia, co robią, więc mogłem je przepisać w następujący sposób:

// ECMAScript
things.reduce(function (acc, thing) {
    (acc[thing.type] || (acc[thing.type] = [])).push(thing);
    return acc;
}, {});

# Ruby
things.group_by(&:type)

// Scala
things groupBy(_.type)

// C#
from thing in things group thing by thing.Type // or
things.GroupBy(thing => thing.Type);

Nie ma pętli i nie można zmieniać stanu. No dobrze, bez wyraźnych pętli i liczników pętli.

Kod stał się znacznie krótszy, o wiele prostszy, bardziej podobny do opisu tego, co powinien robić (szczególnie w przypadku Rubiego, prawie bezpośrednio mówi „pogrupuj rzeczy według typu”) i znacznie mniej podatny na błędy. Nie ma niebezpieczeństwa ucieczki z końca tablicy, błędów słupka ogrodzeniowego lub błędów pojedynczych z indeksami pętli i warunkami zakończenia, ponieważ nie ma wskaźników pętli i warunków zakończenia.

Kpić. Wprowadza zbyt wiele sztucznych wymagań dla nadmiernego odsprzęgania w kodzie, prowadzi do nadmiaru kodu ravioli i zmusza projekt w stylu OO do gardła, gdy bardziej proceduralny lub funkcjonalny projekt może być prostszym rozwiązaniem problemu.

Programiści z Delphi na całym świecie odkrywali w ciągu ostatnich dwóch lat, jak źle jest używać tablic znaków do przechowywania bajtów ze względu na hurtową konwersję Unicode

I „wkrótce” dowiemy się, jak źle jest przechowywać liczby całkowite na listach, gdy chcemy zmienić na 64-bitowe.

Nieruchomości. Wiem, że jest to kontrowersyjne, ale uważam, że właściwości .net są znacznie nadużywane.

Jaka jest różnica między tymi dwiema liniami?

public string Property { get; set; }

public string Field;

Dla programisty różnica polega na: absolutnie niczym. Skompilowana forma jest nieco inna, więc jeśli piszesz bibliotekę, a ta biblioteka będzie aktualizowana w programach, a nie możesz ponownie skompilować samych programów (na przykład, jeśli piszesz interfejs dla wtyczek, które powinien działać w różnych wersjach oprogramowania), nie powinieneś używać pól publicznych, ponieważ nie możesz ich zastąpić właściwościami. W każdym innym przypadku nie ma absolutnie żadnej różnicy między użyciem pola lub auto-właściwości bez modyfikatorów.