ок, я все понимаю, но как написать тест для «в форме при введенной маске поиска „*\1“ происходит лишнее экранирование \1», адекватно ли время написания подобного теста с патчем в 1 строку…
не понимаю как обзор кода можно автоматизировать… какой именно этап имеется ввиду?
я это делаю примерно так — качаю брнч подготовленный к ревью, собираю, смотрю наличие варнингов (их быть не должно)
просматриваю коммиты по очереди, их как правило не много, не больше 5-10, смотрю появившиеся новые объекты которые возможно не освобождены в нужном месте, смотрю на-сколько код красив (не в плане отступов, а вообще его оптимальность), ставлю подпись если все устраивает и бранч соответствует заявленным функциям.
У нас в команде принято производить обзор нового кода перед его влитием, без ревизии 2-х разработчиков нельзя производить влитие кода в основной ствол.
> 1. Обзоры кода НЕ ДОЛЖНЫ проводиться с целью поиска ошибок.
не понял что то я этого… ведь я произвожу ревизию кода в основном чтобы увидеть потенциальные ляпы (ошибки) которые пропустил выложивший…
спасибо за отклик, если вдруг хватит сил только на часть функционала — не беда, главное чтобы утилита была работоспособной и код был читаемым (на сколько это вообще возможно в перле)
интересно на сколько хорошо и детально они проработали остальные части тела…
Японцы они такие… дотошные по самое немогу… помню передачу по N.Geographic показывали про то как японцы разрабатывают унитазы так у них даже искуственные (извините) какашки были для тестирования разработаны со свойствами близкими к натуральным…
я не понимаю вашего вопроса, я не использую firefox на серверах и не помню чтобы такое говорил. Второе я считаю что если пишешь что то что дальше будет кем то использоваться то надо это делать так чтобы было меньше привязок к чему то узкоспециальному.
>
>Сравните и скажите, что проще:
>bash:
>1. find. '*.c' -print | xargs grep 'hello' /dev/null
>2. for i in `ls *.tar.bz2`; do tar xjf "$i"; done
>
>zsh:
>1. grep hello $(ls **/*.c)
>2. for i in *.tar.bz2;tar xjf "$i"
ненене дэвид блэйн, одно дело пользоваться zsh для своего удобства, второе писать скрипты для общих случаев, в скриптах не место не bash-измам не zsh-измам, мое сугубое имхо.
ну «for i in» буквально означает перебирать то в чем ищите, а искать надо в списке, "*.txt" это не список файлов это просто строка. я обычно делаю как то так
#!/bin/sh
ls -la | while read tfile
do
echo "$tfile"
done
самый простой пример цикла по списку файлов, можете дальше его усложнять как будет угодно…
вот как тут на картинке funkyimg.com/u2/310/066/ydiff_PNG.png
я это делаю примерно так — качаю брнч подготовленный к ревью, собираю, смотрю наличие варнингов (их быть не должно)
просматриваю коммиты по очереди, их как правило не много, не больше 5-10, смотрю появившиеся новые объекты которые возможно не освобождены в нужном месте, смотрю на-сколько код красив (не в плане отступов, а вообще его оптимальность), ставлю подпись если все устраивает и бранч соответствует заявленным функциям.
не понял что то я этого… ведь я произвожу ревизию кода в основном чтобы увидеть потенциальные ляпы (ошибки) которые пропустил выложивший…
и надеюсь не будет…
Японцы они такие… дотошные по самое немогу… помню передачу по N.Geographic показывали про то как японцы разрабатывают унитазы так у них даже искуственные (извините) какашки были для тестирования разработаны со свойствами близкими к натуральным…
>Сравните и скажите, что проще:
>bash:
>1. find. '*.c' -print | xargs grep 'hello' /dev/null
>2. for i in `ls *.tar.bz2`; do tar xjf "$i"; done
>
>zsh:
>1. grep hello $(ls **/*.c)
>2. for i in *.tar.bz2;tar xjf "$i"
ненене дэвид блэйн, одно дело пользоваться zsh для своего удобства, второе писать скрипты для общих случаев, в скриптах не место не bash-измам не zsh-измам, мое сугубое имхо.
#!/bin/sh
ls -la | while read tfile
do
echo "$tfile"
done
самый простой пример цикла по списку файлов, можете дальше его усложнять как будет угодно…
вот пример цикла с for
for i in `seq 1 100`; do
echo "$i"
done