AP> Так намного лучше. Хотя вот в таком эскейпинге - \@ очень легко ошибиться. Ну
AP> и $@ или $_ читабельности не добавляют, а совместо с ; в конце строки
AP> становятся малочитаемыми.
так это вопрос выбора имен переменных
речь идет о том что читает код всеж таки специалист
вот отвлечься от Perl, взять Makefile, там полно всяких $@, $<, $> итп
никто же не говорит что makefile масдай все пишут/используют
альтернатив в общем-то никто и не брался придумывать ;)
AP>>
AP>>> мне уже не прочитать. Это же брэйнфак какой-то, а не язык
AP>> программирования. почему брейнфак? $_ - универсальная временная переменная.
AP>> называлась бы она $TEMP было б так же, никто ведь не мешает называть
AP>> переменные как нравится и не использовать $_? (кстати эта переменная
AP>> синоним имеет $ARG в use English)
AP> Перл тем и плох, что позволяет писать как попало. В одном и том же коде
AP> зачастую смешиваются разные стили. А писать все в одном стиле - кода больше
AP> получается в некоторых случаях и лениво становится.
стоп
давай различать разные алгоритмы и стили.
плохой стиль программирования в любом языке будет читаться плохо
а стандартные имена стандартных временных переменных это как бы
стандартное и соответственно претензии к нечитабельности идут только от
тех кто этим не пользуется.
например когда вижу java'вский
bla_bla.krya_krya.ha_ha.kva_kva.be_be.bi_bi.ko_ko.kukareku(10);
меня жуть берет, но я не специалист в javam поэтому не знаю что каждая
фигатень значит.
однако java повсюду очень хвалят именно как язык строгий нерасполагающий
к ашипкам итп
так и тут ну запомнить надо что $@ - входные переменные, $_ - временная
переменная
и код сразу понятен :)
AP>>> Может быть, оно и работает, но если помрет на каком-нибудь спецсимволе
AP>>> входных данных,
AP>> ну вообще ТАКОЙ метод парсинга как ты предложил вполне и на тикле
AP>> помереть может.
AP> На тикле я его в catch засуну на продакшене да еще в защищенный интерпретатор
AP> упакую. В тикле средства защиты динамического кода предусмотрены.
ну и в перле я его в eval завернул (что тоже что твой catch) и в перле
есть рестриктед перл-песочница
AP>>> то отладка обещает быть веселой. И вы серьезно готовы
AP>>> мегабайт-другой такого кода поддерживать?
AP>> что тебе в этом коде не нравится кроме имени временной переменной?
AP> Да все не нравится. Вот выдернуть кусок кода из контекста
AP>>> eval "foo_$$_[0](\$\$_[1])";
AP>>> foo_unknown($$_[1]) if $@;
выдернуть твой кусок из контекста с {}-ми \/-ми запятыми итп
так оно хуже регекспов тобой же приведенных выглядит
только что покороче чуток
set replist [list to: {} :CV: {} ( { } ) { } : { } , { } \/ { } -> { } $ {} \[
{} \] {}]
совсем нифига не понятно. кстати если распихивать по функциям парсер
то нафиг в главном парсить аргументы? пусть каждая функция и разгребает
что ей там на вход пришло :)
AP> и уже не разберешь, что это и зачем. А если нужно быстро просмотреть модуль в
AP> сотню килобайт такого кода, написанного пару лет назад?
то просматриваешь и всего делов.
любой код должен быть откоментирован, perldoc perldoc на эту тему есть
;)
--
. ''`. Dmitry E. Oboukhov
: :’ : unera@debian.org
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
Attachment:
signature.asc
Description: Digital signature