...gdy 00:00 juz dawno temu minelo, mysli zamiast prowadzic do klarownych rozwiazan slimacza sie we wszystkich kierunkach lepiac sie do siebie nawzajem i nawet budowanie foreacha wymaga zebrania sie w sobie i skupienia uwagi?

... termin oddania projektu za kilka godzin - w poniedzialek rano - szczesliwie calosc na finishu, ostatnie kody w phpie, potem jeszcze animowany slider z karuzelka w jquery i calosc bedzie smigac jak ta lala - tylko czemu koncowki projektow z krotkimi terminami sa zawsze takie ciezkie?

Bo ja wiem. Pamiętam, jak ja miałem oddać pracę z przedmiotu Inżynieria Oprogramowania. Wyobraź sobie że wtedy dwa razy nie spałem pod rząd. Jak zacząłem pisać końcówkę programu o 22:00 w środę tak o 7 w czwartek skończyłem (zero snu). Potem to na autobus i na studia. Brak snu doprowadziło mnie do picia kawy (choć nie lubię).

Coś w tym jest.

A wystarczy umiejętnie rozplanować sobie zadania, a nie robić wszystko na ostatnią chwilę. Nie wiem czy macie się czym chwalić...

Bo ci się nie chce. Tak jak napisał ~phpion jeśli sobie roboty nie rozplanujesz tylko dłubiesz na bieżąco to z każdym skończonym etapikiem masz dosyć i myślisz że zrobiłeś TYYYYYLE że czas na przerwę. Dokładne rozplanowanie rozwiązuje całą sprawę. UML FTW!

Scrum, scrum, scrum...

A czy Ty znasz to uczucie, gdy siadasz do kodu, który sam pisałeś kilkanaście tygodni temu i gdyby nie komentarze oraz przebłyski jak to miało mniej więcej działać za żadne skarby bez analizy kodu byś nie załapał po jaką cholerę zrobiłeś tak a nie inaczej?

[PHP] pobierz, plaintext 
$random_existance = array( 'count' => mt_rand( 0, 2 ), 'place' => array() );
if( $random_existance['count'] > 0 ) {
    $random_text = array(
        '<p>Random text 1.</p>',
        '<p>Random text 2.</p>',
        '<p>Random text 3.</p>',
        '<p>Random text 4.</p>'
    );
    $loops = min( $random_existance['count'], count($random_text) );
    $place = array_rand( array_flip( range( 1, 5 ) ), $loops  );
    foreach( (array)$place AS $miejsce ) {
        shuffle( $random_text );
        $random_existance['place'][ $miejsce ] = array_pop( $random_text );
    }
}
[PHP] pobierz, plaintext 

Ja dziś wziąłem do ręki ten kod (dla utrudnienia usunąłem komentarze), a i tak patrzyłem na swoje niektóre konstrukcje i zastanawiałem się "Ki czort?". Tak niewiele linijek, ale trochę czasu mi zajęło zanim zakminiłem czemu obliczanie $place wygląda tak, a nie inaczej i dlaczego w foreachu mam dodatkowo rzutowanie na tablicę To właśnie tam bowiem tkwi cały sekret dlaczego później mam możliwość prostego użycia gdzieś w czeluściach kodu prostego sprawdzenia "jest-nie ma".

Ja stosuję zasadę, że jeśli kod wymaga komentarzy to jest to najzwyklej w świecie kod źle napisany.
Należy go wtedy przepisać tak by był czytelny bez komentarzy.

Zasada ta należy do manifestu uchu Agile Software Craftsmanship

Znam doskonale to uczcie, teraz komentuje staram sie komentowac wszystko, dowolnie ale komentowac...

Tracisz energię i czas na niepotrzebną czynność. Jeśli kod jest tak nieczytelny, że jego zrozumienie wymaga dodatkowych komentarzy to jest do przepisania. Kod sam w sobie powinien się łatwo czytać i być zrozumiały. Jeśli jest niezrozumiały jest kiepskiej jakości i nie poprawisz jego jakości dodając komentarze.
Kod podlega przenosinom, refactoringowi i wielu innym modyfikacjom. Rzadko za tym idzie modyfikacja komentarzy. A nawet jeśli to dokładasz sobie dwa razy więcej pracy bo utrzymujesz kod i komentarze.
Najczęściej jest tak, że są one nieaktualne, niekompletne i mylące.

