Чи можна зробити довгий код, який представляє обчислення, простішим для читання?

9

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

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

readability

— Майкл Цанг
джерело

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

— Заломон

Чи підтримує ваш погляд на ORM? Ви можете вилучити (групу) приєднання до перегляду, а потім вибрати його. Навіть якщо його представлення не використовується в іншому місці, це може допомогти розбити великий оператор SQL

— Caleth

Чи підтримує ваш ORM мову запитів у формі SQL? Якщо так, то ви можете перемістити запит до власного файлу та включити виділення синтаксису IDE для нього. У свою програму завантажте запит з файлу. Якщо ваш IDE не підтримує конкретно цю мову запитів, ви можете поєднуватися із форматуванням SQL, хоча це може бути не ідеально. Однак читабельність значною мірою збільшується за рахунок хорошого форматування. Це також має перевагу в тому, що його легко скопіювати запит на скретчпад і зробити там модифікації.

— SpaceTrucker

17

Ви написали

Чи вважається такий важко читається код поганим кодом

тож ви точно погоджуєтесь, що це важко читається код, і якщо його важко читати, його важко підтримувати та розвивати - тому, я думаю, ви вважаєте, що код вважаєте «поганим» своїми власними заходами. Однак іноді не очевидно, як покращити щось на зразок оператора SQL 50 рядків. Легкий "метод вилучення" рефакторинга не працює, і ви, мабуть, не маєте поняття, з чого почати, щоб зробити код більш читабельним. У цих випадках ви все одно можете спробувати одне або всі наведені нижче дії

покажіть код іншому, хто має більш досвідчений досвід, ніж ви прибираєте код. Якщо у вас немає когось у вашій організації, ви можете запитати, спробуйте codereview.stackexchange
спробуйте google для конкретної проблеми. Для вашого прикладу, такі речі, як "очищення довгого заявки sql", можуть стати хорошим початком. Ви будете здивовані, скільки статей ви знайдете на цю тему, і навіть якщо ви не зможете знайти рецепт розуму для вашого випадку, ви можете отримати нові ідеї
замість того, щоб просити виправдання для того, що ви не можете зробити, зосередьтесь на речах, які ви можете зробити, щоб принаймні трохи очистити код, як-от додавання належних розривів рядків, належне відступ, додавання пояснювальних коментарів, покращення деяких змінних назва. Не навряд чи під час цього процесу, змушуючи себе перечитати деталі коду, ви знайдете спосіб перефабрикувати код на менші одиниці
практика, практика, практика. "Чисте кодування" - це не те, чого ви дізнаєтесь за один день, це стає легше з більшим досвідом. Можливо, ви не знайдете рішення своєї проблеми сьогодні, але коли ви повернетесь до коду через кілька місяців, він буде виглядати по-іншому.

— Док Браун
джерело

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

— Вальфрат

@Walfrat: мій намір полягав у наданні загальних рекомендацій щодо процесу, причому не виключно для "50 рядків SQL-коду", а не як "нестандартного" рішення з усіма потенційними підходами.

— Док Браун

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

— Вальфрат

4

Важко читати не погано - зайво важко читати - це погано.

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

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

— gnasher729
джерело

Саме так. Постарайтеся зробити код самостійно документуванням, а потім використовуйте коментарі для заповнення прогалин. (відредаговано: після публікації коментаря я зрозумів, що ОП посилається на запити бази даних ORM, а не на SQL.)

— Kyle A

1

ORM для створення звіту? Серйозно? Дізнайся якийсь SQL, чоловіче. Процедурні мови жахливі при такій речі.

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

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

— Джон Ву
джерело

2

Чесно кажучи, те, що вам не подобаються ORM, абсолютно не має значення для питання.

— Док Браун

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

— Джон Ву

0

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

Якщо вам потрібно зробити багато в одному запиті, спробуйте розділити його на рядки із вбудованими коментарями:

query(join(map(condition1, condition2), blah, blah, something(bah, blah, blah)))

Стає:

// Why are we doing such an awful single query rather than a sequence of selects?
query( // Description of query
  join( // Why are you doing a join here
    map( // Why a map
      condition1, // What is this
      condition2  // And this
   ), // End Map
   blah, // What, Why?
   blah, // What, Why?
   something( // What does this do?
      bah, // What, Why?
      blah, // What, Why?
      blah // What, Why?
      ) // End Something
   ) // End Join
) // End Query

— Стів Барнс
джерело

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

— Тімоті розкладачка

@TimothyTruckle Я погоджуюся, що ідентифікатори повинні чітко визначати, що вони є, але всі вони часто не зрозуміли у звичайному коді - у випадку імен полів запису часто не вистачає ясності через історичні обмеження. Я стикався з випадками, коли були назви полів обмежувалося 5 символами, всі вони мали бути великими літерами ASCII, і їх неможливо було змінити через вимоги сумісності, наприклад, з улюбленим інструментом звітування MD.

— Стів Барнс

0

Окрім відмінної відповіді @ DocBrown, я вважаю, що варто визнати, що ніхто весь час не пише «хорошого» коду. Кодування - це компроміси, і часто краще визнати, що ви написали щось трохи менш чисто, ніж хотілося б, і повертайтеся до цього пізніше. Рефакторинг - це процес вдосконалення коду в часі - і, на мій досвід, саме це і робить хорошу базу коду, а не "вперше правильно".

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

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

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

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

— Невілл Куйт
джерело