Практические правила для преждевременной [закрытой] оптимизации
То, что вы видите в строке формата (%1$s), это то, что называется перестановка аргументов (см. Примеры 1-4 для полного понимания).
Вы бы использовали его, если порядок ваших заполнителей отличается от порядка аргументов. Пример:
У вас есть строка
$str = "%s had a %s %s";
и массив
$args = [
'Mary',
'little',
'lamb',
];
И ваш результат форматирования будет: «У Мэри был маленький ягненок». Но что произойдет, если аргументы будут в другом порядке, например:
$args = [
'lamb',
'Mary',
'little',
];
Тогда вы получите «ягненок имел маленькую Марию». Используя подстановку аргументов (я знаю, запутанное имя), вы указываете форматировщику, где именно искать данный аргумент. Эти заполнители настраиваются по позициям, а не по индексу, поэтому они начинаются с 1, а не с 0.
Таким образом, чтобы получить правильный вывод для вышеупомянутых неупорядоченных аргументов, вам потребуется строка формата:
$str = "%2$s had a %3$s %1$s";
Обратите внимание, что замена аргументов имеет смысл тогда и только тогда, когда вы можете гарантировать, что порядок аргументов в вашем массиве всегда будет одинаковым. Кроме того, если вы не можете контролировать порядок аргументов (но можете гарантировать, что он будет одинаковым), вам, скорее всего, придется его использовать.
Как отметил Бернд Уилк πφ , обмен аргументами очень полезен при работе с локализацией, как, например, в вашем случае.
Разные языки имеют разные лингвистические типологии, то есть где, например, субъект, глагол и объект помещены в предложение или даже как написана дата.
Стандартным английским форматом даты является, например, month-day-year. В Германии он отформатирован как day.month.year, а японский - как year-month-date. Теперь, когда вы получите массив аргументов из любого места, содержащий значения для года, месяца и дня, в этом порядке
$arguments = [
"2019",
"03",
"20",
];
, вы не сможете обойтись с помощью замены аргументов, чтобы расположить элементы в правильном порядке.
На английском языке ваша строка формата будет %2$s-%3$s-%1$s, для немецкого %3$.%2$.%1$ и для японского либо %1$s-%2$s-%3$s, либо даже %s-%s-%s (по совпадению, аргументы уже в правильном порядке, но во избежание путаницы и оставайтесь последовательными, вы должны использовать позиционное форматирование, как и в других языках).
Когда вы можете управлять порядком аргументов, обычно проще использовать непозиционную строку форматирования, но, как объяснено выше, это не очень хорошо работает для локализации, если вообще.
8 ответов
Что такое преждевременная оптимизация?
Преждевременная оптимизация - это процесс оптимизации вашего кода (обычно для повышения производительности) до того, как вы узнаете, стоит ли это делать. Примером преждевременной оптимизации является оптимизация кода до того, как вы профилируете его, чтобы выяснить, где находится узкое место производительности. Еще более ярким примером преждевременной оптимизации является оптимизация до того, как вы запустили свою программу и установили, что она работает слишком медленно.
Наступили ли мы сейчас, когда выбор между алгоритмом сложности O (n ^ n) и O (n!) Не имеет значения? А как насчет O (n) или O (n * n)?
Это зависит от размера n и от того, как часто будет вызываться ваш код.
Если n всегда меньше 5, то асимптотические характеристики не имеют значения. В этом случае большее значение будет иметь размер констант. Простой алгоритм O (n * n) может превзойти более сложный алгоритм O (n log n) для малых n. Или измеримая разница может быть настолько маленькой, что это не имеет значения.
Я все еще думаю, что слишком много людей тратят время на оптимизацию 90% кода, который не имеет значения, вместо 10%, которые не имеют значения. Никого не волнует, занимает ли какой-то код 10 мс вместо 1 мс, если этот код почти никогда не вызывается. Бывают случаи, когда просто сделать что-то простое, что работает, и двигаться дальше - хороший выбор, даже если вы знаете, что алгоритмическая сложность не оптимальна.
Каждый час, который вы тратите на оптимизацию редко вызываемого кода, на один час меньше, чем вы можете потратить на добавление функций, которые действительно нужны людям.
Для некоторых людей оптимизация - это часть удовольствия от написания кода, преждевременно или нет. Я люблю оптимизировать и ограничивать себя ради разборчивости. Совет не оптимизировать так много для людей, которые любят оптимизировать.
программисты iphone, в частности, думают, что предотвращение преждевременной оптимизации - это активная задача
Большинство кода iPhone связано с пользовательским интерфейсом. Существует не так много, чтобы оптимизировать. Не нужно выбирать плохой дизайн, который приведет к плохой производительности, но как только вы начнете кодировать хороший дизайн, вам не нужно будет оптимизировать. Поэтому в этом контексте избегать оптимизации является разумной целью.
Сложность алгоритма и даже выбор - это проблема, которая должна быть скрыта за интерфейсом. Например, List - это абстракция, которая может быть реализована различными способами с разной эффективностью для разных ситуаций.
Иногда предотвращение преждевременной оптимизации может помочь проектированию, потому что, если вы разрабатываете с идеей, что вам нужно будет оптимизировать позже, тогда вы более склонны развиваться на абстрактном уровне (например, список), а не в реализации (например Уровень массива или связанного списка).
Это может привести к более простому и более читабельному коду, а также к тому, чтобы избежать отвлечения внимания. Если запрограммированы для интерфейса, различные реализации могут быть заменены позже, чтобы optmize. Преждевременная оптимизация приводит к риску того, что детали реализации могут быть преждевременно раскрыты и связаны с другими программными компонентами, которые не должны видеть эти детали.
Я думаю, что это вопрос здравого смысла. Необходимо понять общую картину или даже то, что происходит под капотом, чтобы иметь возможность рассмотреть, когда оправдан так называемый «преждевременный» ход.
Я работал с решениями, в которых вызовы веб-службы были необходимы для вычисления новых значений на основе содержимого локального списка. Это было реализовано путем создания веб-запроса для каждого значения. Не было бы преждевременной оптимизацией посылать несколько значений одновременно. То же самое касается использования транзакций базы данных для нескольких операций, то есть для нескольких вставок.
Когда дело доходит до алгоритмов, изначально самое важное - сделать это правильно и максимально просто. В этот момент беспокоиться о проблемах со стеком и кучей - это безумие.
Какие практические правила вы используете, чтобы сознательно или бессознательно избегать этого?
Один из способов избежать ненужной оптимизации - рассмотреть относительную выгоду:
A) Стоимость оптимизации кода для программиста + стоимость тестирования этой оптимизации + стоимость поддержки более сложного кода в результате этой оптимизации
против
B) Стоимость модернизации сервера, на котором работает программа, или просто покупки другого (если он масштабируемый)
Если A >> B, подумайте, правильно ли это. [Игнорируя на данный момент экологические издержки B, которые могут волновать или не волновать вашу организацию]
Это относится в целом, а не только к преждевременной оптимизации, но это может помочь привить вашим разработчикам чувство, что тратить свое время на работу по оптимизации - это затраты, и не следует ее предпринимать, если нет реальной измеримой разницы в чем-то, что действительно имеет значение, например: количество необходимых серверов или удовлетворенность клиентов за счет улучшения времени отклика.
Если руководство не видит выгоды в снижении затрат, а клиенты не видят выгоды в улучшении времени отклика, спросите себя, зачем вы это делаете.
Что вы считаете преждевременным оптимизация »? Какие практические правила вы сознательно или бессознательно избегать этого?
Использование гибкого подхода (быстрые итерации с уточнением требований посредством взаимодействия с пользователями) полезно, поскольку осознание того, что текущий интерфейс, вероятно, кардинально изменится после следующего сеанса с пользователями, облегчает сосредоточение внимания на развитии основных функций приложения, а не на производительности.
Если нет, то несколько итераций, когда вы потратили много времени на оптимизацию функции, которая была полностью отброшена после сеанса с пользователем, должны дать вам сообщение.
Мой голос за то, что большинство людей оптимизируют то, что они считают слабым местом, но не профилируют.
Поэтому, независимо от того, насколько хорошо вы знаете алгоритмы и насколько хорошо вы написали свой код, вы не знаете, что еще происходит за пределами вашего модуля. Что API, которые вы вызвали, делают за кулисами? Можете ли вы всегда гарантировать, что определенный порядок операций будет самым быстрым?
Это то, что подразумевается под преждевременной оптимизацией. Все, что вы считаете оптимизацией, которая не была тщательно протестирована с помощью профилировщика или другого инструмента (тактовые циклы по операциям - неплохая вещь, но она говорит только о характеристиках производительности ~ фактические вызовы важнее, чем время, как правило), является преждевременной оптимизацией.
@k_b сказал это гораздо выше меня, и я тоже так говорю. Сделайте все правильно, сделайте все просто, затем профиль, затем подстройка. Повторяйте по мере необходимости.
Порядок приоритета: 1. Должен работать 2. Он должен быть поддерживаемым 3. Он должен быть машинно-эффективным
Это было с первой недели моего первого курса программирования. В 1982 .
«Преждевременная оптимизация» - это всякий раз, когда приоритет 3 рассматривался раньше, чем приоритет 1 или 2.
Обратите внимание, что современные методы программирования (абстракции и интерфейсы) разработаны, чтобы упростить эту приоритизацию.
Одна серая область: во время первоначального проектирования вы действительно должны проверять, не являются ли ваши решения по своей сути чрезвычайно медленными. В противном случае не беспокойтесь о производительности, пока у вас не появится хоть какой-то рабочий код.