Tym bardziej, że robisz to na odwal aby było:

@Mike: Potrzebowałem losowych X liczb z zakresu 1 do X. Używałbym rand lub mt_rand, gdyby nie fakt, że nie mogą się powtarzać. Zobacz więc co robię z place i powiedz czy da się prościej. Biorę tworzę tablicę jako zakres liczb od 1 do X. Teraz losuję bez powtórzeń (range) i muszę wybrać X losowych spośród nich, więc rusza array_rand. Ale on zwraca klucz lub klucze. Na dodatek jeśli to jeden klucz to zwraca go jako typ jakiego jest ów element, więc wymusza na mnie w foreach rzutowanie na array. A skoro losuje klucze to muszę wartości zamienić z kluczami i stąd array_flip. Tylko tak mam pewność, że wybierze zawsze z zakresu bez powtórzeń. Nie ma wbudowanej funkcji w php, która by losowała X liczb z zakresu zadanego bez powtórzeń. Tego raczej nie da się już prościej zapisać, bo inne metody będą bazować na tym, że losujemy w pętli tak długo, aż nie wylosujemy X i w razie trafienia tej samej, nie branie tego przebiegu pod uwagę. Innymi słowy zamiast jakiejś mogacej się wykonywać długo pętli w stylu

[PHP] pobierz, plaintext 
$random_from_range = array();
while( count( $random_from_range ) <= $loops ) {
    $temp = $mt_rand( $start_range, $end_range );
    if( array_search( $temp, $random_from_range ) == false ) {
        $random_from_range[] = $temp;
    }
}
[PHP] pobierz, plaintext 

zrobiłem jednolinijkowca

[PHP] pobierz, plaintext 
$random_from_range = (array) array_rand( array_flip( range( $start_range, $end_range ) ), $loops  );
[PHP] pobierz, plaintext 

Nie sprawdzałem wydajności, gdyż każdy z nich ma swoje wady i zalety a zastosowanie jest zalezne od sytuacji. Ale ten zapis drugi, choć bardziej zawiły dla laika, na pewno ma ten plus, iż nie ma pustych przebiegów, nawet w przypadku gdy losowanie odbywa się przy liczbie losowanych bliskiej ilości liczb w zakresie. A to jest główna wada pętli, ktora zapewne nieraz wtedy trafi wielokrotnie w tę samą liczbę.

@Mike: Tak, wiem, że pierwszy przykład to nie jedyny z możliwych innych, bo tych można napisać jeszcze wiele bazując na shuffle i array_slice czy shuffle i array_pop dla przykładu (bliższe już wtedy 2 wariantowi). Ale najczęstsze implementacje są jednak bardzo podobne do tego pierwszego własnie. Nie jest to optymalne zawsze, podobnie jak moje w pewnych przypadkach, ale kwestia zawsze jest tego gdzie i jak często stosujemy.

~thek ale ja nie mówię tym by każda operacja była jednym poleceniem. Twój przykład jest jak najbardziej OK. No może poza tym, że nazwa zmiennej $loops jest od czapy wzięta. Zamykając to wszystko w funkcję:

[PHP] pobierz, plaintext 
<?php
 
public class SomeClass {
    public getRandomNumbersFromRange($resultNumbersCount, $startRange, $endRange) {
        return (array) array_rand(array_flip(range($startRange, $endRange)), $resultNumbersCount);
    }
}
 
?>
[PHP] pobierz, plaintext 

... sprawiasz, że kod sam się komentuje. Najzwyklej w świecie używając odpowiednich nazw funkcji, zmiennych e.t.c. oraz wydzielając atomowe operacje do funkcji sprawiasz, że wszelkie komentarze są zbędne.
Obawiam się, że podałeś zły przykład lub nie zostałem do końca zrozumiany.

