Pull to refresh

Comments 36

Заплетык языкается — это последствия Перла.
Попиши на нём ещё немного и начнёшь понимать Кенни из СаусПарка.
Я не программист, но очень понравилось, то как вы сами того не замечая, мимикой и жестами иногда противоречите словам =)

Вам было очень досадно, что вы не успели сделать во время. А про знакомство с перлом у вас было в начале некое отвращение и неуважение =)


доктора Лайтман, разлогинтесь. :)
UFO just landed and posted this here
UFO just landed and posted this here
А что вы хотели сказать этим (upload.pl:7):
$file=~ s/.*[\/\\](.*)/$1/;
А если быть точнее, то этим: [\/\\]?
Я так понимаю, под конкретно вот этим ( [\/\\] ), понимался или "/" (*nix), или "\" (windows).
Понятно, спасибо.
Имхо регулярка сложновата для такой простой задачи )
Хм, что-то в голову не приходит ничего проще (

З.Ы. Дабы не пестрило в глазах от кучи эскепирующих слешей можно писать, например так
$file=~ s!.*[/\\](.*)!$1!;

или так

$file=~ s#.*[/\\](.*)#$1#;

или даже так

$file=~ s@.*[/\\](.*)@$1@;
А еще лучше так:
$file =~ s{.*[/\\](.*)}{$1};
В вашем варианте буковок больше )))
Лучше наверное так
$file =~ s}.*[/\\](.*)}$1};
Эм, я с уклоном на восприятие кода ), так более читаемо. Я за использование либо более популярного слеша, либо парных фигурных скобок. Код должен быть и красив и читаем одновременно. Но тогда так же придется использовать m{} )
Я если насчет буковок поменьше, то я бы написал так:
$file =~ s{.*[/\\]}{};

Выражение, оторванное от контекста, малого стоит, но судя по всему тут мы обрабатываем именно имя файла.
Я прекрасно понял, мой вариант с "}" был как бы шуткой )
Собственно всегда так и пишу )
Но чем это принципиально лучше, чем
$file=~ s/.*[\/\\](.*)/$1/;
не вижу.

Имхо, оба варианта хороши. А так это дело привычки.
Я бы упомянул две особенности, провоцирующих на неоднозначное понимание регулярки человеком, а может быть, и интерпретатором:
1. Отсутствие якорей.
2. Конфликт жадности квантификаторов.
Чтобы разобраться с этими неоднозначностями, даже опытному программисту приходится вдумчиво курить маны. Это явно не на пользу читабельности кода.
Хм, а интересно — что с такой регуляркой делать с *nix файлами с именами содеражащими "\" (например, /path/to/file/file\with\slash, где file\with\slash — это имя файла)? С такой регуляркой получим $file eq 'slash'
В идеале не создавать таких файлов )
Ну а если уж и рассматривать такой вариант, то учитывать особенности операционной системы, у Perl с этим проблем нет.
Может, я в танке, может еще что, но вот никак не могу понять зачем сделано так (upload.pl)
my $file = $cgi->param(«file»);
$file=~ s/.*[\/\\](.*)/$1/;
$upload_filehandle = $cgi->upload(«file»);
my ( $name, $path, $extension ) = fileparse ( $file, '\..*' );
$filename = $name. $extension;
open(LOCAL, ">$ENV{'DOCUMENT_ROOT'}/comp2405/assgn3/cont/$filename") or die $!;

Зачем нужен fileparse? Как будто регулярным выражением выше мы не пытаемся сделать то же самое? Или это чтобы наверняка ;)?
Далее, зачем $upload_filehandle — мы это нигде не используем дальше по коду.

Ну и сам способ сохранения файла на сервере с тем же именем, что и у пользователя на локальной машине — не особо внушает доверия — наивно полагать, что пользователь не загрузит больше одного файла с одинаковыми именами (вообще по коду явно видно что сохраняются все аплоады в одну директорию, что усугубляет проблему).

Я конечно понимаю, что это так сказать учебный материал, но зачем прививать дурной тон?

p.s. Отсюда код взяли http://www.perlfect.com/articles/upload.shtml?
Простите, но не могу сдержаться — ОМФГ…
Распечатаю и буду товарища кошмарить (он перл не любит очень =) )
Это вполне рабочий код, и мы его даже используем )
Нет, я не спорю, что код рабочий, что его можно использовать.
Но мне, например, с моим опытом работы с перл (2 года), боюсь без поллитры не обойтись, что бы понять.
И боюсь я не один такой.
Не каждому под силу даже понять, что этот код делает ))) Не волнуйтесь ;)
были даже версии, что этот код почту отправляет %)
А это типа кто разберётся, того на работу возьмут?
Ага, кто разберется — взять
А кто напишет — гнать куда подальше (если рассматривать проекты, в которых заняты большое количество людей).
Ну почему же.
Этот код в разы быстрее и меньше чем CGI.pm, сколько раз вы в CGI.pm заглядывали? )))
Это замечательно, что он быстрее и т.п.
Но вот допустим берем мы программиста на работу (далее будем называть его Гуру). Он в течение некоторого времени пишет код в подобном стиле. Остальные программисты в команде по своему знанию перла и рядом не стояли.
И в один прекрасный момент Гуру нас по какой-либо причине покидает. А тут вдруг потребовалось очень срочно его код проадейтить под новую фичу, или же обнаружился баг именно в его коде и этот баг надо ну очень быстро исправить.

Как думаете сколько времени займет апдейт или фикс бага, в случае если код был бы в выше указанном стиле или же в более читаемом варианте?

P.S. В CGI.pm заглядывал, но давненько. Поэтому сейчас заглянул еще разок. И как ни странно — код в нем довольно понятен ) (да к тому же снабжен комментариями).
это вечная тема )
мы как-то справились с уходом гуру, и сами порядком прокачались )
тут можно много спорить, не будем ))
Есть части проекта, которые должен писать один человек, которые должны быть очень быстрыми и стабильными, и которые править нет особой необходимости.
Все мы дружно и весело используем CGI.pm, но сколько он памяти ест и сколько времени тратит на свою работу? В HL проектах такое недопустимо. Так же мы часто используем xs модули для повышения производительности, там вообще шойтан что происходит :)

Естественно, в промышленных масштабах такой подход не желателен :)
А если нам приходится писать HL проект, мы рискуем использовать нестандартные подходы. Часто это оправдывает себя.
Эх, жаль не могу плюсик в карму вам поставить )

З.Ы. Мы тут малость отклонились от изначально поставленного вопроса ;) Все таки не понятно мне зачем одно и тоже делать подряд дважды в коде )
Откуда мне знать? Как я понял, чувак впервые на Perl пишет, а может и вообще впервые ) Думаю не стоит к этому коду придираться )
Причёску сменил, однако :) Стал таким брутальным парнишей.
Sign up to leave a comment.

Articles