Xpoint
   [напомнить пароль]

Посоветуйте литературу о правильном построении структур программ в Perl

Метки: [без меток]
2007-08-27 19:29:00 [обр] Алексей Фёдоров(0/3)[досье]

Недавно устроился Perl-программистом в одну контору, и понял, что культура написания программного кода тут очень сильно хромает. Каждый пишет программный код как может, отсутствуют какие-либо соглашения и внутренние стандарты. Учитывая что команда работает по методологии Scrum (стандарты и коллективное владение кодом), всё это не может не угнетать. Причём, я не имею ввиду такое понятие как правильное оформление кода (отступы и скобки), я имею ввиду такие не зависящие от языка стандарты де-факто типа:
— объявлять локальные переменные вначале блока или функции, а не по мере того как «за ухом зачесалось»;
— не выходить из функции досрочно в 10-и разных местах, а делать это естественным образом в конце;
— не убивать программу в случае возникновения ошибки;
— выносить за пределы цикла выражения не зависящие от инкремента;
— в операторах сравнения сначала проверять наиболее вероятные условия и пр.

(Пожалуйста, не придирайтесь к этим примерам, это только примеры. Вопрос не в оценке истинности этих примеров.)

Попробовал немножко возмутиться, на что мне сказали: «Приведи нормальные доводы, почему писать так как ты предлагаешь это правильно». Большинство моих ценностей прививал мне мой университет и бывшие коллеги, потому я и не знаю на что сослаться, аргументы «так правильнее» и «так логичнее» не прокатят, нужно сослаться на какие-то источники. Наиболее частое объяснения хаоса царящего в их системе это «так писать короче». Наверное не нужно рассказывать, какие чудовищные выражения могут иметь смысл в Perl. Но, как я понимаю, не всегда короче — значит лучше. Почти каждая функция в системе представляет собой последовательный прогон комманд с убийством скрипта, если что-то не так.

В свете всего выше сказанного, может ли кто-нибудь посоветовать литературу или статьи о культуре правильного построения структуры кода в Perl? Желательно с комментариями и объяснениями. И вообще имеет ли это смысл с языком Perl, может я просто «не по адресу», а искать красоту и логику нужно в Pascal?

Буду признателен за помощь.

спустя 44 минуты [обр] Алексей Шейнюк[досье]
Для начала можно попробовать посмотреть perldoc Perl::Critic
спустя 9 часов [обр] Роман Чемисов(56/327)[досье]
Алексей Фёдоров[досье]
Что может быть лучше Perl Best Practices Великого и Ужасного Damian Conway?
спустя 8 часов [обр] Spectrum2(3/26)[досье]
http://search.cpan.org/~swalters/Object-PerlDesignPatterns-0.03/
Но. Perl сам по себе провоцирует программиста использовать весьма непонятные конструкции.
Это как поэзия. У каждого автора свой стиль, своя манера изложения.
Конечно, в Perl, как и в других языках есть вещи, которые лучше делать так, а не иначе, но ваши примеры, имхо, к ним не относятся.
спустя 37 минут [обр] Алексей Севрюков(198/1280)[досье]
сообщение промодерировано

Алексей Фёдоров[досье]

объявлять локальные переменные вначале блока или функции, а не по мере того как «за ухом зачесалось»;

так память под нее выделится сразу после объявления (это конечно не критично, но зависит от того что объявлять). Так что AFAIK лучше это делать перед использованием. Более того как мне кажется такой код легче читать, особенно если выносить независимые конструкции в отдельные блоки и объявлять эти переменные внутри них. Согласитесь, что:

for my $var(@array){...}

лучше чем:

my $var;
for $var(@array){...}
не выходить из функции досрочно в 10-и разных местах, а делать это естественным образом в конце;

ну это тоже весьма условно. Например, имеем функцию с одним обязательным параметром, если параметр не определен то и обрабатывать его не нужно, т.е.:

sub test(){
my $p=shift;
return unless defined $p;
# а дальше спокойно работаем с $p, она определена.
}
не убивать программу в случае возникновения ошибки;

тоже очень спорное утверждение. Консольную программу именно проще убить с указанием ошибки, и это и есть более правильный вариант, ИМХО. Неконсольное приложение при грубой ошибки тоже надо убивать, если дальнейшая работа невозможна, но хорошо бы вывести ошибку так, чтобы ее можно было увидеть без лога. Т.е. опять же все зависит от того о каких ошибках идет речь.

