Чи є якісь методи в програмуванні, якими ви вважаєтесь надмірно використаними (IE використовується набагато надмірно, ніж вони повинні бути), або зловживали ними, або використовували трохи для всього, хоча вони не є справді хорошим рішенням багатьох проблем, які люди намагаються вирішити вирішити з цим.

Це можуть бути регулярні вирази, якась схема дизайну або, можливо, алгоритм, або щось зовсім інше. Можливо, ви думаєте, що люди зловживають багаторазовою спадщиною тощо.

Коментарі в кодексі

Я просто хочу, щоб викладачі університету розуміли, що їм не потрібно вчити своїх студентів писати 10 рядків коментарів, в яких говориться, що наступний код - це цикл для циклу, який повторюється від 1 до числа x. Я бачу це в коді!

Навчіть їх спочатку писати код самодокументування, а потім відповідне коментування того, що не може бути адекватним самодокументуванням другого. Світ програмного забезпечення був би кращим місцем.

Однотонний шаблон дизайну.

Звичайно, це корисна модель, але щоразу, коли новий програміст дізнається про цей шаблон, він починає намагатися застосовувати його для кожного створеного ним класу.

Найгірше захистити німе програмування. вкладаючи все в спробу лову і нічого не роблячи з уловом

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

        }

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

Покладайтеся на StackOverflow для вирішення своїх проблем, а не роздумуйте про важкий шлях.

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

У мої дні нам доводилося кодувати з книг, ні в Інтернеті, ні в SO. Тепер зійди з моєї галявини.

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

Інша справа, що (наприклад, Perl) OOP часто зводиться писати те ж саме навпаки: result = $object ->function(pars)замість result = function(object, pars)цього іноді має сенс, але при змішуванні з процедурним програмуванням це може зробити читання коду досить заплутаним. І крім цього, ви просто вводите більше накладних витрат там, де це не покращує дизайн. Це зводиться до того, що сказано про однотонну схему: слід використовувати, але не на все.

Я використовую OOP сам, але в моїй галузі (наукові обчислення) продуктивність - це велика справа, і OOP часто зловживають там, оскільки всі студенти зараз отримують Java. Він чудово підходить для вирішення більших проблем, для концептуалізації тощо. Але якщо ви працюєте з, наприклад, послідовностями ДНК у BioPerl, використання об'єктів кожного разу та послідовно працюючи з геттерами та сеттерами може вдвічі збільшити час обчислення. Якщо ваш код працює кілька днів замість кількох годин, ця різниця дійсно має значення.

Провівши кілька років у веб-формах ASP.NET, я б сказав однозначно:

Розумний інтерфейс користувача

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

Стів Сандерсон пояснює цей антидіапазон набагато краще, ніж я міг у своїй книзі Pro ASP.NET MVC:

Щоб створити додаток Smart UI, розробник спочатку створює інтерфейс користувача, як правило, перетягуючи серію віджетів користувальницького інтерфейсу на полотно, а потім заповнює код обробника подій для кожного можливого натискання кнопки чи іншого події інтерфейсу. Вся логіка додатків знаходиться в цих обробниках подій: логіка приймати та перевіряти введення користувача, здійснювати доступ до даних та зберігання даних та надавати зворотній зв'язок шляхом оновлення інтерфейсу користувача. Вся програма складається з цих обробників подій. По суті, це те, що зазвичай виходить за замовчуванням, коли ви ставите новачка перед Visual Studio. У цьому дизайні не існує жодного розділення проблем. Все злито разом, влаштоване лише з точки зору різних подій інтерфейсу, які можуть статися. Коли логіку чи ділові правила потрібно застосовувати у кількох обробниках, код зазвичай копіюється та вставляється, або певні випадково вибрані сегменти враховуються в статичні класи корисності. З такої кількості очевидних причин такий тип дизайну часто називають антидіаграмою.

Я бачу це періодично, і це зазвичай є результатом не повністю розуміння булевих виразів.

if (someCondition == true)

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

Спадщина.

Не примусово виконувати це - де це не має сенсу.

Налаштування програмного забезпечення, що не використовується на постійній основі.

Хоча я можу визнати, що це може бути корисним, але мені цікаво, скільки грошей витрачається на те, щоб зробити дрібниці для сумнівної вигоди. Тут компанія може витратити сотні тисяч, якщо не мільйони доларів на ліцензії на певне програмне забезпечення, яке потім налагоджується, оскільки воно настільки конфігурується, редагується та є гнучким, що воно за замовчуванням не робить багато. Зрештою, це спеціальне додаток, оскільки до всього нового коду додано те, що спочатку було придбано.

Використання complier як налагоджувач.

Ігнорування попереджень про компілятори або їх повне вимкнення.

Глобальні змінні.

Усі шаблони дизайну.

Вони схожі на сіль або цукор. Деякі з них на вашій їжі роблять її чудовою, багато з них робить вашу їжу відстійною.

Не зрозумійте мене неправильно. Шаблони дизайну - чудові прийоми. Я їх багато використовував. Але іноді я знаходжу програмістів (дехто з них моїх колишніх начальників), які мали такі "ти мусиш використовувати схему дизайну", навіть якщо це не відповідає проблемі !!!

Одним із прикладів є "Візерунок відвідувачів", який більше спрямований на "Лінійні / Послідовні колекції". Мені довелося колись працювати зі структурою даних про дерево. Для того, щоб "відвідати" кожен предмет, я кодую недизайнний шаблон, і колишній начальник наполягає на використанні або адаптації "Шаблону відвідувачів". Потім я переглядаю мережу, для другої думки. Що ж, інші програмісти мали таку ж ситуацію і таке ж рішення. І називаємо це "Дерево / Ієрархічний шаблон відвідувачів"., Як НОВА модель дизайну

Я сподіваюся, що його додали як новий зразок до існуючих, у новій версії книги "Шаблони дизайну".

Використання винятків як контролю потоку. Сорт подібний до цієї відповіді , але різний.

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

Поводження з винятками має використовуватися лише для обробки справді виняткових (так), непередбачених сценаріїв, а не для таких випадків, як користувач, що вводить алфавітний символ, де очікується число. Цей вид зловживань винятком надзвичайно поширений серед поганих програмістів у світі 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;

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