Чому приклади масивів PHP залишають кінцеву кому?

Я бачив такі приклади:

$data = array(
   'username' => $user->getUsername(),
   'userpass' => $user->getPassword(),
   'email' => $user->getEmail(),
);

Однак на практиці я завжди не залишав кінцевої коми. Я роблю щось не так, чи це просто "інший" спосіб це зробити? Якби я використовував фреймворк, чи не матиме кінцева кома негативно впливати на генерацію коду? Я також бачив використання кінцевих коми в оголошеннях масивів іншими мовами (Java, C ++), тому я припускаю, що причини залишення кінцевих коми не є специфічними для PHP, але це викликало у мене інтерес.

Чому приклади масивів PHP залишають кінцеву кому?

Тому що вони можуть. :) Введення вручну PHP для станів масиву :

Наявність кінцевої коми після останнього визначеного запису масиву, хоча і є незвичним, є допустимим синтаксисом.

Серйозно, це цілком для зручності, тому ви можете легко додати до масиву ще один елемент без необхідності попередньо додавати кінцеву кому до останнього запису.

Говорячи про інші мови: будьте обережні з цим у JavaScript. Деякі старіші браузери видають помилку, хоча новіші зазвичай дозволяють.

Це хороша практика при визначенні масиву на декількох рядках. Це також заохочується стандартами кодування ZendFramework :

Використовуючи останню декларацію, радимо використовувати кінцеву кому для останнього елемента масиву; це мінімізує вплив додавання нових елементів на послідовні рядки та допомагає забезпечити відсутність помилок синтаксичного аналізу через відсутність коми.

Я помітив під час роботи з контролем версій (git), що якщо ми додамо 1 річ до масиву, а у нас немає кінці, що здається, це буде виглядати так, ніби ми змінили 2 рядки, тому що кома мала бути додана до попереднього рядка. Я вважаю, що це виглядає погано і може ввести в оману при перегляді змін файлу, і з цієї причини я вважаю, що завершальна кома - це добре.

Тому що він підтримує уніфікованість записів.

Якщо вам довелося поміняти місцями замовлення або додати чи видалити записи, ви знаєте, що можливість залишити кінцеву кому дуже зручна.

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

Дозволяючи кінцеву кому на останньому елементі, це звільняє програміста від необхідності схилятися до цієї прикрої і безрезультатної деталі.

Причиною є зміни комітів.

Якщо вам потрібно додати завершальну кому при додаванні нового елемента. Ви міняєте 1 рядок і додаєте 1 рядок. (- ++)

При додаванні нового елемента, коли кома вже є у рядку вище. Додано лише 1 доданий рядок, а жодного не змінено. (+)

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

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

Я завжди роблю кінцеву кому, оскільки це допомагає уникнути синтаксичних помилок при додаванні нових елементів масиву ... це просто хороша практика.

Якщо ви подивитесь на приклад конфігурації файлу roundcube (config.inc.php), у них є приклад із кінцевою комою та без неї.

Цей масив визначає, які плагіни слід увімкнути чи вимкнути:

...
// List of active plugins (in plugins/ directory)
$config['plugins'] = array(
'managesieve',
'password',
'archive',
'zipdownload',
);
...

Зазвичай це буде рядок за рядком, і якщо хтось хоче додати щось у масив, він може зробити це:

...
// List of active plugins (in plugins/ directory)
$config['plugins'] = array(
'managesieve', //code by personA
'password', //code by personA
'archive', //code by personA
'zipdownload', //code by personA
'newplugin', //new code by personB
);
...

Отже, коли вони фіксують цей код, вони бачать лише одні зміни для цього конкретного рядка, і це стає більш читабельним при перевірці, хто вносить зміни в код для цього конкретного рядка.

В іншому рядку коду ви можете побачити це без кінцевої коми:

...
$config['default_folders'] = array('INBOX', 'Drafts', 'Sent', 'INBOX.spam', 'Trash');
...

Зазвичай це один рядок коду, де ніхто не очікує частого зміни цього коду.

Іншим словом:

1) Поставте завершальну кому, якщо масив використовується як параметр або файл конфігурації, який, можливо, доведеться динамічно змінювати в майбутньому. Крім того, якщо ви вносите зміни в цей масив програмно, використовуючи кінцеву кому, ви вносите зміни лише до одного рядкового коду, тоді як без нього вам доведеться мати справу з 2-ма рядковими кодами, і це може призвести до складності синтаксичного аналізу масиву.

2) Вам не потрібно ставити завершальну кому, якщо масив є постійним масивом, і ви не очікуєте, що він зміниться в майбутньому, але, як згадується у прийнятій відповіді, ви можете поставити завершальну кому, але це не має мети

Це мене нещодавно здивувало, але це має сенс. Я давно намагався дотримуватися попередньої конвенції, яка робить те саме, тобто ставити розділювальну кому перед кожним записом, а не в кінці.

$data = array(
   'username' => $user->getUsername()
 , 'userpass' => $user->getPassword()
 , 'email' => $user->getEmail()
);

Коми також всі вибудовуються таким чином, що виглядає приємно, але це може зробити відступ трохи незручним. Можливо, з цієї причини, здається, це не зачепило багато років, і у мене були інші, хто запитував мене, чому я це роблю. Я думаю, що рішення PHP є хорошим компромісом, і в будь-якому випадку це, мабуть, прийняте рішення зараз.

Я завжди додавав коми на початку нового запису. Компілятори розглядають це як односимвольний знак перспективи, який говорить, що "є ще один". Я не знаю, чи використовують сучасні компілятори LR (1) (ліворекурсивний одиночний маркер вперед), але я думаю, що саме тут виникає синтаксична помилка, коли кома після неї нічого не має. Рідко коли-небудь доводилося, щоб інший розробник погоджувався зі мною, але схоже, що це робить JohnBrooking!