QFT, jestem przeciw zbędnym komentarzom. Moje komentarze to ewentualnie przypomnienie co następująca funkcja, metoda, jakaś spójna część kodu "robi" - choć rzadko, bo w większości wypadków sama nazwa np. funkcji, klasy dużo mówi. Ja akurat jestem zwolennikiem dłuższych nazw zmiennych etc. tzn. jak mam np. zmienną, która tylko "tu" się przyda, to nazywam ją $tempNumbers albo $tempSortedNumbers - netbeans i tak podpowiada.
A ponieważ nadal się uczę - to mam jeszcze wiele kodu śmieciowego w swoich "biblioteczkach" - masakra... Wtedy nie komentowałem z lenistwa i często piszę od nowa kod bo jak można używać czegoś, czego się nie rozumie

~thek ten pierwszy przykład równiez można napisać w dużo bardziej czytelny i samodokumentujący się sposób:

[PHP] pobierz, plaintext 
<?php
 
public class SomeClass {
 
    public getRandomNumbersFromRange($resultNumbersCount, $startRange, $endRange) {
        $randomNumbers = array();
        while (count($randomNumbers) <= $resultNumbersCount) {
            $randomNumber = mt_rand($startRange, $endRange);
            addRandomNumberIfUnique($randomNumbers, $randomNumber);
        }
 
        return $randomNumbers;
    }
 
    private addRandomNumberIfUnique($randomNumbers, $randomNumber) {
        if (array_search($randomNumber, $randomNumbers) == false) {
            $randomNumbers[] = $randomNumber;
        }
    }
}
 
?>
[PHP] pobierz, plaintext 

Kolejne dwie zasady, które staram się stosować to:
1. Unikać nazw zmiennych pod tytułem temp. One kompletnie nic nie mówią bo chodzi o zawartość.
2. Wydzielać bloki kodu do oddzielnych funkcji. Nawet te najmniejsze jeśli tylko pomoże to w czytelności kodu.

Znów kompletnie brak miejsca na komentarze. Jest naprawdę bardzo niewiele miejsc gdzie komentarze są przydatne. A jeszcze mniej gdzie są potrzebne.

Chyba, że istnieje wymóg stworzenia dokumentacji (javadoc lub phpdocumentor).

Poza tym, ja osobiście uważam, że używanie zmiennych typu 'temp' czy 'tmp' we fragmentach kodu, gdzie te zmienne faktycznie istnieją jedynie na chwilę, w celu przechowania jakiejś tymczasowej wartości (np. jakieś obliczenia w pętli, gdzie przechowują wynik cząstkowy), ma sens pod warunkiem, że faktycznie służą tylko i wyłącznie temu. Nawet nazwa takiej zmiennej sugeruje, że jest ona chwilowa i że jej wartość nie jest nigdzie dalej wykorzystywana.

Co oczywiście nie przeszkadza w niczym nazwać jej np. 'temporarySum' czy cos takiego

No tak zdarza się, że ktoś postawi taki wymóg
Warto się wtedy ograniczyć do komentowania tylko publicznego API najważniejszych modułów. Udokumentowanie wtedy klas oraz pakietów zazwyczaj może wystarczyć.
Z rzeczy, które niemal zawsze przydaje się udokumentować w komentarzach to informacje o rzucanych wyjątkach.

Oj znamy to uczucie, programowanie to nie praca, to coś o wiele straszniejszego

