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

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

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

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

Здравствуйте, alex_ant, Вы писали:

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

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

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

Code Complete Стива МакКонела читал (в переводе "Совершенный код")

_>— объявлять локальные переменные вначале блока или функции, а не по мере того как «за ухом зачесалось»;
Объявлять локальные переменные надо там, где они понадобятся. Если, конечно, язык такое позволяет. Perl точно позволяет.

_>— не выходить из функции досрочно в 10-и разных местах, а делать это естественным образом в конце;
Зависит от. Если лучше читается код который выходит в 10 местах — то пусть выходит в 10 местах.

_>— не убивать программу в случае возникновения ошибки;
Если возникла ошибка которая могла возникнуть только при нарушении целостности логики программы — то, наверное, убитие программы и есть самый верный способ. "Выжить любой ценой" — это только для очень специальных систем.

_>— выносить за пределы цикла выражения не зависящие от инкремента;
Тоже вообщем-то не самоцель. Для большинства современных компиляторов компилятор это сделает сам. Не уверен насчёт Perl — но и тут следует не переусердствовать и не пожертвовать читаемостью в целях предварительной оптимизации.

_>— в операторах сравнения сначала проверять наиболее вероятные условия и пр.
Не вижу никакого смысла в проверке наиболее вероятного условия в начале. Такой подход, ИМХО, оправдан только для ассемблера или для очень древних и убогих компиляторов. Перлу наверняка абсолютно всё равно в каком порядке идут условия. Тут тоже читаемость кода — основной критерий.

Здравствуйте, Left2, Вы писали:

Т. е. давайте доверимся компилятору и будем писать как попало? А точнее так, как каждому кажется удобнее?

P. S. Всегда прикалывали гении программирования, не способные внимательно прочесть пост и осмыслить вопрос темы. Если не заметили, я не просил оценить примеры из моего поста, я спрашивал о литературе, способной описать преимущества подходов. Самомнение, распираемое изнутри, мешает размышлять по делу? Ваши ценные взгляды на программирование были услышаны, возрадуемся.

_>P. S. Всегда прикалывали гении программирования, не способные внимательно прочесть пост и осмыслить вопрос темы. Если не заметили, я не просил оценить примеры из моего поста, я спрашивал о литературе, способной описать преимущества подходов. Самомнение, распираемое изнутри, мешает размышлять по делу? Ваши ценные взгляды на программирование были услышаны, возрадуемся.

Хамите, милейший?
Что ж, анонимность инетрнета позволяет. Желаю по мере взросления поумнеть.

Здравствуйте, Left2, Вы писали:

L>Хамите, милейший?
Простите, вырвалось. Терпеть не могу, когда вместо того, чтобы ответить на чётко поставленный вопрос, начинают «блистать умом» на уровне пьяных посиделок.

Здравствуйте, alex_ant, Вы писали:

_>Здравствуйте, Left2, Вы писали:

_>Т. е. давайте доверимся компилятору и будем писать как попало? А точнее так, как каждому кажется удобнее?

_>P. S. Всегда прикалывали гении программирования, не способные внимательно прочесть пост и осмыслить вопрос темы. Если не заметили, я не просил оценить примеры из моего поста, я спрашивал о литературе, способной описать преимущества подходов. Самомнение, распираемое изнутри, мешает размышлять по делу? Ваши ценные взгляды на программирование были услышаны, возрадуемся.

с.п. — это не догма, а инструмент увеличивающий читабельность и надёжность кода. рекомендации, которые ты приводил — это не истина в послекдней инстанции, и Left2 тебе как раз принялся объяснять почему они могут быть неверны. однако тебе не зватает опыта чтобы самому об этом судить, ты пока что доверяешь только книгам, написанным авторитетами

не зависящие от языка стандарты де-факто типа:
_>— объявлять локальные переменные вначале блока или функции, а не по мере того как «за ухом зачесалось»;
_>— не выходить из функции досрочно в 10-и разных местах, а делать это естественным образом в конце;
_>— не убивать программу в случае возникновения ошибки;
_>— выносить за пределы цикла выражения не зависящие от инкремента;
_>— в операторах сравнения сначала проверять наиболее вероятные условия и пр.

бу-га-га. случайное образование (твоё или твоих учителей) слило воедино праивла микрооптимизации программ и советы по улучшению читабельности

_>В свете всего выше сказанного, может ли кто-нибудь посоветовать литературу или статьи о культуре правильного построения структуры кода?

http://www.rsdn.ru/article/mag/200401/codestyle.XML

Кое-что из упомянутого вами там освещено

Здравствуйте, alex_ant, Вы писали:

_>P. S. Всегда прикалывали гении программирования, не способные внимательно прочесть пост и осмыслить вопрос темы. Если не заметили, я не просил оценить примеры из моего поста, я спрашивал о литературе, способной описать преимущества подходов.

Но если нет преимуществ, то литературы об этих преимуществах нет уж и подавно.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>с.п. — это не догма, а инструмент увеличивающий читабельность и надёжность кода. рекомендации, которые ты приводил — это не истина в послекдней инстанции, и Left2 тебе как раз принялся объяснять почему они могут быть неверны. однако тебе не зватает опыта чтобы самому об этом судить, ты пока что доверяешь только книгам, написанным авторитетами

Ясен пень, что это не догма и не истина в последней инстанции. Я это понимаю. Более того, истин в последней инстанции вообще не бывает. Я просто привёл примеры, но вместо этого, лишь один человек посоветовал книгу, остальные прицепились к формулировкам.

