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

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

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

Вы написали

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

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

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

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

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

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

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

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

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

ORM для создания отчета? Шутки в сторону? Выучи немного SQL, чувак. Процедурные языки ужасны при подобных вещах.

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

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

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

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

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

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

И вы оцениваете код на уровне приложения, а не на уровне отдельных методов / строк кода. Так что, если у вас есть сложный метод, но он четко назван, я не думаю, что у вас есть «плохой» код, если метод является связным.

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

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

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