Последние два примера актуальны, согласен. Но, я не понимаю чего Вы хотите добиться. Утверждаете что они делают "не так", но реальных примеров не приводите. Вы покажите реальные куски кода, которые по Вашему мнению написаны не логично и неправильно, и уже на их примере можно рассматривать.

спустя 6 минут [обр] Алексей Севрюков(198/1280)[досье]

Spectrum2[досье]

Но. Perl сам по себе провоцирует программиста использовать весьма непонятные конструкции.

Непонятные конструкции это регулярные выражения и предопределенные переменные? ИМХО, только они могут немного вводить в заблуждение. При правильном же форматировании и комментировании кода и эти конструкции читаются относительно легко.

спустя 11 секунд [обр] Алексей Фёдоров(0/3)[досье]

Спасибо за ответы. Не могли бы вы оценить общие требования к программированию, которые я считаю верными? Я понимаю, что где-то могут быть приняты иные стили и стандарты, и как говориться «на вкус и цвет товарищей нет». Но для меня важно научить всю команду программировать в едином стиле, чтобы каждый участник проекта видя чужой код, воспринимал его как свой. Поэтому эти рекомендации я хотел бы использовать как базис. Говоря проще, мне интересно могут ли быть причины по которым какие-то из требований принципиально неприемлемы (например, в силу тормозов или глюков)? Что можете посоветовать?

Вот эти требования:

  1. Модули и классы должны иметь описание интерфейса (список имеющихся функций, пусть и в виде комментариев).
  2. Программы должны иметь чётко заданную структуру. Например: путь к интерпретатору, описание директив, описание модулей, описание констант, реализация функций, основное тело программы. Каждый блок должен отделяться разделителем, с соответствующим комментарием.
  3. Модули должны иметь чётко заданную структуру. Например: описание прагм, описание модулей, описание констант, описание интерфейса, реализация функций. Каждый блок должен отделяться разделителем, с соответствующим комментарием.
  4. Следует избегать использования глобальных переменных. Если глобальные переменные присутствуют, функция, работающая с ними, должна получать их из параметров.
  5. При возникновении ошибки в функции модуля, нельзя завершать работу скрипта досрочно.
  6. Каждая функция должна снабжаться однострочным комментарием, описывающим её работу на естественном языке. Сигнатура получаемых данных и возвращаемого результата должна быть очевидна из кода.
  7. Имя функции желательно должно состоять из названия действия и названия объекта над которым производится действие.
  8. Функции, действующие симметрично должны иметь симметричные названия.
  9. Не должно существовать функций, которые производят дополнительные действия, не очевидные из названия.
  10. Тело функции или программы должно быть структурировано в соответствии с истинностью проверяемых условий (декомпозиция), при таком подходе каждому событию (условие) должно быть сопоставленно определённое состояние (блок) и действие (выражения внутри блока).
  11. Если функция не может поместиться на 1,5-2 «экранах» значит её следует разбить на подфункции.
  12. Нужно стремиться к тому, чтобы из функции должна быть только одна точка возврата результата — в конце, срабатывающая при естественном его достижении.
  13. Реализация подфункций, используемых в текущей функции, должна находится перед текущей функцией и располагаться в хронологическом порядке вызовов.
  14. В операторах сравнения желательно первым делом сравнивать наиболее вероятные условия, и далее по уменьшению степени вероятности.
  15. Выражения не зависящие от инкремента в цикле должны вычисляться заранее перед циклом.
  16. Если данные последовательно обрабатываются в нескольких циклах, нужно попробовать объединить обработку в один цикл.
  17. Нельзя объявлять новые переменные внутри блока цикла.
  18. Если некоторое выражение более одного раза используется в операторах сравнения, это выражение должно быть вычислено заранее и храниться во временной переменной.
  19. Схожие строки кода идущие последовательно выравниваются по аналогичным элементам.
  20. Любые заранее определённые строковые или числовые значения должны быть вынесены в секцию констант.
  21. Программный код не должен иметь избыточных комментариев (допустим строки от предыдущего изменения кода).
  22. Если имеются большие участки кода с аналогичными действиями (например в тестах модулей), нужно использовать некий хорошо различимый разделитель.

