Forum PHP.pl

Oczywiście, że musisz to zgłosić.
Nie ma znaczenie jak to przechowujesz (znaczy są pewne wytyczne) i czy to szyfrujesz czy nie. Ważne jest to, że przechowujesz dane.
http://www.bankier.pl/wiadomosc/Kiedy-zbio...DO-2661828.html

Oczywiście, że naklepania durnego CRUDa w PHP może być tańsze czy szybsze ale jeśli to ma być WWW pod którym jest coś ciekawszego to już szybkość i beztroska zamknięta w PHP przestaje być wartością dodaną.

No widzisz ~marcio zamiast buńczucznych haseł okazuje się, że po prostu mało wiesz ale z chęcią wypowiadasz się o całości.
Poza gigantyczną ilością zastosowania Javy poza WWW to samo WWW w Javie też można pisać bardzo efektywnie. JSP, które widziałeś to ledwie wierzchołek góry lodowej.

O to samo chciałem zapytać.

~marcio od wypowiadania sloganów podobnych do "sry ale java pod www to dla mnie pomylka!" nie posuwasz dyskusji ani o krok naprzód. Natomiast jakbyś zechciał przytoczyć jakiś argument. Ooo to by było coś.

A może zainteresuje się Arduino. Tez super sprawa, w którą mam zamiar się zagłębić.

Zauważ, że używając jednego języka jesteś w stanie złowić większą ilość klientów. Możesz pisać naprawdę wiele rzeczy w Javie. Od WWW począwszy, przez aplikacje desktopowe aż po aplikacje mobilne (z Androidem włącznie).
Czy to nie jest argument za Javą?
Czyli wiesz ale nie powiesz. Sprytnie.
To powiedz jaki to tok myślenia Javowców jest powodem żeby ten język odrzucić lub w niego nie brnąć?

A jakież to powody? Piszę w Javie i jakoś nie dostrzegam oczywistych powodów, dla których miałbym ją porzucać na rzecz C#

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.

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.

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.

~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.

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.

~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.

~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.

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:

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

A oto przykład tego czym polimorfizm nie jest.
Jest ogromna różnica pomiędzy przeciążaniem metod (ang. overloading) a ich nadpisywaniem (and. overriding). To co opisał ~thek to overloading, podczas którego mechanizm polimorfizmu najzwyklej w świecie nie działa!

Polimorfizm jest to mechanizm podczas, którego obiekt może występować jako obiekt różnych typów. Oznacza to, że obiekt zmienia swoją formę w zależności od referencji.
Przykład z polami figur jest OK. Przykład z przeciążaniem metod jest fatalny!

---update---
Można by się zagłębiać w czeluście teoretyzowania i powiedzieć, że przecież przykład z przeciążeniem metod to mechanizm ad-hoc polimorfizm ale to nie jest clue sprawy. To nadal nie jest polimorfizm na poziomie obiektów, o którym mowa w tym przypadku i w 99% procentach rozmów o polimorfizmie.
Zresztą ad-hoc polimorfizm to tylko polimorfizm z nazwy.

Nie.

Przekieruj sobie w hosts adres php.pl na jakiś szajs. Nie będzie CI się chciało tego zmieniać. Ale to wymaga dyscypliny, żeby nie zmieniać tego ustawienia.
Sam plik w upierdliwym miejscu (w Windowsie) więc nie będzie Ci się chciało tam zaglądać.

Szybkość pisania to mit. Dużo ważniejsza jest czytelność i łatwość serwisowania.
Od lat wiadomo, programiści w pracy niemal 8% czasu poświęcają na czytanie i modyfikację kodu a nie na jego tworzenie.

Tak tylko zwracam uwagę, bez wskazania na żaden język wymieniony w tytule.

Wybaczam. Spiąłem się bo już się weekendu nie mogę doczekać. Jeszcze 72min.

Żartujesz sobie?

Klikasz w pierwszy link zatytułowany How does Google Trends work? i czytasz pierwsze zdanie:

Nigdy nie przestanę się dziwić dlaczego ludzi wolą gdybać, roztrząsać, domyślać się i.t.d. zamiast po prostu sprawdzić.

About Google Trends
Wnioski możesz wysnuć rozmaite ale zawsze to będzie na podstawie tego co ludzie szukają czyli jest tak jak sądziłeś, że nie jest.

A jaki to ma związek z symfony?
Nie sądziłem, że jest zakaz pisania backendu samemu Przecież generatory można wykorzystać w części lub tylko do utworzenia szablonu rozwiązania. Potem kodować możesz samemu równie skutecznie.
Uszanuj to, że inne rozwiązanie nie trafia w cudzy gust. To że Ci się podoba Kohna nie znaczy że musisz przekonywać tych, którzy nie chcą być przekonani.
To się tyczy zwolenników dowolnego narzędzia.

Nie cuduj, każdy framework po to powstał i każdy spełnia swoje zadanie mniej lub bardziej.
Czy programiści Zend'a traktują ustalanie struktury folderów jako implementacji logiki?


OK, starczy. Nie ma co bić piany. Piszcie w czym chcecie i tak Java rządzi a PHP idzie na dno, bo niestety polityka Zend'a (nie mam tu na myśli frmaeworka) w niczym nie pomaga.