@mike: w przykładzie chodziło mi o to, że nawet pozornie jednolinijkowa operacja może mieć taki kod, który bez chwili rozknimki nie jest dla Ciebie zrozumiały i nie chodzi tutaj o to, że nie jest to ujęte w klasie i problem rozwiązuje zastosowanie określonego nazewnictwa. Czasem konieczne jest skomentowanie czemu tak, a nie inaczej, by przeglądając kod po kilku tygodniach wiedziećy na czym polega ów fragment, gdyż zastosowaliśmy jakieś niezbyt dla siebie typowe rozwiązanie, które wydaje się na pierwszy rzut oka nieczytelne lub nie pasujące do całości. Tak więc nie chodzi mi tu o to by trzymać konwencje, ale wchodzić z komentarzami tam, gdzie to jest uzasadnione logiką i naszym zapominalstwem. Na poziom poniżej tego, który podpowiada nam IDE bazując choćby na PHPdoc. Przykładowo, jeśli tu czy tam użyliśmy algorytmu X, który można znaleźć na stronie Y lub Z. Ja w tym kodzie miałem, że służy on mi do tego i tamtego, ale ważne było dla mnie także, dlaczego taką składnię zastosowałem, a tego mi już konwencja nazewnictwa po kilku tygodniach nie powie. Fakt, nazwa $loops jest nic nie mówiąca, ale została po pierwotnej wersji podczas optymalizowania. To zresztą fragment wtyczki do Wordpressa, która dość mocno mieli, więc zamiast dodatkowo obciążać serwis kolejnym poziomem abstrakcji, zastosowałem podejście strukturalne jako szybsze, zwłaszcza że dane pobierane są z innego serwisu (XMLRPC) i już tutaj wiele tracę na nawiązanie połączenia oraz oczekiwanie na dane, więc musiałem optymalizować pod kątem czasu wykonania. Przez to pewne rzeczy i kruczki musiałem opisać by po kilku tygodniach nie patrzyć się na to jak cielę na malowane wrota

Dokładnie to miałem na myśli.

~thek zgodzę się. Czasem krótko można napisać o algorytmie, który jest zastosowany jeśli jest on na przekład nieintuicyjny, autorski lub nieznany szerokiemu gronu.
To jest jedna z sytuacji kiedy krótki komentarz jest OK.

$temp - nigdy samego nie używam zawsze tempCos - i tylko jak blooregard pisał wtrącam taką zmienną w odpowiednich momentach ; ) np:

[PHP] pobierz, plaintext 
           $tempNumbers = $prepared_smsAnalytics->fetch(\PDO::FETCH_OBJ);
           ($tempNumbers->delivered != '') ? $tempDelivered = array_unique(explode(",", $tempNumbers->delivered)) : $tempDelivered = null;
            ...
           return array($tempDeliveredNumbers, $tempBouncedNumbers, $tempRejectedNumbers);
[PHP] pobierz, plaintext 

Chociaż tak myślę czytając "2-gą radę" mike'a - mógłbym oddzielić to do osobnej funkcji - co będzie bardziej czytelne.

Jak widać "prepared_" - to taki mój prefix, obok używam query_, exec_ - wówczas gdy potrzebuję użyć to znowu wpisuję $prepared_ np. i netbeans sam podpowiada - pomaga mi jak akurat potrzebuję dostępu do bazy i konkretnych danych. W sumie tak sobie myślę, że mógłbym każdą taką rebeliancką akcję powydzielać do malutkich funkcji, a nóż później funkcja dojrzeje i się w coś przekształci.


A co chciałem do tematu powiedzieć: każdy ma swoje "ulepszenia", które przyśpieszają pracę nad kodem

Tylko trzeba pamiętać o tym, że ktoś kiedyś może będzie ten kod utrzymywał i Twoje "ulepszenia" mogą wtedy bardzo ten proces utrudnić

Skoro tak temat powędrował to ja przy okazji gorąco polecam: Clean Code: A Handbook of Agile Software Craftsmanship. Książka naprawdę bardzo dobra.
Niby opisane zasady i podpowiedzi tyczą się niemal podstaw, które dobry programista już dawno powinien osiągnąć to jednak nieźle trzepie po głowie. Ja mocno polepszyłem warsztat po przeczytaniu książki.
Pozycja z naciskiem na Javę (zawiera trochę tekstu, który dość mocno tyczy się tego języka) ale w ogólności kierowana dla użytkownika każdego języka.

Wiem, że mało adekwatny nieco, ale posłużę się linijką z kodu jaki już podałem i tyczy właśnie wyliczania niefortunnego $loops

