Существуют ли какие-либо приемы в программировании, которые вы считаете чрезмерно используемыми (IE использовал их более чрезмерно, чем они должны быть), или злоупотребляли ими, или использовали немного для всего, при этом не являясь действительно хорошим решением многих проблем, которые пытаются предпринять люди решить с этим.

Это могут быть регулярные выражения, какой-то шаблон проектирования или алгоритм или что-то совершенно другое. Может быть, вы думаете, что люди злоупотребляют множественным наследованием и т. Д.

Комментарии в коде

Я просто хотел бы, чтобы преподаватели университета поняли, что им не нужно учить своих студентов писать 10 строк комментариев, в которых говорится, что следующий код является циклом for, повторяющимся от 1 до числа x. Я вижу это в коде!

Научите их сначала писать самодокументируемый код, а затем комментировать то, что не может быть адекватно самодокументируемым. Мир программного обеспечения был бы лучше.

Синглтон дизайн шаблона.

Конечно, это полезный шаблон, но каждый раз, когда новый программист узнает об этом шаблоне, он начинает пытаться применять его в каждом создаваемом им классе.

Самая злая вещь для защиты тупого программирования. ставить все в ловушку и ничего не делать с ловушкой

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

        }

Я вздрагиваю, когда вижу попытку, которая ничего не делает и предназначена для обработки глупой логики. В общем, попробуйте использовать уловы, но в некоторых случаях они очень полезны.

Полагайтесь на StackOverflow, чтобы решать свои проблемы, а не решать их трудным путем.

Новые программисты, которые находят много знаний о SO (слишком часто), пишут, прежде чем думать и пробовать.

В свое время нам приходилось кодировать из книг, ни интернета, ни ТАК. А теперь иди с моей лужайки.

ООП видимо. Это очень ценно, но при неправильном использовании он может довольно легко затенить в противном случае понятный код (на ум приходят некоторые примеры программирования на S4 на R) и может привести к огромным накладным расходам, которые не нужны и могут стоить вам больших затрат на производительность.

Другое дело, что (например, в Perl) ООП часто сводится к написанию одной и той же вещи наоборот: result = $object ->function(pars)вместо result = function(object, pars)этого иногда имеет смысл, но в сочетании с процедурным программированием это может сделать чтение кода довольно запутанным. И кроме того, вы просто вводите больше накладных расходов, когда это не улучшает дизайн. Это также сводится к тому, что сказано о синглтон-паттерне: должен использоваться, но не на всем.

Я сам использую ООП, но в моей области (научных вычислениях) производительность имеет большое значение, и ООП там часто злоупотребляют, так как все студенты в настоящее время получают Java. Это отлично подходит для решения более крупных проблем, для концептуализации и так далее. Но если вы работаете, например, с последовательностями ДНК в BioPerl, использование объектов каждый раз и работа с геттерами и сеттерами может увеличить время расчета в десять раз. Когда ваш код выполняется несколько дней вместо нескольких часов, эта разница действительно имеет значение.

Проведя несколько лет в ASP.NET Webforms, я бы сказал однозначно:

Умный интерфейс

Несмотря на то, что создание веб-форм в виде веб-форм вполне возможно для создания многослойных тестируемых приложений, разработчики слишком легко могут одним щелчком мыши щелкнуть мышью на пути к формам, тесно связанным с их источником данных, а логика приложения замусорена вокруг всего кода пользовательского интерфейса.

Стив Сандерсон объясняет этот анти-паттерн гораздо лучше, чем я, в его книге Pro ASP.NET MVC:

Чтобы создать приложение Smart UI, разработчик сначала создает UI, обычно перетаскивая серию виджетов UI на холст, а затем заполняет код обработчика событий для каждого возможного нажатия кнопки или другого события UI. Вся логика приложения находится в этих обработчиках событий: логика, позволяющая принимать и проверять ввод данных пользователем, осуществлять доступ к данным и их хранение, а также обеспечивать обратную связь путем обновления пользовательского интерфейса. Все приложение состоит из этих обработчиков событий. По сути, это то, что имеет тенденцию выходить по умолчанию, когда вы ставите новичка перед Visual Studio. В этом дизайне нет разделения интересов вообще. Все слито воедино, организовано только с точки зрения различных событий пользовательского интерфейса, которые могут произойти. Когда логика или бизнес-правила должны применяться в более чем одном обработчике, код обычно копируется и вставляется, или определенные случайно выбранные сегменты разлагаются на статические служебные классы. По стольким очевидным причинам этот тип шаблона проектирования часто называют анти-шаблоном.

Я иногда вижу это, и это обычно происходит из-за неполного понимания логических выражений.

if (someCondition == true)

Реализовать основную (или иным образом предоставленную) функциональность, либо из-за незнания ее существования, либо из-за предполагаемой потребности в настройках.

Наследование.

Не навязывайте это там, где это не имеет смысла.

Настройка готового программного обеспечения.

Хотя я могу признать, что это может быть полезно, я действительно задаюсь вопросом, сколько денег тратится на то, чтобы сделать маленькие вещи для сомнительной выгоды. Именно здесь компания может потратить сотни тысяч, если не миллионы долларов, на лицензии для некоторого программного обеспечения, которое затем настраивается, потому что оно настолько настраиваемо, редактируемо и гибко, что по умолчанию оно мало что дает. В конце концов, это пользовательское приложение, потому что весь новый код добавлен к тому, что было куплено изначально.