Ещё раз заостряю внимание на том, что я понимаю, что в Perl можно вообще ничего из перечисленного не соблюдать, и компилятору чаще всего всё равно до этих правил. Вопрос в том, можно ли эти требования использовать как некий базис, или же тут есть принципиально неверные пункты.

Спасибо.

спустя 6 минут [обр] Алексей Фёдоров(0/3)[досье]
И ещё добавить захотелось: :)
  1. Если возможно принять в функцию список параметров, а не сложную структуру (например хэш), желательно сделать приём списка параметров.
спустя 18 минут [обр] Алексей Севрюков(198/1280)[досье]

Алексей Фёдоров[досье]

  1. Наверно имелся ввиду метод, а не функция?
  2. помоему многострочник с описанием входных и выходных параметров удобнее. Для модулей же вообще можно использовать отдельный pod.
  3. Название действия да, но причем тут название объекта? А если используется исключительно ООП?
  4. не осилил.

...

  1. очень спорно, не соглашусь. И экран - тоже понятие растяжимое. У меня на 24" в блокноте очень много кода умещается.
  2. Выше уже писал - не согласен. Это применимо лишь частично, Вы конечно можете предложить использовать кучу условных ветвлений, но мне кажется что это наоборот только ухудшит читабельность кода.
  3. Тоже спорно, мне кажется более логичным размещение сперва основных методов, а потом, приватных, к которым внешнего доступа нет. Опять же - если сложности с поиском приватных методов то помоему везде есть поиск, в одном файле все находится за несколько секунд.

...

  1. Это основы. Естественно нужно стараться оптимизировать код везде, где это возможно. Но мы ведь с Вами обсуждаем "внешний" вид и читабельность кода, а не оптимизации, так ведь?
  2. Почему? Цикл это тот же блок. Не согласен.
  3. Зависит от выражения, но опять же это ухудшит читабельность. И это тоже из области оптимизации.
  4. не осилил.
  5. а если переменная потом будет меняться, но ей надо присвоить какое то начальное значение?

...

  1. не осилил.

Естественно это все ИМХО.

спустя 39 минут [обр] Алексей Фёдоров(0/3)[досье]
  1. Ну метод, но может и функция. Насколько я знаю «правильных» объектов в Perl нет.
  2. Тут имеется ввиду объект не в терминологии ООП, а вообще.
  3. Например, есть функция возвращающая данные пользователя и функция устанавливающая данные пользователя. Логично назвать их get_user_info() и set_user_info(). Практика показывает, что и тут народ находит просторы для творчества и получается get_info_of_user() и set_system_user().
  4. Согласен формулировка «экран» размыта, но хуже было бы вводить конкретные численные показатели, типа «23 строки и ни строчкой больше».
  5. Это не должно восприниматься как догма.
  6. Ваше предложение и моё можно объединить.
  7. Мы с вами обсуждаем некие «общие стандарты создания логики программы», которые, в частности, могут учитывать оптимизацию. Если кто-то стремиться оптимизировать код, а кто-то никогда не задумывался об этом, они не будут писать одинаково, а нам нужно обратное. Мы тут немножко глубже копаем, чем просто стандарты оформления кода.
  8. Я согласен, что цикл это блок. Имелось ввиду, что определять переменные внутри условия цикла можно, а внутри блока цикла нежелательно, т. к. такая переменная будет объявляться на каждой итерации цикла.
  9. Сравните примеры:
$str    = substr($str,    $index, $length);
$my_str = substr($my_str, $index, $length);

и

$str = substr($str, $index, $length);
$my_str = substr($my_str, $index, $length);

В первом случае сразу бросается в глаза, что строчки кода аналогичны.

  1. Нет, это просто неточность формулировок. Имеются ввиду константы.
  2. Многие проблемы в Perl возникают при неправильном приёме сложных структур, это отнимает время и силы. Если можно получить любые данные линейным списком, это может избавить другого программиста от долгого изучения параметров. Например:

проще принять параметры:

($id, $settings_count, $settings_IP, $info)

чем структуру:

{
    'id'       => 1, 
    'settings' => {
        'count' => 34, 
        'IP'    => '127.0.0.1'}, 
    'info' => 'bla-bla-bla'};
спустя 2 часа 1 минуту [обр] Spectrum2(3/26)[досье]

Алексей Фёдоров[досье]Все не осилил, но хочу сказать, что я за демократию! А не за

научить всю команду программировать в едином стиле

