Являются ли последние запятые в Perl плохой практикой?

Сегодня я был на собрании Webex, показывающем свой экран с некоторым кодом Perl, который я написал. Мой босс внезапно сказал мне, пока все остальные смотрят и слышат, что мне пришлось удалять конечные запятые из моих хэш-структур и массивов, потому что это плохая практика. Я сказал, что не думал, что это была плохая практика в Perl, но он настоял и заставил меня удалить эти запятые только, чтобы показать мой script, работающий на собрании.

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

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

Итак, неуместно ли оставлять конечные запятые?

Это пример:

my $hash_ref = {
    key1    => 'a',
    key2    => 'b',
    key3    => 'c',
};

my $array_ref = [
    1,
    2,
    3,
];

Ответы

Ответ 1

Отличная практика - использовать запятую. Ларри добавил это, потому что видел, как программисты добавляют элементы в список (или как там их называют языки, но забывают символ разделителя. Perl позволяет использовать запятую, чтобы сделать это менее распространенным. Это не причуда или побочный эффект чего-то еще. Это то, что Perl хочет, чтобы ты сделал.

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

Ответ 2

Таким образом, страница PBP, на которую ссылается Миллер, утверждает, что упростить переупорядочение списка проще, обрезая и вставляя строки; документ стиля кодирования mod_perl, связанный Бородиным, утверждает, что нужно избегать кратковременной синтаксической ошибки при добавлении материала.

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

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

Ответ 3

В документе стиля Apache mod_perl говорится об этом

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

То, что ваш менеджер, возможно, думал о том, что выполнение того же самого в C является нестандартным и не переносным, однако нет оправдания его необычайному поведению.

Ответ 5

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

my $hash_ref =
  { key1    => 'a'
  , key2    => 'b'
  , key3    => 'c'
  };

my $array_ref = 
  [ 1
  , 2
  , 3
  ];