Можно ли сделать длинный код, представляющий вычисление, более легким для чтения?

9

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

Считается ли такой трудно читаемый код плохим кодом? Точно так же, если я напишу код для сложного алгоритма, в результате чего будет трудно читаемый код, заключенный в явно названный метод, это плохой код?

Майкл Цанг
источник
Разве вы не можете каким-либо образом параметризировать запрос? Я предполагаю, что этот запрос варьируется в зависимости от того, что происходит внутри метода, который создает. Может быть, вы можете разбить его на более мелкие части и построить в несколько этапов, чтобы было легче читать.
Заломон
Ваш ORM поддерживает представления? Вы можете извлечь (группу) объединение в представление и затем выбрать представление. Даже если это представление не используется в другом месте, это может помочь разбить большой оператор SQL
Caleth
Поддерживает ли ваш ORM SQL-подобный язык запросов? Если да, то вы можете переместить запрос в его собственный файл и включить для него подсветку синтаксиса IDE. В вашем приложении загрузите запрос из файла. Если ваша среда IDE не поддерживает этот конкретный язык запросов, вы можете справиться с форматированием SQL, даже если это не идеально. Однако читаемость в значительной степени повышается благодаря хорошему форматированию. Это также имеет то преимущество, что его легко скопировать запрос в блокнот и внести изменения там.
SpaceTrucker

Ответы:

17

Вы написали

Является ли такой трудно читаемый код плохим кодом?

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

  • покажи код кому-то еще, кто опытнее тебя чистит код. Если в вашей организации нет кого-то, кого вы можете спросить, попробуйте codereview.stackexchange

  • попробуйте Google для конкретной проблемы. Для вашего примера, такие вещи, как «очистить длинную инструкцию SQL», могут быть хорошим началом. Вы будете удивлены, сколько статей вы найдете по этой теме, и даже если вы не можете найти рецепт мозгового убийства для вашего случая, вы можете получить некоторые свежие идеи

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

  • практика, практика, практика. «Чистое кодирование» - это не то, что вы изучаете за один день, оно становится легче с большим опытом. Возможно, вы не нашли решения для своей проблемы сегодня, но когда вы вернетесь к коду через несколько месяцев, он будет выглядеть для вас иначе.

Док Браун
источник
Я несколько не согласен с частью комментариев, если есть одна сложная часть кода, которая является сложной, поскольку она не может быть иначе И не нашла способ упростить ее, комментарии вряд ли дадут общую картину того, что делается. Документировать это с какой-то диаграммой было бы намного лучше. И комментарий, который ссылается на эту внешнюю документацию, должен быть оставлен. Конечно, эти ситуации должны быть исключительными, потому что мы все знаем, что ведение внешней документации выполняется редко, поэтому чем меньше, тем лучше. В остальном хороший ответ как всегда.
Вальфрат
@Walfrat: я намеревался предоставить общее руководство по процессу, не только для «50 строк кода SQL», а не как готовое решение со всеми потенциальными подходами.
Док Браун
Я знаю, я просто хотел предположить, что если что-то после многократного обзора не может быть достаточно упрощено (что бы это ни было), комментарии, скорее всего, не помогут в том, что делает эту вещь сложной, поэтому, вероятно, потребуется минимальная внешняя документация. В конкретном случае запросов к базе данных это еще проще, если показать диаграмму, показывающую, как каждая часть запроса соотносится друг с другом.
Вальфрат
4

Трудно читать, не плохо - излишне трудно читать, это плохо.

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

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

gnasher729
источник
Точно. Старайтесь изо всех сил, чтобы код самодокументировался, а затем используйте комментарии, чтобы заполнить пробелы. (отредактировано: после публикации моего комментария я понял, что OP ссылается на запросы к базе данных 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, объедините их вместе, чтобы читатели вашего кода могли предположить, что все они ведут себя одинаково, не имеют побочных эффектов и т. Д.

Невилл Кайт
источник