И дело даже не в том, что Вы

Недавно устроился Perl-программистом в одну контору, и понял, что культура написания программного кода тут очень сильно хромает

 
и собрались там всех переучить, а в том, что каждый вправе программировать так как ему нравится/хочется/кажется правильным (я сейчас не говорю об откровенно плохом коде, да Алексей Фёдоров[досье] об этом тоже речь не ведет). Вы посмотрите модули на CPAN. Огромное разнообразие стилей, культур и т.д. Тот же CGI.pm посмотрите.

Вы, наверное, пришли в Перл СИ или Паскаль?

Алексей Севрюков[досье]

Непонятные конструкции это регулярные выражения и предопределенные переменные? ИМХО, только они могут немного вводить в заблуждение. При правильном же форматировании и комментировании кода и эти конструкции читаются относительно легко.

Мне кажется примеров можно много привести, в том числе и без предопределенных переменных:

sub { bless {} => shift }

Ну а комментирование кода - это отдельная история.

спустя 7 минут [обр] Алексей Севрюков(198/1280)[досье]

Алексей Фёдоров[досье]

  1. Даже если понятие "экран" определено - не вижу особого смысла разбивать большие функции на несколько маленьких. Особенно в тех случае где эти маленький функции больше нигде использоваться не будут.
  2. А если эти переменные на самом деле временные и актуальны только внутри блока? Опять же зависит от цикла и содержимого. Например, если мы прогоняем цикл по сложной структуре:
my @arr=[[1,2, {text=>1}],[3,4,{text=>2}]];
foreach my $row(@arr){
my $hash_ref=$row->[2];
print $hash_ref->{text};
}

то как мы видим, удобно использовать внутри цикла "синоним" для ссылки, чтобы не использовать конструкции типа $row->[2]{text}.
Естественно эта структура более менее простая и можно сделать и так, но на действительно сложных структурах с синонимам работать намного проще, чем с многоэтажными конструкторами. Тоже относится и к каким-нибудь временным переменным, хранящик некоторые временные значения, индивидуальные для каждой итерации цикла. Если же объявлять их в начале блока (не в цикле), то это создаст путаницу когда я начну искать где эта переменная объявленная и где еще она может использовать. Определение же ее в блоке сразу говорит о том, что она используется только в этом блоке. Опять же цикл это тот же блок, просто выполняющийся несколько раз.

  1. Осилил, согласен.

P.S. Я все-таки хотел бы увидеть живые куски кода, который Вы считаете неудовлетворительным.

Spectrum2[досье] Конструкция человеком с опытом читается без проблем, но оформлена действительно запутанно. Честно говоря даже не знаю кому в голову такое может придти ) По крайней мере я подобных конструкций ни разу не видел.

спустя 15 минут [обр] Spectrum2(3/26)[досье]
Алексей Севрюков[досье]Да ладно Вам, это ж из Perl Cookbook :)
спустя 45 минут [обр] Алексей Фёдоров(0/3)[досье]

Spectrum2[досье]
Я думал, коллективная работа над проектом с коллективным владенем кода в любом случае подразумевает наличие стандартов кодирования внутри команды. Объяснять преимущества этого подхода не буду, об этом было много написано и сказано. В данном случае речь шла о вынесении этих рекомендаций на общее обсуждение и внедрение в случае одобрения. Демократия должна быть, анархия — нет. То что вы называете демократией (каждый пишет как хочет), это и есть анархия. Тот, кто хочет писать как хочется, должен быть готов работать в одиночку. И даже «ИМХО» писать не хочется, спросите у Фредерика Брукса, Кена Ауэра или Роя Миллера, они подтвердят. :)

Я программирую на Perl много лет. А рекомендации по написанию программ в Object Pascal просто считаю эталоном правильного подхода к кодированию (отнюдь, не претендую на то, что это истина).

Алексей Севрюков[досье]

  1. Если функция большая затрудняется её понимание. Разбивание функций на подфункции помогает переходить от общего к частному (нисходящее программирование). Программист, который будет потом читать код сначала сможет понять, что вообще делается в целом, потом перейти к деталям и пр. Одна большая функция на 4 «экрана» может быть и работать будет быстрее, но не каждый сразу же сможет понять основной замысел происходящего, спотыкаясь о частности.
  2. Спорный момент, согласен. Но всё же по-моему ваш пример — редкий случай. :)
