Используя 'возврат' вместо 'еще' в JavaScript
Я помню старые дни Borland, и интервал только не зависел от Вашей машины, но и от Вашего компилятора. Таким образом, основное назначение здесь - если Вы - неаккуратный кодер, тогда используют то, что и продолжают быть тем путем.
, Если Вы волнуетесь по поводу управления памятью, затем рассмотрите, почему C# является языком со строгим контролем типов и что у Вас есть int32, int64 и int16 по причине.
Рассматривают это:
for (int i=0; i<100; i++) { }
и
for (Int16 i=0; i<100; i++) { }
и
for (Int64 i=0; i<100; i++) { }
, Какой из них является самым эффективным? Int16! Вы могли утверждать, что в CIL они - то же, но что, если у Вас есть функция вызова, распараллелил 1000 раз? Это уже 4 КБ (так) памяти, которую Вы тратите впустую ПРОСТО ТАМ.
Настоящие программисты использовали бы меньшее обозначение несмотря на него возможно не быть отличающимся, потому что семантически это более корректно, и мог бы в некотором будущем вопросе компиляции. Остальная часть Вас, на которых любители могут пойти не, заботится о мелких подробностях, и Ваш код высосет, потому что Вы не заботитесь об этом. Это похоже на freekin' завод. Любите его! Не будьте неаккуратны!
9 ответов
I always go with the first method. Easier to read, and less indentation. As far as execution speed, this will depend on the implementation, but I would expect them both to be identical.
«Профиль, не рассуждайте!»
- вы ставите телегу впереди лошади (ремонтопригодность для людей важнее скорости машины)
вам следует направить свои усилия по оптимизации за счет измерений , что означает
- , что вы должны рассчитать время выполнения самостоятельно; очевидно, что он будет отличаться в разных браузерах и версиях
- , вам следует оптимизировать только для скорости точек доступа вашего приложения (см. пункт 1)
There won't be any difference in performance I would recommend the second example for maintainability. In general it's good practice to have one and only one possible exit point for a routine. It aids debugging and comprehension.
Может быть, немного , но я не думаю, что его можно будет измерить, если остальная часть функции не включает "тяжелые" (и в противном случае избыточные, поскольку я предполагаю, что возврат даст тот же результат) js-вызовы.
В качестве примечания, я думаю, что это является ненужной микрооптимизацией, и вам, вероятно, следует поискать улучшения производительности в другом месте,
Проверьте сами. Если этот JavaScript выполняется в браузере, он почти наверняка будет зависеть от механизма синтаксического анализа JavaScript в браузере.
Хотя это зависит от реализации JavaScript в работающем браузере, между ними не должно быть заметной разницы (с точки зрения скорости).
Вторая форма предпочтительнее, поскольку прерывание потока не является хорошей привычкой программирования. Также подумайте о том, что при сборке инструкция перехода (микрооперация) всегда оценивается независимо от оценки.
Предположим, что возврат занимает 1 мс по сравнению с вложенным , если занимает 0,1 мс (или наоборот).
Трудно вообразить любой из них. почти такая медленная.
Итак, вы делаете это более 100 раз в секунду?
Если так, может вам стоит позаботиться.
Насколько я понимаю, это не имеет значения, потому что вы выполняете переход с условием if. Итак, если some_condition истинно, часть else не будет затронута даже без возврата.
In many languages, is a common practice to invert if statements to reduce nesting or use preconditions.
And having less nesting in your code improves code readability and maintainability.