Standardy kodowania [scanner] |
Standardy kodowania [scanner] |
17.08.2009, 10:41:00
Post
#61
|
|
Grupa: Zarejestrowani Postów: 10 Pomógł: 0 Dołączył: 17.08.2009 Ostrzeżenie: (0%) |
Trochę od siebie.
1. Wcięcia - jak dla mnie wcinanie kodu tuż po <?php jest trochę bez sensu, toż to tylko jedna linijka, kod nie stanie się bardziej nieczytelny, a przynajmniej szerokość kodu się zmniejszy, nie będzie zawijany. 2. Nawiasy klamrowe - Wg. mnie czytelniejsze jest stosowanie:
od:
Mamy poza tym krótszy kod. Ten post edytował lars_91 17.08.2009, 10:41:35 |
|
|
17.08.2009, 11:38:33
Post
#62
|
|
Grupa: Moderatorzy Postów: 15 467 Pomógł: 1451 Dołączył: 25.04.2005 Skąd: Szczebrzeszyn/Rzeszów |
Cytat 2. Nawiasy klamrowe - Wg. mnie czytelniejsze jest stosowanie: Jeśli chodzi o sposób zapisywania nawiasów, to istnieją dwie szkoły - a wyznawców praktycznie 50/50. ;] -------------------- ZCE :: Pisząc PW załączaj LINK DO TEMATU i TYLKO w sprawach moderacji :: jakiś błąd - a TREŚĆ BŁĘDU? :: nie ponaglaj z odpowiedzią via PW! |
|
|
22.08.2009, 23:34:31
Post
#63
|
|
Grupa: Moderatorzy Postów: 4 362 Pomógł: 714 Dołączył: 12.02.2009 Skąd: Jak się położę tak leżę :D |
Osobiście uważam, że standardy są od tego, by się do nich stosować. Sam "wychowywałem się" na C++ i na studiach wiele z nich mi wtłoczono. Czy to tyczących składni, czy też pisania dokumentacji projektowej itp. Wiele z nich po czasie stało się podświadomych i trudniej mi się połapać w "radosnej twórczości". Co do spacji i tabulatorów, to tak naprawdę wychodzi ten drobiazg przy komentowaniu kodu zazwyczaj, bo tam głównie dba się o to by pewne informacje były w określonym miejscu i tam tabulacja zawodzi w głównej mierze.
Spacje pomiędzy nawiasami przy liście parametrów funkcji to już standard dla mnie bo czytanie jednolitych bloków w momencie gdy do funkcji jako parametr przesyłam wartości zwracane przez inną kilkukrotnie czasem zagłębioną (wiem... tracę przy tym na wydajności, ale czasem już tak jest) to potworki w stylu
są mniej czytelne niż
Nawiasy klamrowe po funkcji przejąłem wrzucać zaraz po liście argumentów, bez przechodzenia do nowej linii, co dla mnie wygodniejsze zresztą, bo późniejsze zagłębianie sprawia, że taki kod jest nieco czytelniejszy, gdyż widać więcej kodu na tym samym poziomie zagnieżdżenia.
A teraz wyobrazić sobie trzeba, że tych instrukcji warunkowych, pętli itp., jest w kodzie znacznie więcej. Łatwiej ogarnąć całość przy pierwszej szkole zapisu, gdyż jest on zwięźlejszy. Ten kto stosuje skrótowe zapisy instrukcji warunkowych rozumie , ale gdy ktoś zobaczy coś takiego pierwszy raz zapewne nie przyjdzie mu do głowy, ze jest to odpowiednik znanego mu Zresztą sam jestem zwolennikiem stosowania skrótów tam gdzie to możliwe i nieraz stosuję formę a gdy nie ma else, po prostu które to formy są dopuszczalne i w przypadku jednej instrukcji skracają kod, bez utraty jego czytelności. W końcu po coś te formy skrótowe zostały wymyślone. Albo by zmniejszyć kod w określonych przypadkach, albo dla zachowania zgodności składniowej z innymi językami. Z C++ wyniosłem też pisanie obiektów z małej oraz klas z dużej. Dopiero PHP wniósł dodatki związane z opisem typu w zmiennej. Jako że akurat pod tym względem C++ wymusza jawne podawanie tego podczas tworzenia kodu, a niemal każda konwersja musi być jawna, nie musiałem tego wcześniej stosować. Do tej pory mam odruchy w PHP by robić rzutowania, nawet dla typów wbudowanych Inna sprawa, że PHP mi na to także pozwala. Dlatego, mimo różnic w pewnych rzeczach, dobrze mi się pracuje z wersją 5. Jak dla mnie pominięto w artykule choćby: a) stosowanie spacji podczas wyrażeń arytmetycznych. Wiele osób całkowicie to ignoruje, co prowadzi do jego zlewania się w jeden wielki ciąg, który fatalnie się czyta, stosowanie podkreślenia na początku zmiennej by oznaczyć ją jako tymczasową (w obrębie funkcji wewnętrznej, pętli czy tego typu sytuacjach), co pozwala na szybsze połapanie się w tym, które są ważne. Wiem, że kłóci się to trochę z $_POST, $_GET i innymi ale te akurat zawsze są z dużych i znane każdemu więc się nie pomyli nikt raczej c) nie stosowanie podwójnego podkreślenia, bo te w wielu językach są zarezerwowane dla słów specjalnyc, co może spowodować pomyłki przy odbiorze kodu, d) jednolitość pisowni zmiennych bool, bo stosuje się warianty: TRUE, true, True. Oczywiście można by dodać jeszcze kilka innych -------------------- Najpierw był manual... Jeśli tam nie zawarto słów mądrości to zapytaj wszechwiedzącego Google zadając mu własciwe pytania. A jeśli i on milczy to Twój problem nie istnieje :D
|
|
|
5.12.2009, 12:01:53
Post
#64
|
|
Grupa: Zarejestrowani Postów: 40 Pomógł: 3 Dołączył: 5.02.2007 Ostrzeżenie: (0%) |
Witam,
Tutaj też jest trochę o standardach kodowania http://97dd3f4dc892082dd4198bc1d2d576a8.blogspot.com/ Z jedną rzeczą w artykule natomiast nie bardzo się zgadzam a mianowicie odnośnie nazewnictwa plików. Z mojej strony dwa ale: 1: Jeśli chodzi o nazywanie plików małymi literami: - Klasy PEAR (pliki) nazywane są dużymi literami; - Zend FM stosuje również nazewnictwo klas dużymi literami Wydaje mi się więc, żę nazwanie plików z kodem klas z dużej litery jest dobrym rozwiązaniem (nie jest złym) 2: "Nazwy plików piszemy małymi literami, zaznaczając typ pliku: Tu też się przyczepię. Wydaje mi się, że jeśli rozplanujemy aplikację trzymając konkretne jej części w wydzielonych dla nich folderach, dopisywanie do nazwy pliku jej typu nie ma większego sensu. Jeśli mamy np folder classes lub libs to nie widzę potrzeby dodawania w nazwie "class" lub "function". Poza tym ciekawy artykuł, wiem, że dośc stary niemniej dobrze, że ktoś napisałem a tym. Pozdrawiam. Ten post edytował albrzykowski 5.12.2009, 12:02:47 -------------------- Debian Etch, MySQL 5, PHP 5, Apache 2, Eclipse PDT
|
|
|
5.12.2009, 20:02:02
Post
#65
|
|
Grupa: Zarejestrowani Postów: 999 Pomógł: 30 Dołączył: 14.01.2007 Skąd: wiesz ? Ostrzeżenie: (0%) |
Wydaje mi się że to już nie ma co się czepiać, tylko trzeba ten temat zarchiwizować lub dodać mu jakiś tag typu [nieaktualne].
|
|
|
5.02.2010, 01:43:59
Post
#66
|
|
Grupa: Zarejestrowani Postów: 195 Pomógł: 14 Dołączył: 12.01.2006 Skąd: Gotham City Ostrzeżenie: (0%) |
Standard kodowania jest jeden. Netbens. Prawy przycisk myszy i fromat. Wszystko piszemy z małej litery i nadajemy sensowne nazwy. To samo tyczy się katalogów i nazw plików czy komentarzy. Reszta to prehistoria i utrudnianie sobie życia na siłę.
Ten post edytował emp 5.02.2010, 01:46:26 -------------------- Temat zamykam i przenoszę do Bangladeszu.
To jest wiadomość śmierci jeśli ją czytasz to znaczy że pozostało ci 30 sekund życia, więc lepiej zacznij się modlić. |
|
|
5.02.2010, 18:46:08
Post
#67
|
|
Grupa: Moderatorzy Postów: 15 467 Pomógł: 1451 Dołączył: 25.04.2005 Skąd: Szczebrzeszyn/Rzeszów |
A przeczytałeś ten wątek? Ja akurat NetBeans/Eclipse/czegokolwiek w javie nie znoszę i co?
-------------------- ZCE :: Pisząc PW załączaj LINK DO TEMATU i TYLKO w sprawach moderacji :: jakiś błąd - a TREŚĆ BŁĘDU? :: nie ponaglaj z odpowiedzią via PW! |
|
|
9.05.2010, 18:36:26
Post
#68
|
|
Grupa: Zarejestrowani Postów: 283 Pomógł: 11 Dołączył: 11.10.2004 Skąd: 3c Ostrzeżenie: (10%) |
Ja nie uwazam zeby watek archiwizowac wg mnie problem jest dosc istotny a nowosci (i ich sensowna argumentacja moze byc ciekawa).
Co do tego co zostalo opisane przez scannera w wiekszosci przypadkow po pewnym stazu mozna samemu do tego dojsc. Ja w 90% jakby intuicyjnie (czyli tak jak dla mnie wydawalo sie najczytelniej) stosowalem wlasnie takie rozmieszczenia kodu jak opisane w artykule. Choc to co mnie najbardziej gubi w cudzych kodach to zapis w postaci:
zdecydowanie wole:
czyli odwrotnosc do tego co podal thek |
|
|
9.11.2010, 15:01:15
Post
#69
|
|
Grupa: Zarejestrowani Postów: 167 Pomógł: 0 Dołączył: 30.04.2004 Skąd: Częstochowa Ostrzeżenie: (0%) |
zdecydowanie wole: Ja do niedawna też, ale widzę że jak się używa bardziej zaawansowanych edytorów które zwijają kod, to traci się po zwinięciu linijkę, bo zostaje { (phped), więc postanowiłem zmienić wieloletnie przyzwyczajenia. -------------------- |
|
|
30.12.2010, 00:27:03
Post
#70
|
|
Grupa: Zarejestrowani Postów: 76 Pomógł: 8 Dołączył: 10.11.2010 Skąd: Polska,Katowice Ostrzeżenie: (0%) |
Cytat Standard kodowania jest jeden. Netbens. Prawy przycisk myszy i fromat. Wszystko piszemy z małej litery i nadajemy sensowne nazwy. To samo tyczy się katalogów i nazw plików czy komentarzy. Reszta to prehistoria i utrudnianie sobie życia na siłę. Wszystko piszemy z małej litery ?. Logicznie rzecz biorąc nie ma to większego sensu. Przykład islogin() czy IsLogin() : wybieraj a teraz przykład długiej nazwy funkcji handlequestgiverstatusqueryopcode( WorldPacket & recv_data ) czy HandleQuestgiverStatusQueryOpcode( WorldPacket & recv_data ) chyba że chodzi Ci o nazwy zmiennych - to się zgodzę ale nie w każdym przypadku. Co do plików też się nie zgodzę ;P co do klamr, ja znów mam nawyk z c++ i kilku obszernych projektów i wole stosować
spacje po i przed nawiasami, nie wiem czemu ale jakoś tak wygodniej mi. Klamry za warunkiem. Tak naprawdę standardy standardami ale trudno nauczyć człowieka czegoś innego od tego jak mu dobrze. Każdy pisze tak jak lubi, jedynie to w projekcie na większa skale trzeba się czegoś trzymać. Ten post edytował kulczycki 30.12.2010, 00:33:17 |
|
|
3.01.2011, 13:08:16
Post
#71
|
|
Grupa: Moderatorzy Postów: 6 071 Pomógł: 860 Dołączył: 10.12.2003 Skąd: Dąbrowa Górnicza |
handlequestgiverstatusqueryopcode( WorldPacket & recv_data ) czy HandleQuestgiverStatusQueryOpcode( WorldPacket & recv_data ) Dlaczego pakujesz camelCase jako nazwę funkcji do języka, który korzysta z under_score? handle_quest_giver_status_query_opcode( WorldPacket & recv_data ) Takie cuda jak podane przez Ciebie pasują do JavaScript (z tym, że pierwsza litera to mała litera), a nie do PHP. |
|
|
3.01.2011, 22:53:40
Post
#72
|
|
Grupa: Zarejestrowani Postów: 76 Pomógł: 8 Dołączył: 10.11.2010 Skąd: Polska,Katowice Ostrzeżenie: (0%) |
Phpion to nie z javyscript a z c++. I nie wiem co złego jest w łączeniu nazw przez użycie dużych liter zamiast _. Mi tak jakoś jest o wiele bardziej wygodniej, i jest to ładniejsze dla oka. Szczerze to masz też racje bo nie brałem pod uwagi under_score
|
|
|
4.01.2011, 07:26:39
Post
#73
|
|
Grupa: Moderatorzy Postów: 6 071 Pomógł: 860 Dołączył: 10.12.2003 Skąd: Dąbrowa Górnicza |
Nie mówię skąd się wywodzi CamelCase - odniesienie do JavaScript miało na celu to, że w tym języku jest stosowany CamelCase, natomiast w PHP under_score. Według mnie decydując się na kodowanie w danym języku wypadałoby nie mieszać konwencji i trzymać się tej obowiązującej. Dla porównania:
PHP: http://php.net/quickref.php JS: http://www.tutorialspoint.com/javascript/j...n_functions.htm |
|
|
4.01.2011, 07:37:47
Post
#74
|
|
Grupa: Zarejestrowani Postów: 76 Pomógł: 8 Dołączył: 10.11.2010 Skąd: Polska,Katowice Ostrzeżenie: (0%) |
A masz na myśli nazwy zwykłych funkcji czy też metod w obiektach ?
|
|
|
4.01.2011, 12:47:29
Post
#75
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) |
@phpion: Nie podawaj tutaj PHP jako przykładu języka, w którym przyjęła się notacja under_score (ona się tak na serio nazywa?), bo ona się nie przyjęła. Albo inaczej - już od dawna nie jest wiodącą. Niestety bardzo często powtarzane "PHP ma burdel w API" odnosi się również do braku jakichkolwiek konwencji dot. nazewnictwa.
|
|
|
4.05.2011, 22:22:19
Post
#76
|
|
Grupa: Zarejestrowani Postów: 2 885 Pomógł: 463 Dołączył: 3.10.2009 Skąd: Wrocław Ostrzeżenie: (0%) |
Odkurzam. W zalinkowanym artykule w temacie lista znaczników phpDoc jest już niekompletna.
-------------------- Nie pomagam na pw, tylko forum.
|
|
|
8.10.2014, 23:26:21
Post
#77
|
|
Grupa: Zarejestrowani Postów: 251 Pomógł: 23 Dołączył: 23.04.2013 Ostrzeżenie: (0%) |
@phpion: Nie podawaj tutaj PHP jako przykładu języka, w którym przyjęła się notacja under_score (ona się tak na serio nazywa?), bo ona się nie przyjęła. Albo inaczej - już od dawna nie jest wiodącą. Niestety bardzo często powtarzane "PHP ma burdel w API" odnosi się również do braku jakichkolwiek konwencji dot. nazewnictwa. Odgrzeję starego i zgniłego koteleta, ale wyłącznie w celach edykacyjnych. Nie spotkałem się nigdy z terminem "under_score", to się nazywa "snake_case" - ogólnie mamy 3 terminy: - snake_case, - camelCase, - StudlyCaps. Co do standardów kodwania - obecnie w PHP chyba najlepszy wybór to PSR-X i do tego książki typu "Clean Code". |
|
|
2.11.2014, 18:07:53
Post
#78
|
|
Grupa: Zarejestrowani Postów: 64 Pomógł: 10 Dołączył: 2.08.2012 Skąd: DW Ostrzeżenie: (0%) |
StudlyCaps znam jako PascalCase. snake_case czesciej zwane jest LowerCase albo underscores. Natomiast korzystam w swoich projektach z notacji węgierskiej w przypadku zmiennych i PascalCase w przypadku funkcji, klas i przestrzeni.
|
|
|
5.11.2014, 08:52:48
Post
#79
|
|
Grupa: Zarejestrowani Postów: 251 Pomógł: 23 Dołączył: 23.04.2013 Ostrzeżenie: (0%) |
StudlyCaps znam jako PascalCase. snake_case czesciej zwane jest LowerCase albo underscores. Natomiast korzystam w swoich projektach z notacji węgierskiej w przypadku zmiennych i PascalCase w przypadku funkcji, klas i przestrzeni. Hmm, ogólnie to niedawno w jednej z książek (chyba Javy) spotkałem się z określeniami: lowerCamelCase i UpperCamelCase. Później zajrzałem na wiki i zobaczyłem: - BumpyCaps/BumpyCase - camelBack - CamelCaps - CapitalizedWords/CapWords - compoundNames - Embedded Caps/Embedded Capitals - HumpBack - InterCaps/Internal Capitalization - mixedCase - nerdCaps/headlessCamelCase - PascalCase - SmalltalkCase - WikiWord/WikiCase - wimpyCaps No i pomyślałem sobie, że... tak mało wiemy. ; F Dobra, nie ma co rozgrzebywać tego tematu, jak widać co język to nowe pojęcia - a ludzie uwielbiają finezję. ; ) |
|
|
23.06.2022, 23:27:20
Post
#80
|
|
Grupa: Zarejestrowani Postów: 3 034 Pomógł: 366 Dołączył: 24.05.2012 Ostrzeżenie: (0%) |
Wiem że troche odgrzebuje, ale wisi od lat jako ostatni wiec pewnie od czasu do czasu ktoś tu zajrzy mimochodem, dlatego dla potomnych dziś jedyny standard to będzie ten https://www.php-fig.org/per/coding-style/
|
|
|
Wersja Lo-Fi | Aktualny czas: 27.09.2024 - 08:19 |