спустя 13 минут [обр] Алексей Севрюков(198/1280)[досье]

Алексей Фёдоров[досье]

  1. Речь же шла об одном экране, а Вы уже про 4 заговорили. Я таких функций и не видел даже.
  2. Может быть и редкий, но я постоянно со сложными структурами работаю именно так и очень часто внутри цикла использую локальные переменные.

Spectrum2[досье] Странно, неоднократно от корки до корки "читал" и как то не замечал. Перечитаю еще раз )

спустя 2 минуты [обр] Алексей Фёдоров(0/3)[досье]
Алексей Севрюков[досье]
Пытался найти для вас пример, везде слишком много уникальных фирменных названий, я не могу светить этим в Сети. Сидеть и править тоже не хочется, тем более что может пострадать логика. Если как-нибудь увижу независящий от этого пример — покажу. А вообще лучше показывать целый модуль, но это ещё сложнее.
спустя 2 минуты [обр] Алексей Севрюков(198/1280)[досье]
Алексей Фёдоров[досье] Это необязательно, просто мне лично очень интересно посмотреть на живой пример. Если найдете - шлите на почту, почитаю на досуге.
спустя 4 минуты [обр] Алексей Фёдоров(0/3)[досье]
Алексей Севрюков[досье]
  1. О четырёх экранах это гипербола, чтобы подчеркнуть сказанное. :) Думаю, вы поняли общую мысль. То что таких функций нет, не говорит о том, что кто-то не захочет такое написать когда-нибудь. Кстати, сказать у меня такие функции были, когда по требованию заказчика с формы нужно было получить 157 параметров. Но тут в силу линейности происходящего это «правило» отпадает.
  1. Возможно. Я лично всегда стремился к простоте структур (неспроста, а по совету одного учебника Perl), потому случаев описанных вами в своей практике не использовал. Опять таки, не претендую на то, что я однозначно прав в этом.
спустя 31 секунду [обр] Алексей Фёдоров(0/3)[досье]
Алексей Севрюков[досье]
Ладно, пошлю на почту. :)
спустя 10 минут [обр] Алексей Севрюков(198/1280)[досье]

Алексей Фёдоров[досье]

  1. Ну невозможно, например, тот же самый XML представить в простой структуре. А с ним приходится работать относительно часто. Да что говорить, ведь простейший пример:
while( my($k,$v) = each(%ENV) )
 {
   print "$k=$v\n";
 }

так же использует локализованные переменные в цикле. А так помоему делает подавляющее большинство.

спустя 18 минут [обр] Алексей Фёдоров(0/3)[досье]

Алексей Севрюков[досье]
То ли я вас не понимаю то ли вы меня. Я ничего не имею против примерно такого:

for (my $i; $i < 10; $i++) {
    ...
}

В условии цикла определяется переменная $i. Такие переменные работают даже быстрее. Но я думаю, что такой подход не вполне корректен:

while ($a > $b) {
    my $Temp = ...;
    ...
}

В блоке цикла определяется переменная $Temp. Не знаю точно как в Perl, но во многих языках инициализация занимает некоторое время, потому инициализировать переменную лучше заранее. Но тут по-моему дело даже не в скорости, а в логичности происходящего. Это всё равно что каждый день заново принимать на работу нового сотрудника (пусть даже того же самого) для выполнения некой работы, вместо того, чтобы один раз принять его и использовать некоторое время. Потому, мне кажется, логичнее было бы сделать так:

my $Temp = ();
while ($a > $b) {
    $Temp = ...;
    ...
}
спустя 2 минуты [обр] Алексей Фёдоров(0/3)[досье]

В первом примере допустил ошибку, нужно было так:

for (my $i = 1; $i < 10; $i++) {
    ...
}

ну не важно...

