Пример: на самом деле раздражает печатать список строк в python:
["January", "February", "March", "April", ...]
Я часто делаю что-то подобное, чтобы избавить меня от необходимости вводить кавычки повсюду:
"January February March April May June July August ...".split()
Те занимали такое же количество времени, и я получил 2x количество месяцев, набранных. Другой пример:
[('a', '9'), ('4', '3'), ('z', 'x')...]
вместо:
map(tuple, "a9 43 zx".split())
что заняло гораздо меньше времени.
Код обычно читается много раз, и он написан только один раз.
Сохранение времени записи за счет удобочитаемости обычно не является хорошим выбором, если только вы не делаете какой-то броский код.
Вторая версия менее явная, и вам нужно некоторое время, чтобы понять, что делает код. И мы просто говорим о создании переменной, а не об алгоритмах!
Хороший текстовый редактор может сделать эти вещи без проблем. Например, я могу ввести следующую строку в свой код:
print `"January February March April May June July August September October November December".split()`
И затем, используя последовательность клавиш V:!python<ENTER>, я могу запустить строку через интерпретатор python, а вывод следующий:
['January', 'February', 'March', 'April', 'May', 'June', 'July', 'August', 'September', 'October', 'November', 'December']
Я использую Vim для моего примера, но я уверен, что это так же легко с Emacs, TextMate и т.д.
В разумно умном редакторе вы можете:
<space> на "<space>" для первого примера),Читаемость и легкость ввода... уважают силу редактора!
В общем, я думаю, что это плохая идея. Первый пример не так плох (это своего рода замена для python отсутствие qw), но второй гораздо труднее понять. В частности, я думаю, что такого рода вещи очень неряшливы и, безусловно, не подходят при написании кода Python, во всяком случае. Кодируемость кода гораздо важнее, чем экономия времени на создание кода. Если у вас действительно много данных для жесткого кодирования, напишите script, чтобы сгенерировать его для вас.
Как часто вам нужно вводить ["January", "February"... etc]?
Предоставленный вами подход может сэкономить ваше время, но зачем добавлять сложность в ваш код без уважительной причины, кроме того, что вы немного ленивы?
Если вам действительно нужно набирать его так часто... Copy-Paste!
В производственном коде, сделайте это правильно. В тестовом коде, пока эта идиома появляется более одного или двух раз, я думаю, что это приемлемо. Если в тестовом коде эта ситуация появляется один или два раза, сделайте это правильно.
... Я часто делаю что-то подобное, чтобы избавить меня от необходимости вводить кавычки повсюду...
Я думаю, что такая вещь должна выполняться только один раз для каждой программы. Если вы делаете то же самое "повсюду", то не имеет значения, какой из них вы используете, вы создаете монстра.
Такое выражение должно быть написано только ОДИН за весь код.
Это разумно сделать для данных, которые вы не ожидаете изменить, например, месяцев или дней недель. Также разумно делать это, одновременно высмеивая или обманывая взаимодействия с файлами или базами данных, поскольку он изолирует ваш код для тестирования. Однако это нехорошее долгосрочное решение для производственного кода, и это не спасает вас много времени. Все, что достаточно велико, чтобы обеспечить большую экономию времени, достаточно велико, чтобы требовать хранения данных где-то еще, как отдельный файл базы данных.
Я почти клянусь Code Steve McConnell Complete: одна из основных идей заключается в том, что плохие программисты пишут код, чтобы заставить компьютеры что-то, период, в то время как хорошие программисты пишут сначала, чтобы написать код, который люди могут понять, и только второй, чтобы заставить компьютер делать что-то.
(Код, написанный без удобочитаемости в качестве основной проблемы, похож на попытку найти вещи в шкафу или шкафу для хранения, где люди просто втискивают вещи, не задумываясь о том, чтобы сделать что-то, в чем вы можете перемещаться и находить вещи.)
Я думаю, вы могли бы выиграть от чтения кода Complete; Я знаю, что сделал.
ваши быстрые и умные методы, в то время как приятные, занимают больше времени, чтобы читать, что плохо. Считывание всегда происходит всегда.
Я не думаю, что тип вещи должен быть в источнике.
Если бы я был вами, я бы оценил Python соответствующие версии и затем вставлял результаты в исходный код.
Я думаю, что ввод таких утверждений, как
"Январь Февраль Март Апрель Май Июнь Июль Август...". split()
на глобальном уровне модуля отлично. Таким образом, он выполняется только один раз во время импорта. Я даже иногда использую его в критических функциях, не связанных с производительностью, из-за уменьшения линейного шума.
В обозревателе я считаю, что интерпретаторы Python могут быть выполнены для выполнения "split()" во время компиляции, что приведет к ликвидации служебных данных метода. Причина в том, что строка является встроенным литералом, а Python не позволяет добавлять/переопределять методы в самом базовом строковом типе, поэтому компилятор может знать, что ".split() может ссылаться только на один конкретный метод.
Я бы счел это приемлемым, если немного ленивым, до тех пор, пока то, что делается, не слишком критично. Вы всегда можете вернуться и оптимизировать его, если вам нужна более высокая скорость.