Dlaczego przykłady tablic PHP zostawiają końcowy przecinek?

Widziałem przykłady takie jak następujące:

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

Jednak w praktyce zawsze nie zostawiałem końcowego przecinka. Czy robię coś złego, czy to tylko „inny” sposób na zrobienie tego? Gdybym używał frameworka, czy końcowy przecinek nie miałby negatywnego wpływu na generowanie kodu? Widziałem użycie końcowych przecinków w deklaracjach tablicowych w innych językach (Java, C ++), więc zakładam, że powody pozostawiania końcowych przecinków nie są specyficzne dla PHP, ale to wzbudziło moje zainteresowanie.

Dlaczego przykłady tablic PHP zostawiają końcowy przecinek?

Ponieważ mogą. :) Ręczny wpis PHP dotyczący stanów tablic :

Umieszczanie końcowego przecinka po ostatniej zdefiniowanej pozycji tablicy, mimo że jest niezwykłe, jest prawidłową składnią.

Poważnie, jest to całkowicie dla wygody, więc możesz łatwo dodać kolejny element do tablicy bez konieczności uprzedniego dodawania końcowego przecinka do ostatniego wpisu.

A propos innych języków: uważaj na to w JavaScript. Niektóre starsze przeglądarki generują błąd, chociaż nowsze generalnie na to pozwalają.

Jest to dobra praktyka podczas definiowania tablicy w wielu wierszach. Zachęcają do tego również standardy kodowania ZendFramework :

Korzystając z tej drugiej deklaracji, zachęcamy do używania końcowego przecinka dla ostatniego elementu tablicy; minimalizuje to wpływ dodawania nowych elementów w kolejnych wierszach i pomaga uniknąć błędów analizy z powodu brakującego przecinka.

Podczas pracy z kontrolą wersji (git) zauważyłem, że jeśli dodamy 1 rzecz do tablicy i nie mamy końcowego przecinka, będzie to wyglądać tak, jakbyśmy zmodyfikowali 2 linie, ponieważ przecinek musiał zostać dodany do poprzedniego wiersza. Uważam, że wygląda to źle i może być mylące, gdy patrzę na zmiany pliku, iz tego powodu myślę, że przecinek na końcu jest dobrą rzeczą.

Ponieważ zapewnia jednolite wpisy.

Jeśli musiałeś zamienić zamówienie lub dodać lub usunąć wpisy, wiesz, że pozostawienie końcowego przecinka jest bardzo wygodne.

Jeśli ostatni element nie może mieć przecinka, w końcu musisz zachować ostatni przecinek, modyfikując wpisy. To bezcelowe ćwiczenie, strata czasu i ruchów palcami, ponieważ zamiar zamiany lub modyfikacji wpisów został już osiągnięty.

Dopuszczając końcowy przecinek na ostatnim elemencie, uwalnia programistę od konieczności zajmowania się tym irytującym i bezowocnym szczegółem.

Powodem jest zatwierdzanie zmian.

Jeśli musisz dodać końcowy przecinek podczas dodawania nowego elementu. Zmieniasz 1 linię i dodajesz 1 linię. (- ++)

Podczas dodawania nowego elementu, gdy przecinek jest już w linii powyżej. Jest tylko 1 dodana linia i żadna zmieniona. (+)

Nie mogę mówić w imieniu innych osób, ale zazwyczaj zostawiam w kodzie przecinek na końcu. Robię to, ponieważ jeśli / kiedy później dodam do tablicy, nie muszę się martwić o pominięcie przecinka z powodu zapomnienia o dodaniu przecinka do tego, co wcześniej było ostatnim wierszem.

Uważam, że chociaż jest to dozwolone, jest to zła praktyka, to tak jakby pominąć ostatni średnik z funkcji i pętli.

Zawsze robię końcowe przecinki, ponieważ pomaga to uniknąć błędów składniowych podczas dodawania nowych elementów tablicy ... to po prostu dobra praktyka.

Jeśli spojrzysz na przykład konfiguracji pliku roundcube (config.inc.php), zobaczysz przykład zi bez końcowego przecinka.

Ta tablica określa, które wtyczki powinny być włączone lub wyłączone:

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

Normalnie byłoby to wiersz po wierszu i jeśli ktoś chce dodać coś do tablicy, może zrobić to:

...
// 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
);
...

Tak więc, kiedy zatwierdzają ten kod, widzą tylko jedną zmianę dla tej konkretnej linii i jest to bardziej czytelne podczas sprawdzania, kto wprowadza zmiany w kodzie dla tej konkretnej linii.

W innym wierszu kodu można to zobaczyć bez końcowego przecinka:

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

Zwykle byłby to pojedynczy wiersz kodu, w którym nikt nie oczekuje, że ten kod będzie często zmieniany.

Innymi słowy:

1) Umieść końcowy przecinek, jeśli tablica jest używana jako opcja lub plik konfiguracyjny, który może wymagać dynamicznej zmiany w przyszłości. Poza tym, jeśli wprowadzasz zmiany w tej tablicy programowo za pomocą końcowego przecinka, wprowadzasz zmiany tylko w jednym kodzie liniowym, podczas gdy bez niego musisz radzić sobie z 2 wierszami kodów, co może spowodować bardziej złożoną analizę tablicy

2) Nie musisz umieszczać końcowego przecinka, jeśli tablica jest tablicą stałą i nie spodziewasz się, że zmieni się w przyszłości, ale jak wspomniano w Akceptowanej odpowiedzi, możesz wstawić przecinek na końcu, ale nie ma to żadnego celu

Zaskoczyło mnie to ostatnio, ale ma sens. Od dawna próbowałem trzymać się wcześniejszej konwencji, która prowadzi do tego samego, czyli umieszczania przecinka oddzielającego przed każdym wpisem, a nie na końcu.

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

Wszystkie przecinki również są ułożone w ten sposób, co wygląda ładnie, ale może sprawić, że wcięcie będzie trochę niezręczne. Może z tego powodu wydaje się, że przez lata nie przyjęło się zbytnio, a inni pytali mnie, dlaczego to robię. Wydaje mi się, że rozwiązanie PHP jest dobrym kompromisem, aw każdym razie jest to najwyraźniej obecnie akceptowane rozwiązanie.

Zawsze dodawałem przecinki na początku nowego wpisu. Kompilatorzy postrzegają to jako jednoznakowy symbol wyprzedzenia, który mówi „nadchodzi kolejny”. Nie wiem, czy współczesne kompilatory używają LR (1) (lewostronnie rekurencyjne, z pojedynczym tokenem antycypowanym), ale myślę, że to stąd pojawia się błąd składni, gdy po przecinku nic nie ma. Rzadko się zdarza, że ​​inny programista się ze mną zgadza, ale wygląda na to, że JohnBrooking tak robi!