спустя 8 часов [обр] Alexander O(122/460)[досье]
Алексей Фёдоров[досье]
конечно, на инициализацию переменной время тратится, но в большинстве случаев этим временем можно пренебречь.
Гораздо важнее то, что при объявлении переменной вне цикла ее область видимости вылезает за пределы блока цикла. И потом думай, предусмотрено ли использование этой переменной где-то ниже по коду.
Так что я за то, чтобы выносить объявления переменныых вне цикла только в исключительных случаях, с комментариями, почему это сделано.
спустя 19 минут [обр] Alexander O(122/460)[досье]
здесь довольно полное обсуждение
I need perl coding standards
спустя 6 часов [обр] Алексей Севрюков(198/1280)[досье]
Alexander O[досье] собственно об этом я писал выше:
Если же объявлять их в начале блока (не в цикле), то это создаст путаницу когда я начну искать где эта переменная объявленна и где еще она может использоваться. Определение же ее в блоке сразу говорит о том, что она используется только в этом блоке.
спустя 43 минуты [обр] Алексей Фёдоров(0/3)[досье]
Алексей Севрюков[досье], Alexander O[досье]
Если принято объявлять переменные до цикла, путаницы с их поиском наверное не будет (люди будут знать, где искать). Вот с увеличением области определения согласен, это резонное замечание. Если стремиться к тому, что у каждой переменной область определения должна быть минимальна, то мой подход не оправдан.
спустя 6 часов [обр] Thirteensmay(15/157)[досье]

Алексей Фёдоров[досье] Знаете, в этом плане очень легко быть начальником, указывать всем что есть хорошо и что плохо, устанавливать правила и определять стандарты... СВОИ... И Вам даже будет казаться что стало лучше, и для Вас и вправду станет лучше, веть это Ваши стандарты, образ мышления, привычки...

Не в коем случае не хочу сказать что то что Вы задумали неправильно и бесполезно. Правильно и полезно, но не переборщите ! Большинство программистов и так знают что все что Вы описали в общем случае правильно, в теории, однако на практике существуют такие понятия как недостаток времени, усталость, привычки, пр... С пунктами 5, 9, 11, 12, 13, 17, 19, 23 в той или иной мере несогласен, к сожалению нет времени обстоятельно обосновать, просто обратите на них внимание.

Вижу что Вы пытаетесь выделить лишь общие черты, правильно, но повторю - не переборщите. Вот взгляните например сюда: Идентификация массива Как бороться ? структура кода идеальна ;)

Думаю в первую очередь надо обращать внимание на архитектуру и логику приложения, а уж только потом на структуру кода. И пусть они будут как можно проще, в этом случае куча тупого кода проблемы не создаст. Понимать приложение по коду не лучший вариант, для этого существуют более подходящие решения, см. UML и соответствующие диаграммы.

Продумайте и включите в Ваш список пункты проясняющие именно это вопрос. Например требование создания для каждого более менее значимого структурного элемента краткого технического описания, схемы структуры/взаимодействия и т.п. Думаю будет полезно, по крайней мере я всегда начинаю знакомство с новой системой с вычерчивания схем, тупо карандашиком, и код при этом становится не так страшен, так проще...

К сведению: В стандартах разработки ИС и ПО на документирование как правило отводится времени больше чем на проектирование и разработку как таковую вместе взятые... Не решите Вы этой проблемы одной только структурой кода, думайте сами ;)

спустя 2 часа 14 минут [обр] Алексей Севрюков(198/1280)[досье]

Thirteensmay[досье] На самом деле я практически уже во всем согласился с автором после того как увидел код. Логика конечно есть и структура кода вполне нормальная (хотя есть конечно не вполне конкретные), но вот оформление действительно просто ужос...

IMHO, желание автора вполне нормально - работать с нормальным кодом. Ведь от скорости чтения и понимания кода зависит и КПД работы, не так ли? С некоторыми пунктами действительно перебор, но они все были уже обсуждены и некоторые взгляды автор поменял. Осталось дело за малым - привить "правила хорошего тона" остальным программистам.

P.S. Показать код или даже куски не имею права, так как дал слово о неразглашении, но можете поверить мне на слово.

спустя 4 дня [обр] Алексей Фёдоров(0/3)[досье]

Thirteensmay[досье]
Я понимаю, что есть соблазн всё «заточить» под себя и психологически эта тяга присутствует во мне и сейчас. Тем не менее как-то создать свод соглашений нужно, и начать так же с чего-то нужно. Я потому и вынес свои личные взгляды на всеобщую оценку, чтобы после некоего фильтра осталось нечто более менее абсолютное. Допускаю так же, что я был в чём-то неправ, т. к. мои программистские пристрастия воспитывались в достаточно замкнутой среде.

Если вы не согласны с какими-то пунктами, пожалуйста, скажите почему. Потому что если ответ на эти пункты представляет собой что-то вроде «я так не привык» или «мы всегда делали иначе» — это как раз и будет личными пристрастиями. Какие-нибудь логические обоснования будут очень интересны.

