Насколько сложным должен быть код?

Question

Я изучаю алгоритмы, которые могут помочь мне написать меньший, но более сложный код. Вместо того чтобы писать 150 строк операторов if-else, я могу разработать алгоритм, который делает это в 20 строк. Проблема в том, что многие из этих алгоритмов могут быть сложными и требовать много математики, чтобы понять их. Я также здесь единственный, кто понимает их.

Для удобства сопровождения кода было бы лучше просто написать код, как все остальные, или лучше использовать алгоритмы?

Answer 1

Проще обычно лучше. Помните, что другие люди, вероятно, когда-нибудь будут поддерживать его.

Answer 2

Zen of Python неплохо справляется с этой проблемой:

...

Простое лучше, чем сложное.

Комплекс лучше, чем сложный.

...

Если реализацию сложно объяснить, это плохая идея

...

Другими словами (и как уже говорили другие), самый простой алгоритм , который выполнит работу при наложенных ограничениях (время, память и т. Д.), Является лучшим. Очевидно, что более простой алгоритм, который не выполняет работу, не достаточно хорош. Если ваш код короче, потому что он использует сложные идеи, это сложно. Если никто другой не может понять ваш код, это сложно, и если вам трудно объяснить его им (даже если они поймут это с докторской степенью по математике), плохая идея .

...

Особых случаев недостаточно, чтобы нарушать правила.

Хотя практичность побеждает чистоту.

...

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

Answer 3

Пишите код так, чтобы его было проще и понятнее обычному программисту, работающему над вашим кодом.

Answer 4

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

Тем не менее, я видел достаточно "WTF?" кодирование, которое вы описываете, что я, как правило, пошел бы на подход, если-то-еще. Но подумайте об этом; Можно ли использовать ваш более сложный, формальный подход, но разделить особенно сложные компоненты на хорошо названные методы? Если вы можете сделать это (возможно, даже рефакторинг для устранения избыточности), вы сможете избежать наихудших аспектов вашего алгоритма и избежать многоуровневой структуры if-then-else.

Answer 5

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

Answer 6

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

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

Я бы также предположил, что вы можете разместить версию if-else в блоке комментариев над версией алгоритма из 20 строк (или наоборот), чтобы сопровождающие могли понять, что пытается сделать ваша сложная версия. Наличие обоих в коде облегчает тестирование производительности обоих (и после того, как вы ввели их оба, нет смысла удалять другое). Это также позволит легко перейти на другие языки / платформы / компиляторы в будущем. Вы можете этого не ожидать, но если код работает, он, вероятно, будет жить десятилетиями и будет видеть множество различных компиляторов и платформ.

Answer 7

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

Answer 8

Попробуйте и проверьте вашу "более сложную" версию другими, через несколько недель после ее написания. Оцените сложность того, насколько трудно вам читать и объяснить это другим, и их реакцию на код.

Answer 9

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

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

Answer 10

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

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

Но держите эти алгоритмы изолированными в своих собственных функциях и не забудьте объяснить входные и выходные переменные!

Обязательная цитата:

«Управление сложностью - это сущность компьютерного программирования. »(Брайан Kernigan)