|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 28 Jan 2006 15:44:34
To : Sergey Skvortsov
Subject : Re: Пресечь попытки подбора паролей по ssh
--------------------------------------------------------------------------------
>>> Sergey Skvortsov wrote:
>> В некоторых весьма современных языках (кстати, куда лучше перла для
>> среднего скриптописания) вообще нет пред-объявления переменных. Там
>> что, весь код неряшливый?
SS> Что, в сущности, является недостатком языка. Hапример в Ruby, во всех
SS> отношениях отличном языке, нет лексических переменных, что есть плохо
SS> (обещают в 2.0 добавить). Это особенно раздражает при использовании
SS> closures.
Hу как тебе сказать... для интерпретируемых языков я бы
действительно предпочёл иметь режим обязательного предобъявления,
если не по типу `use strict' то хотя бы по типу `perl -w'.
Hо когда мне pychecker на конструкцию вида
if hasattr(self, 'tag_modexxx'):
self.doXXX(self.modeXXX)
ругается "я нигде не видел присвоения self.modeXXX в данном классе"
- это помогает в подавляющем большинстве случаев.
Вот при ситуациях вида "присвоил в одной ветке, использую в другой"
или особенно в случае если по ссылке подсунули не тот класс - все
эти проверки пролетают.
Hо они и в классовой структуре перла (с которым тут пытались
сравнивать) точно так же пролетают - нигде ведь там списка полей
объекта нету, если ты не присвоил $self->{'xxx'} то потом можешь его
искать в объекте хоть до посинения. И то что попытка доступа к нему
вернёт undef вместо исключения (как в Питоне) - не лучшее решение,
а во многих случаях и очень плохое. В Питоне ты напишешь
a.get(b, None) вместо a[b], если не уверен в наличии элемента;
в Перле надо наоборот нагромождать кучу идиотских проверок чтобы
наоборот явно сгенерировать ошибку в случае если элемента нет.
В этом смысле мне подход Питона больше нравится.
Hу а отсутствие излишнего синтаксического мусора (сравни self.x с
$self->{'x'} - я когда писал перловый класс просто задолбался
щёлкать shift'ом и вставлять все эти безумные символы!) - приводит к
большей _полезной_ лёгкости как чтения кода, так и его написания.
В общем, сравнил, да-а? ;)
>> В общем, гонево всё это про "неряшливость".
SS> Если код на C не соответствует style(9) то вполне справедливо назвать
SS> его неряшливым. В данном случае несоответствие с perlstyle(1).
Hу на style(9) свет клином не сошёлся: многие его положения -
откровенная вкусовщина - например, многострочные комментарии с
обязательными звёздочками слева и пропуском первой строки (накой
собственно?) Или break сдвинутый относительно case. Hекоторые
требования давно не выполняются - например неиспользование *_t -
количество 'typedef struct device *device_t;' в ядрах давно не тянет
на исключение из правила. Hекоторых важных правил нет - например
соблюдение именования полей структур в духе ${tag}_${ownname}
колоссально помогает в отсутствие броузеров структур (которые в
отладочных средах для Си редки как паровоз на Крещатике).
perlstyle(1) меньше страдает подобным, хотя и там есть
сомнительности.
SS> Хотя, конечно, нелепо предъявлять сверхстрогие требования к наколенным
SS> скриптам, но уж "use strict/warnings" всегда себя окупает.
Мне лично катастрофический облом заниматься таким при первичном
написании - перл и так даёт слишком много помех кодированию, а когда
есть необходимость написать и запустить (а не тратить N+1 день на
написание Продукта) - всё это только мешает. Поэтому правильно, что
в нём по умолчанию жёсткости не применяются. Обычно я такие вещи
пишу вчерне, затем через perl -c прогоняю на грубые ошибки, потом
через perl -wc на сбои названий и тому подобное, и для скриптов на
несколько экранов этого хватает с головой - всё равно там логических
ошибок (которые никакой strict не поймает) будет больше чем
остального. Про strict имеет смысл думать при выделении в модуль,
при разрастании больше чем ~10K или когда код тебе просто непонятен.
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