Использование компилятора в качестве отладчика.

Игнорирование предупреждений компилятора или их полное отключение.

Глобальные переменные.

Все шаблоны дизайна.

Они похожи на соль или сахар. Некоторые из них на вашей еде делают это здорово, многие из них делают вашу еду отстойной.

Не пойми меня неправильно. Шаблоны дизайна - это замечательные приемы. Я использовал их много. Но иногда я нахожу программистов (некоторые из них мои бывшие начальники), у которых были такие «вы должны использовать шаблон проектирования», даже если это не соответствует проблеме !!!

Одним из примеров является «Шаблон посетителя», который больше ориентирован на «Линейные / последовательные коллекции». Мне приходилось работать с древовидной структурой данных, один раз. Чтобы «посетить» каждый предмет, я кодирую не шаблонный метод, а бывший босс настаивает на использовании или адаптации «Шаблонов посетителей». Затем я просматриваю сеть, для второго мнения. Ну, другие программисты имели ту же ситуацию и то же решение. И назовите его «Tree / Hierarchical Visitor Pattern»., Как НОВЫЙ шаблон проектирования

Я надеюсь, что он добавлен как новый шаблон к существующим, в новой версии книги «Шаблоны проектирования».

Использование исключений в качестве управления потоком. Вроде как на этот ответ , но разные.

Поглощение исключений - плохая форма, потому что оно вводит в код загадочные, трудно обнаруживаемые ошибки. Использование исключений в качестве управления потоком, с другой стороны, плохо, потому что это делает код гораздо более неэффективным, чем могло бы быть, и является концептуально неаккуратным.

Обработка исключений должна использоваться только для обработки действительно необычных (непредсказуемых), непредвиденных сценариев, а не таких вещей, как пользователь, набирающий алфавитный символ там, где ожидается число. Такое злоупотребление исключениями чрезвычайно распространено среди плохих программистов в мире Java.

Я собираюсь пойти с негибкостью через чрезмерное сокрытие данных.

Все мы знаем, что абстракция и сокрытие реализации хороши, но больше не всегда лучше. Переусердствовав, вы можете получить негибкий результат, который не справится с изменениями требований. Чтобы обработать это изменение, вам нужно не только изменить класс, который должен обработать это изменение, но также создать способ, с помощью которого информация, в которой он ранее не нуждался, была доступна, несмотря на слои скрытия данных.

Проблема в том, что, как и в случае с поиском правильного баланса для каждого контекста, требуется опыт.

Экспонирование внутренних массивов

    public class Data {
    int[] x;

    public void setArray(int[] x) {

        this.x = x;
    }

    public int[] getArray() {

        return x;
    }
}

Согласно http://www.oracle.com/technetwork/java/seccodeguide-139067.html

перед возвратом скопируйте изменяемые объекты, если только вы не собираетесь делиться состоянием

Изменчивое состояние и циклы. Вы почти никогда не нуждаетесь в них, и вы почти всегда получаете лучший код без них.

Например, это берется непосредственно из потока 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

Они оба делают одно и то же. Но я понятия не имею, что они делают. К счастью, вопрос на самом деле объясняет, что они делают, поэтому я смог переписать их следующим образом:

// 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);

Там нет петель и нет изменяемого состояния. Ну, ладно, никаких явных циклов и счетчиков циклов.

Код стал намного короче, намного проще, намного больше похож на описание того, что код должен делать (особенно в случае с Ruby, он почти прямо говорит «группировать вещи по типу»), и гораздо менее подвержен ошибкам. Нет опасности убежать от конца массива, ошибок столба или ошибок «один за другим» с индексами цикла и условиями завершения, потому что нет никаких индексов цикла и условий завершения.

Дразнящий. Он вводит слишком много искусственных требований для чрезмерной развязки в вашем коде, приводит к чрезмерно усиленному коду равиоли и вынуждает дизайн в стиле OO урезать вам горло, когда более процедурный или функциональный дизайн может быть более простым решением вашей проблемы.

За последние два года программисты на Delphi со всего мира узнали, как плохо использовать массивы символов для хранения байтов из-за оптового преобразования Unicode.

И «скоро» мы узнаем, как плохо хранить целые числа в списках, когда мы хотим внести изменения в 64-разрядные.

Свойства. Я знаю, что это противоречиво, но я чувствую, что свойства очень сильно используются в .net.

В чем разница между этими двумя строками?

public string Property { get; set; }

public string Field;

Для разработчика разница: абсолютно ничего. Скомпилированная форма немного отличается, поэтому, если вы пишете библиотеку, и эта библиотека будет обновляться в программах, и вы не сможете перекомпилировать сами программы (например, если вы пишете интерфейс для плагинов, который должен работать в разных версиях вашего программного обеспечения), тогда вы не должны использовать открытые поля, потому что вы не можете заменить их свойствами. В любом другом случае нет абсолютно никакой разницы между использованием поля или авто-свойства без модификаторов.