Если рассуждать как Left2 «всё зависит от случая» — можно ответить абсолютно на любой вопрос. Я понимаю, что всё зависит от случая, но тем не менее некие рекомендации есть, более того, коллективное владение кодом подразумевает единые рекомендации для всей команды.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>бу-га-га. случайное образование (твоё или твоих учителей) слило воедино праивла микрооптимизации программ и советы по улучшению читабельности

Случайные правила, это лучше чем случайное отсутствие правил.

Здравствуйте, Lloyd, Вы писали:

L>Но если нет преимуществ, то литературы об этих преимуществах нет уж и подавно.
Мы наверное живём на разных планетах и читаем разные книжки.

Здравствуйте, alex_ant, Вы писали:

_>Здравствуйте, Lloyd, Вы писали:

L>>Но если нет преимуществ, то литературы об этих преимуществах нет уж и подавно.
_>Мы наверное живём на разных планетах и читаем разные книжки.

Не исключено.

Здравствуйте, Lloyd, Вы писали:

L>Но если нет преимуществ, то литературы об этих преимуществах нет уж и подавно.

да просто завались всяких … книжек (а, особенно, статей в сети), в которых не весть что советуют и которые читать крайне вредно для незамутнения рассудка и вот найдёт же какой-нибудь такую и станет на неё ссылаться повсюду и не сдвинешь его: "вон, посмотри, в инете народ советует!"

Здравствуйте, alex_ant, Вы писали:

_>Здравствуйте, BulatZiganshin, Вы писали:

BZ>>бу-га-га. случайное образование (твоё или твоих учителей) слило воедино праивла микрооптимизации программ и советы по улучшению читабельности

_>Случайные правила, это лучше чем случайное отсутствие правил.

Согласен. "Лучше безобразно, но единообразно", как любил говаривать подполковник Схаба

Мне кажется, что если есть готовые правила, то стоит подстраиваться под существующие. Если нет, то надо утвердить общие. Причем их общность более ценна, чем их качество.

Нет ли для перла уже готовых принятых сообществом правил? Например, для Java, Python, C# есть готовые от производителей

Вот еще разные правила Примеры правил кодирования

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

Мартин Фаулер "Рефакторинг"

P.S. И поддерживаю Left2, сам хотел такое написать

Здравствуйте, no4, Вы писали:

no4>Мне кажется, что если есть готовые правила, то стоит подстраиваться под существующие. Если нет, то надо утвердить общие. Причем их общность более ценна, чем их качество.

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

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

Здравствуйте, alex_ant, Вы писали:

_>Недавно устроился Perl-программистом в одну контору, и понял, что культура написания программного кода тут очень сильно хромает. Каждый пишет программный код как может, отсутствуют какие-либо соглашения и внутренние стандарты. Учитывая что команда работает по методологии Scrum (стандарты и коллективное владение кодом), всё это не может не угнетать.

_>Причём я не имею ввиду такое понятие как правильное оформление кода (отступы и скобки), я имею ввиду такие не зависящие от языка стандарты де-факто типа:

Не соглашусь в пункте "не зависящие от языка стандарты де-факто". Буду краток: С++.

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

В С++, например, от расположения (и, как следствие, инициализации) переменных зависит семантика.

Ещё, как уже сказал Left2, сокращение дистанции между определением и использованием уменьшает риск использования переменных не по делу.

Чем локальнее переменная, тем строже программа — но, конечно, следование такому идеалу приведёт к появлению кучи лишних вложенных блоков.
Впрочем, это повод задуматься о рефакторинге.

На самом деле, дилемма — где объявлять переменные, в начале или в гуще — означает совсем другое.
Для маленьких блоков это некритично. А вот для гигантских, в пару-тройку-десяток страниц...
Вот это — точно повод задуматься о рефакторинге.

_>— не выходить из функции досрочно в 10-и разных местах, а делать это естественным образом в конце;

Та же самая история.
Либо код конкретной функции содержит только логику ветвления — и тогда пусть он даже в десяток страниц, все return'ы отчётливо видны, и главное, понятно, при каких условиях достижимы.
Либо код содержит густые вычисления — тогда очень желательно, чтобы структура control flow была как можно более простой.

Если же вперемешку — вот тут всё и начинается.

_>— не убивать программу в случае возникновения ошибки;

А в вашей фирме есть какие-то общие взгляды на обработку ошибок разной природы?
Советую коллективно помедитировать над этим, в дальнейшем получите кучу бонусов.
Что-то можно и нужно логгировать, что-то — восстанавливать, и т.д. и т.п.
В каких случаях сокращённый control flow (вылет по исключению или внезапный return) полезен, а в каких — нужно ветвиться.

Возможно, что необходимый минимум — это вместо die использовать функцию (или несколько) с аналогичной ролью, но с более разнообразным поведением.

Посмотрите на уже известные решения — log4perl и прочее. Чтобы, во-первых, было с чего черпать вдохновение, а во-вторых, чтоб, когда договоритесь, не начать изобретать велосипед.

_>— выносить за пределы цикла выражения не зависящие от инкремента;
_>— в операторах сравнения сначала проверять наиболее вероятные условия и пр.

Правильно, но без фанатизма.
Если в угоду premature optimization пострадает читаемость кода — вряд ли скажут спасибо.
Нужно профилировать, профилировать, профилировать.

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

1) Если люди вменяемые, то попробуйте совместно выработать общие правила, а не насильно прививать то, что одному кажется наилучшим.
Насилие порождает насилие. Ты им — идеальное оформление и идеальную структуру, а они тебе — quick-n-dirty. На их стороне численный перевес, так что готовься к тому, что через месяц, после длительной истерики, сам начнёшь писать QnD.

2) Если "старую собаку не научишь новым трюкам", то придётся смириться.

И всё-таки, перл — это скриптовый язык. Он изначально заточен под QnD, и этим можно пользоваться. При условии, что QnD локально.

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

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