спустя 5 минут [обр] Алексей Фёдоров(0/3)[досье]

Кстати, вот ещё одно «кредо», которое я всегда соблюдал: использование бесконечных циклов, с принудительным выходом из них по какому-либо условию — это дурной тон.

Вы согласны с этим?

(Опят-таки, понимаю, что всё зависит от случая, но я имею ввиду некий общий случай «вообще» и общие рекомендации)

спустя 5 часов [обр] Алексей Севрюков(198/1280)[досье]
Алексей Фёдоров[досье] Вы снова говорите абстракциями. Смотреть надо какие то конкретные примеры, потому что в некоторых частных случаях вполне допустимы бесконечные циклы. Хотя, с другой стороны можно ведь все условия окончания цикла указать в условиях, а не писать например, while(1). Но опять же, при большом количестве условий выхода из цикла удобнее писать их в теле - читать такой код будет проще.
спустя 11 часов [обр] Алексей Фёдоров(0/3)[досье]
Эх... :)
спустя 3 часа 48 минут [обр] Thirteensmay(15/157)[досье]

"В некоторых частных случаях вполне допустимы бесконечные циклы, при большом количестве условий выхода из цикла удобнее писать их в теле - читать такой код будет проще"

>> И часто он будет более эффективным. Здесь ситуация аналогична goto, редко, но бывает полезно. Как пишут в классической литературе для выхода из глубоко вложенных условно-циклических структур. Ну Вы наверное скажете что нельзя так программы строить, что надо ... и т.д., и будете отчасти правы. Я уже говорил, производительность, недостаток времени, привычки, делают свое дело, и в отличии от теории они реальны. Тоже самое с 12 пунктом.
Конечно всегда надо стремится к простоте и логической стройности, часто декомпозиции, в этом Ваши подходы абсолютно верны. Другое дело это не всегда получается.

5 - Согласен, но это влечет требование проверок возвращаемого результата/обработки исключений, что несколько усложняет код/затраты на разработку. Вы готовы за это заплатить ? Окупится ? Думаю не всегда, особенно при небольших масштабах.

9 - Хм, из названия run() вовсе не очевидно что пишется какой нить pid файл, однако есть такая составная часть/подфункция, и это логично. Я понял что Вы имели ввиду, но получилось както жестковато/глуповато, думаю тут надо просто переформулировать, чтото из области "обзывайте функции по делам их", "не мешайте котлеты с мухами" ;)

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

13 - Наверное скорее вопрос привычки, я например считаю наоборот. Лучше сначала увидеть вызов функции, понять что она есть, и как используется, а уж потом при необходимости посмотреть реализацию, чем просматривать килобайты фиг знает чего в поисках чегонить понятного. А понятное это как правило высокоуровневые функции, вот они и должны быть первыми. По поводу хронологического порядка - думаю лучше в порядке логической значимости, а если много равнозначных то по алфавиту.

17 - По поводу локальных временных переменных типа ссылок или расчетных коэффициентов уже сказано, думаю неудобно путаться ища их в других местах. Что же касается постоянного "переобъявления" то глобальные ессно не переопределяются, а если с my то не испытывал от этого проблем ниразу, оно на сколько я понимаю достаточно оптимизировано.

19 - Дело вкуса, и это не всегда красиво, удобочитаемости не сказал бы что сильно добавляет, а вот гемороя клаву топтать уж точно.

23 - В общем случае согласен, сам так считаю, но думаю надо уважать привычки других, Вы же хотите чтобы уважали Ваши ? ;) Просто некоторым такой подход кажется более наглядным, бог с ними, не особо напрягает, а когда параметров много то даже появляется смысл.

Думаю Вам надо разделить ваш список на 2 раздела: "Требования" и "Рекомендации". Ведь есть же пункты которые не вызывают споров ;)

Заметьте, чем большее количество нюансов вы пытаетесь охватить тем более ваши требования становятся размытыми и соответственно теряют смысл. Люди разрабатывающие ЯП тоже не просто так, если какая-либо возможность реализована, значит это комуто было нужно. Все мы пытаемся балансировать между стройностью, читай строгостью, и удобством, читай свободой, но это в значительной мере взаимоисключающие вещи, так что пилите Алексей, пилите... ;)

Powered by POEM™ Engine Copyright © 2002-2005