Які речі миттєво дзвонять дзвіночками тривоги при перегляді коду? [зачинено]

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

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

Почну з легкого:

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

/* Fuck this error */

Зазвичай зустрічається всередині нісенітницького try..catchблоку, він, як правило, привертає мою увагу. Так само, як і /* Not sure what this does, but removing it breaks the build */.

Ще кілька речей:

• Кілька вкладених складних ifвисловлювань
• Спробуйте блокувати блоки, які використовуються для регулярного визначення логічного потоку
• Функції з родовими назвами process, data, change, rework,modify
• Шість-сім різних стилів зміцнення в 100 рядках

Я щойно знайшов:

/* Stupid database */
$conn = null;
while(!$conn) {
    $conn = mysql_connect("localhost", "root", "[pass removed]");
}
/* Finally! */
echo("Connected successfully.");

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

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

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

Код, який намагається показати, наскільки розумний програміст, незважаючи на те, що він не додає реальної цінності:

x ^= y ^= x ^= y;

• 20000 функцій ліній (перебільшення). Будь-яка функція, яка займає більше декількох екранів, потребує повторного факторингу.

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

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

{ Let it Leak, people have good enough computers to cope these days }

Що гірше, що це з комерційної бібліотеки!

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

//Copy the value of y to temp.
temp = y;
//Copy the value of x to y.
y = x;
//Copy the value of temp to x.
x = temp;

Крім того, коментарі щодо коду, які могли бути усунені, дотримувались деяких основних вказівок:

//Set the age of the user to 13.
a = 13;

Код, який створює попередження при компілюванні.

Функції з цифрами в імені замість описових імен , наприклад:

void doSomething()
{
}

void doSomething2()
{
}

Будь ласка, зробіть так, щоб імена функцій щось означали! Якщо doSomething і doSomething2 роблять подібні речі, використовуйте назви функцій, які диференціюють відмінності. Якщо doSomething2 - це вирив функціональності від doSomething, назвіть його для його функціональності.

Чарівні числа чи чарівні струни.

   if (accountBalance>200) { sendInvoice(...); }

   salesPrice *= 0.9;   //apply discount    

   if (invoiceStatus=="Overdue") { reportToCreditAgency(); }

• Можливо, не найгірше, але чітко показує рівень реалізації:

  if(something == true) 

• Якщо мова має конструкцію для циклу або ітератора, то використання циклу while також демонструє рівень розуміння мови виконавцями:

  count = 0; 
  while(count < items.size()){
     do stuff
     count ++; 
  }
  
  for(i = 0; i < items.size(); i++){
    do stuff 
  }
  //Sure this is not terrible but use the language the way it was meant to be used.

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

Те, що я відразу помічаю, - це частота глибоко вкладених блоків коду (якщо є, поки є тощо). Якщо код часто заглиблюється більш ніж на два або три рівні, це ознака проблеми дизайну / логіки. І якщо він пройде, як 8 гнізд у глибину, то краще, щоб він не був розбитий.

Оцінюючи програму студента, я іноді можу сказати у миттєвий стиль. Це миттєві підказки:

• Погане або непослідовне форматування
• Більше двох порожніх рядків поспіль
• Нестандартні або непослідовні угоди про іменування
• Повторний код, чим більше дослівних повторів, тим сильніше попередження
• Те, що має бути простим фрагментом коду, надмірно складне (наприклад, перевірка аргументів, переданих основним, перекрученим способом)

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

Розглядаючи більш досконалий код, це мої інші попередження:

• Наявність багатьох класів Java, які лише "структурують" для зберігання даних. Не має значення, чи поля є державними, чи приватними та користуються геттерами / сеттерами, це все ще не є частиною продуманого дизайну.
• Класи, які мають погані імена, наприклад просто простір імен і не мають справжньої згуртованості в коді
• Посилання на моделі дизайну, які навіть не використовуються в коді
• Порожні обробники виключень без пояснень
• Коли я піднімаю код у Eclipse, сотні жовтих "попереджень" рядок коду, в основному через невикористаний імпорт або змінні

З точки зору стилю я, як правило, не люблю бачити:

• Javadoc коментує, що лише перегукується з кодом

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

Особистий улюблений / домашній улюбленець: ідентифікатори, згенеровані IDE, отримують звинувачення. Якщо TextBox1 є головною і важливою змінною у вашій системі, у вас є ще одна річ, що приходить, перевірити код.

Повністю невикористані змінні , особливо коли змінна має ім'я, подібне до імен змінних, які використовуються.

Дуже багато людей згадували:

//TODO: [something not implemented]

Хоча я хочу, щоб цей матеріал був реалізований, принаймні вони зробили помітку. Я думаю, що гірше:

//TODO: [something that is already implemented]

Тодо нікчемні та заплутані, якщо ви ніколи не намагаєтесь їх зняти!

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

Сполучення в назвах методів:

public void addEmployeeAndUpdatePayrate(...) 


public int getSalaryOrHourlyPay(int Employee) ....

Роз'яснення: Причина, в якій задзвонили сигнали тривоги, полягає в тому, що вона вказує на те, що метод, ймовірно, порушує принцип єдиної відповідальності .

