Редактор может или не может быть многопоточным, но, даже если это будет, то это вряд ли будет использовать потоки с этой целью по одной простой причине: выполнение так не обеспечило бы преимуществ для нормативного использования, и оно несомненно создаст головные боли разработчика и возможно поставит под угрозу функции, которые считают важными (для нормативного использования).
Учитывая бесконечное количество времени и бесконечное число программистов, несомненно все программное обеспечение было бы дико оптимизировано вниз к самым маленьким самым несоответствующим деталям, экстенсивно протестированным, чтобы гарантировать, чтобы эта оптимизация ни на что негативно не влияла и т.д. Без этого никто не хочет провести их время, кодируя функции 99,9% пользователей, не будет, чтобы никогда ценить, особенно если 0,1%, кто действительно делает так, потому что, например, (аналогия) они действительно хотели открыть банки супа с молотком.
Как несколько человек указали, загрузив файл на 3 ГБ в текстовый редактор, чтобы сделать, поиск и замена хорошо, что-то, что Вы сделали бы, если единственный способ, которым Вы знали, как сделать поиск и замену, находится в текстовом редакторе. Я не пытаюсь оскорбить Вас с этим, BTW, просто дать Вам, дружественное пошаговое перемещение - теперь является временем для расширения некоторых горизонтов ;)
Проблема этого стиля в том, что эти две формы не эквивалентны. При использовании:
if command; then
foo
else
bar
fi
тогда будет вызван либо foo
, либо bar
, никогда не оба. При использовании обоих &&
и ||
можно использовать оба пути:
$ [[ -d / ]] && {
> echo "Path 1 taken"
> false
> } || {
> echo "Path 2 taken"
> }
Path 1 taken
Path 2 taken
$
При использовании if cmd; то foo; else bar; fi
форма, условие для вызова bar
- это cmd
, возвращающий false. При использовании формы cmd && foo || bar
, условием для вызова bar
является cmd && foo
возвращающий false.
EDIT: Я только что заметил, что в вашем вопросе вы признаете, что вы должны поставить true
в конце блоков, чтобы ваша версия работала вообще. Если вы готовы это сделать, я не знаю ни о каких других серьёзных проблемах - но я бы поспорил, что стиль, требующий безоговорочного добавления "true" в качестве последней команды в блоке, если есть вероятность того, что предыдущая команда может провалиться, просто гарантирует, что вы в конце концов забудете об этом, и всё будет выглядеть так, как будто они работают правильно до тех пор, пока они этого не сделают.
На мой взгляд, если-то-другое легче читать для кого-то, кто пишет на любом другом языке.
Но моя рекомендация будет использовать краткую нотацию (с && или ||) только для одноклассников только с одним из &&
и ||
.
Какой-то код, как
[[ -d mustExist ]] || errorFunction "Dir mustExist is missing"
[[ -f toBeSend ]] && sendFile toBeSend
if [[ -d sometimes ]]; then
writeTrueBlock
else
writeFalseBlock
fi
Редактировать: Новая мысль: Может быть, даже лучше написать это, как
test -d mustExist || errorFunction "Dir mustExist is missing"
test -f toBeSend && sendFile toBeSend
if [[ -d sometimes ]]; then
writeTrueBlock
else
writeFalseBlock
fi
Читаемость и стиль
Я склонен использовать &&
и ||
операторы в моих сценариях.
Я даже использую более одного в одном операторе, но только в разделах, которые проверяют, продолжают ли в текущем блоке .
Пример1:
for word in $list; do
condition1 $word || continue
condition2 $word || continue
: do stuff with $word
: do more stuff with $word
done
Состояние1 и Состояние2 действует как утверждения. Мы получаем исключения из пути и продолжайте, как этот кусок кода должен сделать.
Использование Если
тогда затем
... Fi
В этом случае будет немного неловко.
Альтернативные записи:
Пример2:
for word in $list; do
if condition1 $word && condition2 $word; then
: do stuff with $word
: do more stuff with $word
fi
done
в Пример2 У нас есть другой уровень отступа, в то время как ничего Дополнительное происходит.
Пример3:
for word in $list; do
condition1 $word && condition2 $word || continue
: do stuff with $word
: do more stuff with $word
done
Если два условия могут быть выражены просто, я иногда объединяю их как в примере3.
P.S: I изначально добавил упражнение для программиста Shell: только два из трех примеров полностью эквивалентны. Какой нечеткий?
Как это происходит, разница, которую я думал, что там не было.
Я на самом деле написал SHPEC
тест:
describe "continue"
it "discards last exit status"
(for i in 1; do
false || continue
done
)
assert equal 0 $?
end
end
shpec/continue_shpec.sh
continue
discards last exit status
1 examples, 0 failures