[PHP] pobierz, plaintext 
$loops = min( $random_existance['count'], count($random_text) );
[PHP] pobierz, plaintext 

Dla siebie dodatkowo skomentowałem, że jest ono potrzebne w ramach zabezpieczenia. Może być bowiem sytuacja, że tekstów losowych jest podanych mniej niż wylosowana liczba. Niby drobiazg, ale bez niego w określonych sytuacjach kod się może wyłożyć. Komentarz tutaj informuje więc mnie, że jest to miejsce na które muszę zwrócić uwagę podczas ewentualnej optymalizacji kodu. Myślę, że ma tutaj więc uzasadnienie komentarz, gdyż jest to potencjalna pułapka w sytuacji dostarczania danych z zewnątrz. Ja dla siebie więc i późniejszego zrozumienia lubię stosować. Nie by pisać elaborat, ale gdy siadam po długim czasie znowu do kodu tegoż, wiedzieć co z czym zjeść. A takiej informacji konwencje nie obejmują. Konwencje tyczą bowiem czytelności kodu i pewnych podstawowych informacji, a nie jego głebszej warstwy logiczno-informacyjnej tak naprawdę. Z samego nazewnictwa, układu kodu i jego ustrukturyzowania tego nie uzyskam w żaden sposób.

Jakbyś zrobił z tego funkcję (opisaną przez jej nazwę):

[PHP] pobierz, plaintext 
<?php
 
class SomeClass {
    private function calculateRandomNumbersCount($randomExistance, $randomText) {
        return min( $randomExistance['count'], count($randomText) );
    }
}
 
?>
[PHP] pobierz, plaintext 

... to użycie komentarza już nie jest takie oczywiste. Aczkolwiek racja, troszeczkę pomocne.

Gdybym oparł o klasy lub robił specjalnie funkcje, choć wiem, że dany kod będzie wykonywany jednokrotnie przez całe wywołanie funkcji i nigdzie indziej w kodzie, to fakt, miało by to jakiś sens. Jak jednak wspomniałem, świadomie zrezygnowałem z warstwy abstrakcji i zamykania wszystkiego w funkcje celem minizowania wszelkich narzutów czasowych, a takim wypadku cierpi czytelność. Zyskuje na czasie wykonania, tracę na połapaniu się w kodzie i chcąc, nie chcąc, przy takim podejściu komentarze stają się niemal obowiązkiem. Gdyby nie ten fakt, który stanął jako podwalina, to zrobiłbym zapewne jak mówisz i ładnie bym się trzymał standardów OOP. A tak jedyną pomocą jaką mogłem zastosować było trzymanie konwencji nazewnictwa, choć i tu mi się zdarzyło walnąć gdzieniegdzie byczka

Czyli brniesz w negatywne skutki poprzednich błędnych decyzji I brniesz dalej i dalej ...
W programowaniu bardzo łatwo nadziać się na efekt stłuczonej szyby.

thek czy dodanie jednej klasy i kilku metod będzie zauważalnym narzutem w wykorzystaniu zasobów, czasu działania?

Moim zdaniem będzie to bardzo daleka pozycja po przecinku. Czas poświęcony na pisanie komentarzy, albo później przy każdej zmianie - na wgryzanie się w kod, będzie dużo dłuższy i będzie generował dużo większe koszty niż dodatkowa pamięć czy czas serwera.

@mike: jeśli nie naprawiałbym "dziur", to masz rację "Problem" w tym, że skrypt jest kompletny i nie wymaga poprawek od strony logiki. Jedyne które mogą go dotknąć tyczą się właśnie optymalizacji wydajnościowych. Albo wtedy poprawiam czytelność i obniżam wydajność, albo na odwrót. W moim wypadku wybrałem to "na odwrót"
@vokiel: masz częściowo rację. Z tym, że komentarze piszę tak, że nawet kompletny debil by zrozumiał Siadając po nawet roku do kodu i mając poprawne nazewnictwo oraz takie komentarze nie miałbym prawa się nie połapać w chwilę co zrobiłem