Действительно ли приемлемо использовать приемы для сохранения программиста при помещении данных в код?

Хороший текстовый редактор может сделать эти вещи несложными. Например, я могу ввести в свой код следующую строку:

print `"January February March April May June July August September October November December".split()`

А затем, используя последовательность клавиш V:! Python , я могу запустить строку через интерпретатор Python, и на выходе будет следующее:

['January', 'February', 'March', 'April', 'May', 'June', 'July', 'August', 'September', 'October', 'November', 'December']

Я использую Vim для своего примера, но уверен, что это так же просто с Emacs, TextMate и т. д.

В достаточно умном редакторе вы можете:

1. Выбрать интересующие строки,
2. вставить замену ( <пробел> на « <пробел > "для 1-го примера),
3. установите флажок для выбранных строк,
4. щелкните заменить все,
5. бац .. готово.

Читабельно и легко вводить ... уважайте силу редактора!

В общем считаю, что это плохая идея. Первый пример не так уж плох (это своего рода замена отсутствию qw в python), но второй гораздо труднее понять. В частности, я думаю, что такого рода вещи очень непонятны и, во всяком случае, не подходят для написания кода Python. Читаемость кода намного важнее, чем экономия времени на написание кода. Если у вас действительно ТАКОЕ много данных для жесткого кодирования, напишите сценарий, который сгенерирует их для вас.

Как часто вам действительно нужно вводить [«Январь», «Февраль» ... etc] ?

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

Если вам действительно нужно набирать его так часто ... . Копировать-вставить!

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

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

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

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

Такое объявление должно быть написано только ОДИН РАЗ для всего кода.

Я не думаю, что такие вещи должны быть в источнике.

На вашем месте я бы попросил Python оценить соответствующие вторые версии, а затем вставить результаты в мои исходный код.

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

Я думаю, что такие утверждения, как

«Январь Февраль Март Апрель Май Июнь Июль Август ...». split ()

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

Кстати, я думаю, что интерпретаторы Python можно заставить выполнять "split ()" во время компиляции, что устранит накладные расходы на вызов методов. Причина в том, что строка является встроенным литералом, а Python не позволяет добавлять / переопределять методы для самого базового строкового типа, поэтому компилятор может знать, что "" .split () может ссылаться только на один конкретный метод.

Я почти клянусь Стивом МакКоннеллом Code Complete : одна из основных идей заключается в том, что плохие программисты пишут код, чтобы заставить компьютеры что-то делать, точка , в то время как хорошие программисты сначала пишут код, который люди могут понять, и только потом, чтобы заставить компьютер что-то делать.

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

Я думаю, вы могли бы извлечь большую пользу из чтения Code Complete ; Я знаю, что сделал.

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