Nie umiem się zdecydować nad stylem mojego kodu, a dokładnie na formatem nazewnictwa.
Znam osobiście 3, 4 metody:
- nazwaZmiennej
- nazwa_zmiennej
- Nazwa_Zmiennej
- NAZWA_ZMIENNEJ

Nie satysfakcjonuje mnie też odpowiedź "jak Tobie wygodniej" bo gdy piszesz coś większego to chcesz aby to było maksymalnie czytelne dla innych.
Używanie znaku podkreślenia wydaje mi się bardziej naturalne w przypadku tablic asocjacyjnych, które często są wynikiem zapytania do BD, a tam pisze się nazwy kolumn wyłącznie z podkreślnikiem. Tym stylem nazywane też są funkcje wbudowane w PHP co też jest dosyć solidnym argumentem. Na ten moment stosuje jednak CamelCase bo wydaje mi się.. ładniejszy..

Zastanawiam się czy nie ma jakichś prób normalizacji stylu kodowania ale w globalnym zastosowaniu (np. WordPress promuje konkretny styl, ZEND chyba też).

Ja używam dwóch z twojej listy nazwaFunkcji oraz nazwa_funkcji z tym że ograniczam sie z konkretnym stylem do jakiegoś tam obszaru. Np pierwszy do metod, funkcji i czasem zmiennych, drugi tylko do zmiennych. Generalnie chodzi o to aby było czytelnie, nie ważne jak piszesz. Jak nabierzesz doświadczenia w pracy w teamie to przestaniesz widzieć w tym problem.

Ja pisze zgodnie z
http://kohanaframework.org/3.0/guide/kohana/conventions

camelCase jest w JS używane, w połączeniu z notacja węgierską.

funkcje: nazwaFunkcji
nazwy klas: nazwaKlasy lub nazwa_klasy gdzie _ jest zamieniany na /
zmienna: nazwa_zmiennej lub nazwaZmiennej w zależności od sytuacji.

dodatkowo gdy odwołuję się do metody $lol-> default(); to zawsze daję spacje.

Oczywiście, że jest to ważne ale to, który styl wybierzesz nie ma aż tak wielkiego znaczenia, bo to kwestia gustu, ważne żeby kod był napisany spójnym stylem i miał przyjęte jakieś zasady. Ponadto sam format zapisu nazwy funkcji to tylko jedna z wielu zasad jakie powinien zawierać czytelny kod, ważne są też wcięcia, komentarze, nazwy klas, stałych, nazwy tabel i kolumn w bazie, nazwy plików itd.. Osobiście używam "nazwa_zmiennej" w php i nazwaZmiennej w Java i JavaScript oraz stosuję wyłącznie angielską nomenklaturę i komentarze, jak widzę kod z polskimi nazwami dla funkcji i zmiennych to aż mnie telepie. Ważne też, żeby nazewnictwo było proste i logiczne.

Tu masz kilka bardziej popularnych konwencji:
http://framework.zend.com/manual/en/coding-standard.html
http://www.horde.org/apps/horde/docs/CODING_STANDARDS
http://pear.php.net/manual/en/standards.php

Zalezy w php uzywam camelCase czasem zdazy mi sie uzyc nazwa_metody z pythona-a ale ogolnie php nie jest case sensitive wiec nie wiem o co tyle zalotu kazdy pisze jak chce a to ze zend czy kohana ma swoje konwencje to wiesz.... oczywiscie zeby bylo czytelnie

[PHP] pobierz, plaintext 
namespace Greycoffey\Cache\Driver; 
 
class Filesystem // to ma odzwierciedlać strukturę folderów - przestrzenie nazw i klasy, zgodnie z PSR-0
{
  public $nazwaZmiennej; // na początku publiczne, takNazywane
  protected $nazwaZmiennej2; // żadnych fikuśnych _ przed nazwą zmiennej
  private $nazwaZmiennej3; // tu też, ani przed funkcją
 
  // metod takNazywane() - w kolejności: magiczne, publiczne, protegowane, prywatne
}
 
//zmienne takNazywane, a klasy, interfejsy, traitsy(?) TakNazywane
[PHP] pobierz, plaintext 

Hahahaa W PHP masz bajzel, a nie standard nazewnictwa, i to nie jest żaden argument Nie śmieje się z Ciebie, tylko z naszej bibiloteki podstawowej w PHP, która ciągle ewoluuje.

Chronione

Ja daje suffix "_" przed metodami prywatnymi
Interfejsy maja suffix Inazwa i wiele wiele innych ;]

Ciekawe czy myśleli o zrobieniu aliasów w camel case dla wbudowanych funkcji.
Warto zauważyć, że już nowsze, wbudowane biblioteki jak PDO nazwy metod mają camelCase.

Co do interfejsów, gdy nie da isę wymyślić sensownej nazwy jak np. Paginable, dodaje końcówkę Interface, np. DriverInterface.

Team PHP zawsze o czymś myśli, ale tylko na początku... w końcowej fazie albo to spieprzą, albo zostawią bo ktoś zrzędzi że trzeba zachować wsteczną kompatybilność np. patrz na <?= tyle było szumu że trzeba to wypieprzyć, a w 5.4 okazało się że jest domyślnie włączone... parodia.



To pachnie starą metodą z dawnych wersji FW które tym sposobem nie chciały wykonywać metod z "linku". Dzisiaj to już bardziej bawi szczególnie że w niektórych FW nadal jest to dostępne.

Co do interfejsów, klas abstrakcyjnych, namespaceów w PHP 5.3+ to http://news.php.net/php.standards/2

Akurat ten znacznik wydaje mi się dosyć wygodny gdy nie stosuje się żadnych systemów szablonów typu smarty.
Także słyszałem o tym, że będzie nie wspierany i go w ostatnich projektach nie stosowałem, dopóki nie zapoznałem się changelog 5.4,

Nie wiem czym to smierdzi ale jak cos jest prywatne to musi sie wyrozniac zreszta to taki standard dla tych co pisza w python-ie