Очевидно пов'язування вихідного коду GPL'd з комерційною програмою із закритим кодом.

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

Мова агностика:

• TODO: not implemented
• int function(...) { return -1; } (те саме, що "не реалізовано")
• Викидання винятку з невиключної причини.
• Неправильне використання або суперечливе використання 0, -1або nullу виняткових повертаються значення.
• Твердження без переконливого коментаря, в якому сказано, чому він ніколи не повинен провалюватися.

Специфічна мова (C ++):

• C ++ Макроси з малих літер.
• Статичні або глобальні змінні C ++.
• Неініціалізовані або невикористані змінні.
• Будь-яке, array newщо, мабуть, не безпечно для RAII.
• Будь-яке використання масиву чи вказівника, які, мабуть, не є безпечними для меж. Сюди входить printf.
• Будь-яке використання неініціалізованої частини масиву.

Microsoft C ++:

• Будь-які імена ідентифікаторів, що стикаються з макросом, уже визначеним будь-яким із файлів заголовка Microsoft SDK.
• Взагалі, будь-яке використання API Win32 є великим джерелом сигналів тривоги. Завжди відкривайте MSDN і завжди шукайте аргументи / визначення повернення значення, коли виникаєте сумніви. (Відредаговано)

Специфічний для C ++ / OOP:

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

Дивний стиль відступу.

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

Використання безлічі текстових блоків, а не перерахунків або глобально визначених змінних.

Не добре:

if (itemType == "Student") { ... }

Краще:

private enum itemTypeEnum {
  Student,
  Teacher
}
if (itemType == itemTypeEnum.Student.ToString()) { ... }

Кращий:

private itemTypeEnum itemType;
...
if (itemType == itemTypeEnum.Student) { ... }

Слабо набрані параметри або повернені значення методів.

public DataTable GetEmployees() {...}

public DateTime getHireDate(DataTable EmployeeInfo) {...}

public void FireEmployee(Object EmployeeObjectOrEmployeeID) {...}

• Кілька потрійних операторів поєднуються разом, тому замість того, щоб нагадувати if...elseблок, він стає if...else if...[...]...elseблоком
• Довгі назви змінних без підкреслень або camelCasing. Приклад із якогось коду я витягнув:$lesseeloginaccountservice
• Сотні рядків коду у файлі, без зауважень, і код дуже неочевидний
• Надмірно складні ifзаяви. Приклад з коду: на if (!($lessee_obj instanceof Lessee && $lessee_obj != NULL))який я наголосивif ($lessee_obj == null)

Запах коду: не дотримання найкращих практик

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

Ось ваш спалах новин для вас: 50% світового населення менше середнього рівня інтелекту. Гаразд, деякі люди мали б точно середній інтелект, але не будемо вибагливі. Крім того, одним із побічних ефектів дурості є те, що ти не можеш розпізнати власну дурість! Речі виглядають не так добре, якщо поєднувати ці твердження.

Які речі миттєво дзвонять дзвіночками тривоги при перегляді коду?

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

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

Одним із прикладів найкращої практики може бути використання фігур з кожним блоком if, навіть якщо він містить лише один рядок:

if (something) {
    // whatever
}

Ви можете не вважати, що це потрібно, але я нещодавно прочитав, що це головне джерело помилок. Завжди використання дужок також обговорювалося в Stack Overflow , і перевірка наявності if-операторів дужок - це також правило в PMD , аналізаторі статичного коду для Java.

Пам'ятайте: "Тому що це найкраща практика" ніколи не є прийнятною відповіддю на питання "чому ти це робиш?" Якщо ви не можете сформулювати, чому щось є найкращою практикою, то це не найкраща практика, це забобони.

Зауваження, які говорять "це тому, що дизайн підсистеми froz повністю захищений".

Це продовжується над цілим абзацом.

Вони пояснюють, що повинен відбутися наступний рефактор.

Але не зробив цього.

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

Якщо керівник вважає, що j.випадково. програміст не може зробити рефакторинг, тоді це повинен зробити керівник.

У будь-якому випадку це трапляється, я знаю, що код був написаний розділеною командою з можливою політикою влади, і вони не рефакторирували конструкції підсистеми.

Правдива історія. Це може статися з вами.

Чи може хтось придумати приклад, коли код повинен законно посилатися на файл за абсолютним шляхом?

Ловля загальних винятків:

try {

 ...

} catch {
}

або

try {

 ...

} catch (Exception ex) {
}

Регіональне використання

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

Конвенції про іменування класів, які демонструють слабке розуміння абстракції, яку вони намагаються створити. Або це зовсім не визначає абстракцію.

Надзвичайний приклад приходить до тями в класі VB, який я бачив одного разу, під назвою якого Dataбуло 30 000+ рядків ... у першому файлі. Це був частковий клас, розбитий щонайменше на півдесятка інших файлів. Більшість методів були обгортками навколо збережених програм з такими іменами FindXByYWithZ().

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

Функції, що повторюють основні функціональні можливості мови. Наприклад, якщо ви коли-небудь бачите метод "getStringLength ()" в JavaScript замість виклику до властивості ".length" рядка, ви знаєте, що у вас виникли проблеми.

#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...

Звичайно, без будь-якої документації та випадкових вкладених #defineс