Welke functiesimplementeert u (hoe) in uw PHP-webapplicaties omdat
vind je het op de een of andere manier “professioneeler“? Of heb je persoonlijke nitpicks
en stokpaardjes coderen, met name kleine dingen die kunnen tellen?
Aan welke onaangename code of kleine functionaliteit besteed je een buitensporige hoeveelheid tijd om juistte krijgen?

.

Voorbeeld van het coderen van stokpaardjes voor vraag en antwoord illustratie:

Configuratiegegevens niet in database: toepassingsgegevens != configuratiegegevens, die
is ook een kwestie van noodzaak en efficiëntie.

URL-fixing: normaliseer alle webadressen door de afsluitende slash toe te voegen, zelfs als dit technisch niet vereist is.

Door mensen leesbare cookies: voor gegevensprivacyprobeer ik ondoorzichtige sessie-/databasehandvatten te vermijden (voor gebruikersopties, niet voor autorisatiegebruik).

Onderhandeling over inhoud: zinvol voor eenvoudige variaties
tussen bijv. RSS- en Atom-indelingen. Maar ik zie het niet vaak gebruikt worden.

Geen database-ID’s in gebruikersinterface: vermijd het lekken van interne surrogaatsleutels van de database in URL’s. En met ORM’s hoefden db-interne sleutels niet eens in de bedrijfslogica te lekken.

.

Hints (geen regels)

• Dus, welke functionaliteit vindt u dat uw webtoepassing boven het gemiddelde plaatst?
• Waarom is het ongebruikelijk?
• Heeft het voordelen voor gebruikers, maar is het ook gemakkelijk over het hoofd te zien?
• Professionelere en veiligere coderingssuggesties zijn zeer actueel. Dat zijn ze altijd.
• Maar het beoogde bereik van deze vraag en antwoordis eigenlijk ongewone/unieke functiesen mogelijk niet-standaard en controversiële functionaliteit. Grote bonus voor fascinerend.
• Het gaat ook over coderingsvoorkeuren en nitpicks die zich toevallig in PHP voordoen.
• Denk niet te groot of te hoog niveau. Kleine functionaliteit telt ook.
• Toon code indien mogelijk.
• Syntaxis en coderingsstijl / paradigma’s zijn echter meestal off-topic.
• En laten we niet discussiëren over het nut of de kwaliteit van de code. Het is puur een featuritis & code-enquête.

Eerste premieronde voor onderzoek naar featuritis: het was moeilijk om een ​​beslissing te nemen over een van de vele goede ideeën. Eerlijk gezegd kon ik het maar beperken tot vijf favorieten en de beslissing overlaten aan rand(). En het onderwerp is zeker interessant genoeg om een ​​tweede premieronde te rechtvaardigen. Na een pauze. En misschien neemt iemand anders het over om de reikwijdte te verfijnen.

Antwoord 1, autoriteit 100%

Documentatie.

Stel je een open source-project voor dat je kunt vinden met en zonder up-to-date documentatie en voel welke impact dit heeft op hoe professioneel je denkt dat het is.

Antwoord 2, autoriteit 78%

Zorg voor veiligheid, vooral van de privégegevens van de gebruiker.

Bewaar wachtwoorden met een sterke hash zoals bcrypt(zie cryptdocumentatie):

// generating hash
// read up how $costParameter and $salt look like in the crypt() docs
$hash = crypt($password, '$2a$' . $costParameter . '$' . $salt . '$');
// checking if password is correct
if (crypt($whatTheUserEntered, $hash) == $hash) {
    // correct password
}

$saltmag geen statische waarde zijn. Het zou voor elke gebruiker anders moeten zijn.

Antwoord 3, autoriteit 60%

voor een professionele uitstraling is ook een schoon en esthetisch grafisch ontwerperg belangrijk. omdat de hoes tegenwoordig verkoopt. triest, maar waar. webapplicatie met een mooie code en lelijk uiterlijk zal niet veel aandacht trekken.

4, Autoriteit 30%

wachtwoordsterkte / match

Meld de gebruiker interactief van de krachtzwakte van hun wachtwoord, bij het aanmelden of wijzigen. Meld ze ook op de hoogte wanneer hun bevestiging overeenkomt wanneer ze typen.

realtime-formuliervalidatie

Zoals met wachtwoorden, is realtime validatie van formuliervermeldingen veel minder irriterend dan het toestaan ​​van de gebruiker om het hele formulier in te vullen voordat ze weten dat ze een fout hebben gemaakt of een verplicht veld heeft weggegooid.

verdedigende programmering met vriendelijke uitzondering / foutafhandeling

Gebruik nooit cryptische foutmeldingen en verwijs het algemeen naar de beste voorbeelden die u kunt vinden voor goede vriendelijke foutmeldingen. In de beste gevallen vereist dit over het algemeen een getalenteerde kopie-schrijver om te worden belast met het handhaven van een goede toon van stem enz.

Dit gaat hand in hand met een vast uitzonderingsbehandeling en goede defensieve programmering.

Defensief ontwerp is een behoorlijk fatsoenlijk boek over dit onderwerp.

Antwoord 5, autoriteit 28%

Om nog een paar (minder PHP-georiënteerde) punten aan de mix toe te voegen, die zowel de gebruikerservaring zullen verbeteren als uw app professioneler zullen maken, maar die de back-end afhandelen:

Goede compressie/minificatie
Vaak verzenden Web Apps een groot aantal verzoeken, zowel bij het laden als tijdens het gebruik ervan. Minificatie kan helpen het initiële laadgewicht te verminderen, evenals het gebruik van CSS-sprites en GZipping-inhoud. Een geweldige manier om u te helpen uw toepassing te stroomlijnen en zo snel mogelijk te maken, is Yahoo’s YSlow-plug-in voor Firefox’ Firebug-extensie:

Firebug:
http://getfirebug.com/

YSlow:
http://developer.yahoo.com/yslow/

Ook enkele goede praktijken:
http://developer.yahoo.com/performance/rules.html

YSlow helpt u te bepalen hoe u uw applicatie echt netjes, snel en schoon kunt maken. Ik zou ook PHP Minify aanraden om voor een groot deel van de bestandscompressie te zorgen, het is een zeer capabele tool:

PHP Minify: http://code.google.com/p/minify/

Plus een andere reden om Firebug te kopen, zijn de enorme voordelen die het biedt bij het ontwikkelen van een web-app, niet in de laatste plaats het identificeren van hoe veilig de app precies is, zoals tijdens het gebruik, aangezien u de gecreëerde gegevensstromen kunt volgen.

Verduistering
—uitgesplitst naar meer gedetailleerd antwoord hieronder

Goed gebruik van Apache herschrijven
Afgezien van de basisvoordelen van het aanbieden van schone URL’s om de browse-ervaring te verbeteren en de indruk te wekken van logisch geordende inhoud, kan een goed .htaccess-bestand extra beveiligingslagen aan uw site toevoegen, de inhoud van de serverzijde comprimeren en extra identifiers toevoegen (E- Tags bijvoorbeeld, hoewel hun voordeel betwistbaar is). Elke web-app moet ook een goed geschreven .htaccess hebben.

Compatibiliteit/Validatie
Ik zou elke ontwikkelaar altijd dringend willen aansporen om tot de meest uitgebreide (redelijke) lengte te gaan om ervoor te zorgen dat al hun uitvoercode geldig, becommentarieerd, logisch en schoon is. De W3C doen fantastisch werk door niet alleen HTML duidelijk te specificeren, maar ook hoe Web Apps zouden moeten werken. Volg hun richtlijnen om de compatibiliteit van alles wat u schrijft te vergroten, om ervoor te zorgen dat het voor iedereen werkt zoals u het voor ogen heeft.

Enkele geweldige tools:

HTML-validator: http://validator.w3.org/

Andere validatie: http://validator.w3.org/unicorn/

Enkele specificaties om op te letten:

De W3C Web Applications (WebApps) Working Group: http://www.w3.org/2008 /webapps/

W3C-richtlijnen voor toegankelijkheid: http://www.w3.org/WAI/guid- tech.html

W3C WAI-ARIA-initiatief: http://www.w3.org/WAI/ intro/aria.php

Aan de Javascript-kant is JS Lint een geweldig hulpmiddel om ervoor te zorgen dat eventuele bugs in je JS (die mogelijk geen invloed hebben op de prestaties wanneer je het controleert) worden geplet:

JSLint: http://www.jslint.com/

En bij volmacht, om de ontwikkeling te vergemakkelijken, kan verfraaide JS u helpen uw code beter te structureren voor ontwikkeling, pre minificatie: http:// jsbeautifier.org/

Of natuurlijk verfraaid PHP… http://beta.phpformatter.com/

Eindelijk iets minder zwart-wit
Humanisering

Misschien is een van de grootste voordelen van het produceren van webgebaseerde applicaties de connectiviteit die ze kunnen bieden, niet alleen tussen gebruikers (om samenwerking aan te moedigen), maar ook tussen gebruikers en de app zelf en degenen die verantwoordelijk zijn voor de voortdurende ontwikkeling en onderhoud.

Als je denkt aan projecten zoals 37 Signals, is een van de aantrekkelijke factoren dat ze de gebruiker het gevoel geven dat het project (code) zelf is gehumaniseerd en een karakter heeft, waardoor de gebruiker wordt aangetrokken en geassocieerd met de app, het plezier in het gebruik en de communicatie ervan met anderen aanmoedigen. Ik bedoel niet dat de app ‘levend’ lijkt, maar meer dat het meer ‘benaderbaar’ aanvoelt en gebruikers zich ermee kunnen ‘identificeren’.

Dit is echter slechts één kant van de medaille van humanisering, de zoektocht om gebruikers bijna te laten ’empatheren’ met de app/code/framework/ervaring, zodat ze worden aangetrokken en aangemoedigd om het te gebruiken. De andere kant is om de grens tussen de app en degenen erachter te doorbreken.

We willen allemaal graag de persoon, mensen enz. weten achter wat we gebruiken, omdat we veel informatie van hen doorgeven en dit vaak onlogisch toepassen op de app zelf, en inderdaad onze ‘like’ ervan (dwz zoals Steve Jobs, koop Apple etc..hoewel weliswaar een eigenzinnig voorbeeld). Het hebben van een route waarmee we in geval van moeilijkheden contact kunnen opnemen met een echte persoon is een simpele stap, het hebben van een blog voor ontwikkelaars, een nieuwsstream enz. Het bouwen van een gehumaniseerde metaverse rond de app geeft het geloofwaardigheid en het gevoel dat het misschien groter is dan de som der delen.

Toegegeven, humanisering is misschien niet hier of daar – en het is zeker heel moeilijk om te bouwen (op dezelfde manier waarop verschillende mensen verschillende vrienden hebben), maar een ontwikkelaar kan hoe dan ook de randen van een meer klinische, chirurgische app schuren en maken het is comfortabeler en toegankelijker en leuker voor de dagelijkse gebruiker is een winnaar in mijn boek.

Antwoord 6, autoriteit 25%

Geen verplichte registratie
Dit is een veelvoorkomend probleem bij alledaagse webapplicaties. Geforceerde accountregistraties zijn niet gebruiksvriendelijk. Het is tegenwoordig een noodzaak om spam en misbruik te voorkomen. Maar het belemmert adoptie.

Ik denk dat iedereen wel van StackOverflow heeft gehoord. Ze dwingen geen registraties af. Meedoen kan zonder account. In plaats van registraties af te dwingenwordt het systematisch aangemoedigd. Het belangrijkste punt is echter dat er in ieder geval de mogelijkheid is om geleidelijk aan te wennen voordat je je commit.

Het is een eenvoudig concept. Maar het is ook moeilijk te implementeren. Zelden kun je Tack op tijdelijke en optionele user accounts, moet de basis applicatie logica en database structuur worden voorbereid. Ongeacht de uitvoering inspanning, ik geloof dat dit een belangrijk en undercherished feature.

7, gezag 20% ​​

Voortzetting Points

Voorbeeld: U dient een formulier, krijg je doorgestuurd en nu moet de landing page een meldingen cotain. De meeste sites gewoon op te slaan dat de notificatie in de sessie. Dit betekent: een pagina, die volgende zal worden benaderd wordt dat bericht weergegeven. Geen probleem in de meeste gevallen, maar het is echt rommelig naar mijn mening. Ik denk dat de sessie is voor sessie data, niet volgende aanvraag data.

Mijn oplossing: Maak een array, schrijven van gegevens (meldingen en misschien meer) in, opslaan in memcache met behulp van de sessionid + een unieke identificatiecode en aan de omleiding voeg de param __continuation = {die unieke identifier}. Dan is de volgende pagina wordt geladen dat de gegevens opnieuw en processen het.

Dit wordt meer handig, wanneer u wilt meer gegevens dan alleen maar een kort bericht.

Vragen?

8, gezag 15%

Consistent programmering stijl, variabele naamgeving, schrap, enz. Worden gehecht aan een codering standaard (any codering standaard.) Zorg ervoor dat het bestand geschreven door verschillende mensen zien er hetzelfde uit, zodat het behoud van de code vereist geen weten wie het geschreven heeft.

Antwoord 9, autoriteit 10%

Geconglomereerde applicatie

Vraag uzelf af: als u een online handelssysteem heeft en uw kaartbetalingsleverancier offline gaat, zouden uw klanten dan niet nog steeds door uw producten moeten kunnen bladeren en zelfs kunnen afrekenen met verschillende betalingsalternatieven?

Applicaties moeten zo worden gebouwd dat “switches” kunnen worden omgeschakeld, waardoor niet de hele site in de “onderhoudsmodus” gaat, maar de pagina’s of onderdelen in uw applicatie op een elegante manier niet beschikbaar zijn, terwijl de rest van je app is nog steeds beschikbaar voor andere gebruikers.

Geconglomereerde applicatie is misschien een goedkope naam, maar ik ben er absoluut zeker van dat er iets beters voor is, maar het is zeker een van de benaderingen die veel mensen geneigd zijn te vergeten als het gaat om het ontwikkelen van beschikbare applicaties.

Slimme brute-force bescherming

Stel dat je een administratief gedeelte in je applicatie hebt dat heel wat klantinformatie bevat. Zeker gegevens waarvan je niet wilt dat iemand ze in handen krijgt. Zelfs als je een aardig zout en goede algoritmen hebt om je wachtwoorden te hashen, kan een slechte gebruiker nog steeds een DOS/rainbow-table (brute force?) aanval uitvoeren op je inlogformulieren.

De eerste optie is uiteraard om geautomatiseerde software te gebruiken om deze aanvallen uit te voeren en secundair door dit handmatig te doen door een geldig wachtwoord te raden. Het is heel eenvoudig om voldoende informatie over een gebruiker te vinden om zijn of haar wachtwoord te raden, rekening houdend met de hoeveelheid informatie die beschikbaar is door gewoon Google te gebruiken.
Ook als u in een land als Zweden woont – er is niet veel informatie die u niet kunt vinden over een persoon met een enkel telefoontje naar de autoriteiten – Burgerservicenummers, namen van partner, huwelijksstatus, kinderen namen, huisdieren en nog veel meer informatie die allemaal samenkomen als zeer gekwalificeerde gissingen van wachtwoorden voor de gewone gebruiker.

Als we een kijk eens hoe gewone mensen hun wachtwoord kiezen, de beveiliging moetheel gemakkelijk te compromitteren zijn. Natuurlijk kunnen we beperkingen instellen voor de lengte van gebruikerswachtwoorden, speciale tekens enzovoort, maar dat zou de situatie niet beïnvloeden. Er kunnen nog steeds aanvallen met brute kracht worden uitgevoerd.

Als een gebruiker probeert in te loggen en zijn/haar tweede poging vanaf een onbekend IP-adres mislukt, zou er een recaptcha moeten verschijnen om geautomatiseerde aanmeldingen te voorkomen. Na nog eens (n)mislukte pogingen, zou het account volledig moeten worden vergrendeld en moet het opnieuw worden geactiveerd voordat het inloggen kan worden gedaan.

Om te voorkomen dat geautomatiseerde aanvallen de prestaties verminderen, is het waarschijnlijk een goed idee om een ​​IP die (n)mislukte inlogpogingen binnen een bepaalde tijdspanne heeft gedaan, volledig te blokkeren voor toegang tot de inlogpagina, totdat het is opnieuw handmatig op de witte lijst gezet.

Antwoord 10, autoriteit 8%

WRT Config niet in database, gebruik memcache met bijvoorbeeld een vervaldatum van vijf minuten. Een meer geavanceerde optie is om een ​​”reload config”-pagina aan te raken wanneer de configuratie verandert; de truc is om ervoor te zorgen dat je de pagina op elke app-serverinstantie in de farm aanraakt (daarom geef ik de voorkeur aan memcache).

Antwoord 11, autoriteit 8%

Met de delve-functie in PHP kun je:

$a = delve($array,'a.b.c.d','default'); // $a->b['c']->a
$b = delve($object,'a.b.c.d','default'); // $a->b['c']->a

Zonder dit zou je de hele tijd pijnlijke issets en empties en datatypecontroles moeten doen. Dit is verreweg mijn meest favoriete functie.

Met betrekking tot wat professionelere code maakt, zijn unit-tests, documentatieversiebeheer en eerst doen (en als je dat niet doet, dan teruggaan naar stack-overflow).

/**
 * Delve into an array or object to return the value of a set of keys
 * @version 1, December 24, 2009
 * @param mixed $holder
 * @param mixed $keys
 * @param mixed $default
 * @return mixed
 * @package balphp
 * @author Benjamin "balupton" Lupton <[email protected]> - {@link http://www.balupton.com/}
 * @copyright Copyright (c) 2009-2010, Benjamin Arthur Lupton - {@link http://www.balupton.com/}
 * @license http://www.gnu.org/licenses/agpl.html GNU Affero General Public License
 */
function delve ( $holder, $keys, $default = null) {
    # Prepare
    $result = null;
    $end = false;
    # Prepare Keys
    ensure_keys($keys, $holder);
    # Handle
    $key = array_shift($keys);
    if ( $key === null ) {
        # Reched the end of our key array, so holder must be what we want
        $result = $holder;
        $end = true;
    } else {
        switch ( gettype($holder) ) {
            case 'array':
                if ( array_key_exists($key, $holder) ) {
                    # We exist, so recurse
                    $result = delve($holder[$key], $keys, $default);
                } else {
                    $end = true;
                }
                break;
            case 'object':
                if (
                    /* Already accessible via normal object means */
                    isset($holder->$key)
                    /* Is Doctrine Record */
                    ||  (   ($holder instanceOf Doctrine_Record)
                            &&  ($holder->hasAccessor($key)
                                    ||  $holder->getTable()->hasField($key)
                                    ||  ($holder->hasRelation($key) && (!empty($holder->$key) || $holder->refreshRelated($key) /* < returns null, hence the OR and extra check > */ || isset($holder->$key)) ) // && $holder->$key->exists())
                                )
                        )
                    /* Is normal object */
                    ||  (   !($holder instanceOf Doctrine_Record)
                            &&  method_exists($holder, 'get')
                            &&  $holder->get($key) !== null
                        )
                ) {
                    # We exist, so recurse
                    $result = delve($holder->$key, $keys, $default);
                } else {
                    $end = true;
                }
                break;
            default:
                $end = true;
                break;
        }
    }
    # Check Default
    if ( $end && $result === null ) {
        $result = $default;
    }
    # Done
    return $result;
}

Volledig bestand (en bibliotheek) hier beschikbaar:
http://github.com/balupton/balphp /blob/master/lib/core/functions/_arrays.funcs.php

Antwoord 12, autoriteit 8%

Geautomatiseerde eenheidstests

Belangrijk, net zoals een healthcheck-pagina belangrijk is. Zodra mijn code voorbij 800 regels code groeit, kan ik me niet meer herinneren wat ik op regel 100 aan het doen was en zal ik het waarschijnlijk breken zonder het te beseffen.

Antwoord 13, autoriteit 8%

Internationalisering/lokale ondersteuning

Bied applicatievertalingen voor verschillende talen en lever de juiste taal op basis van de landinstellingen van een gebruiker.

Mobiele versie

Detecteer een user-agent string en geef een mobiele/aanraakvriendelijke versie van uw app weer. Dit is vrij eenvoudig te doen met behulp van xhtml mobiele profielen.

Gebruik een ORM die meerdere backends ondersteunt

Zowel als ontwikkelaar als gebruiker is het fijn om database-backends uit te wisselen door een configuratiebestand te bewerken. Op die manier kun je iets als SQLite gebruiken voor gebruik door dev/single-user, en iets als PostgreSQL of MySQL voor productie.

(onopvallend) Melding als Javascript is uitgeschakeld

Ooit in Stack Overflow geweest met JS uitgeschakeld of uitgeschakeld? Soms vergeet ik dat noscript is ingeschakeld, en zo vertelt het me behulpzaam. Dan kan ik een beslissing nemen of ik het wel of niet weer aan wil zetten; maar ik weet in ieder geval dat ik functionaliteit mis, in plaats van alleen maar te denken dat de app zwak is.

Firebug/Javascript-logboekregistratie

Het verstrekken van veel logboekregistratie helpt bij het opsporen van problemen met Ajax. gewoon console.log(message) in javascript doen, logt het bericht in firebug. Zorg voor een productie-/ontwikkelingsschakelaar in het configuratiebestand van uw toepassing die dit in- of uitschakelt (laat de php de logberichten niet genereren in productiemodus)

Antwoord 14, autoriteit 8%

SSL/TLS-codering voor de hele site

Zoals de recente release van Firesheeplaat zien, is het triviaal om sessiecookies te stelen in open wifi-omgevingen (zoals aangeboden door veel bibliotheken, hotels en andere locaties) en alle niet-geschakelde Ethernet-segmenten die nog steeds ronddraaien. (In theorie ook op geschakelde)

Nu Firesheep het zelfs voor de gemiddelde Joe met twee klikken mogelijk maakt, is versleuteling van de hele site niet langer iets dat als een luxe moet worden beschouwd. (Samen met het instellen van de veiligevlag op sessiecookies om ervoor te zorgen dat compatibele browsers ze niet per ongeluk in onbeveiligde verzoeken lekken) Nochde extensie, noch het probleem verdwijnen.

Volgens de blog van Adam Langly heeft Google vastgesteld dat SSL/TLS isn’ t zo erg als mensen geneigd zijn te radenen met een beetje tweaken (waar ze in Chrome op voortbouwen), kan zelfs de latentiecomponent van het opzetten van een verbinding met extra retourvluchten effectief worden geëlimineerd.

Zelfs certificaatkosten zijn niet zo’n groot probleem als veel mensen denken, aangezien StartComgratis SSL biedt certs en hun rootcertificaat is al aanwezig in alle belangrijke browsers.

Antwoord 15, autoriteit 8%

Een registersysteem.

Ik heb al vele malen eerder gesproken over het opslaan van objecten en scope-problemen en de beste manier die ik ken om dit te verhelpen is door een Static/Abstract class te gebruiken met getters en setters die je kunnen helpen objecten rond je applicatie te transporteren en zodat u geen klassen hoeft aan te passen zodat u specifiek objecten kunt importeren voor gebruik.

de klasse kan zo simpel zijn als een abstracte statische klasse met 2 methoden en 1 array, dit zijn de basisingrediënten om het grote bereikprobleem op te lossen zonder iets anders in de oven te beïnvloeden.

Hier is een klein voorbeeld van waar ik het over heb:

abstract class Registry
{
    private static $objects = array();
    public static function set($name,$object)
    {
        self::$objects[$name] = $object;
    }
    public static function get($name)
    {
        return self::$objects[$name];
    }
}

Kijkend naar de eenvoud van die klasse is er niets om bang voor te zijn, niets om je huidige framework / applicatie aan te passen om deze methode te gebruiken, maar als je niet zeker weet hoe het werkt, laat me je dan enkele voorbeelden geven

Laten we eerst zeggen dat we index.phphebben die startup.phpbevat, en binnen startup.phpuw bibliotheken en kernframework code, maar tijdens het opstarten laadt u het volgende

• Database
• Sessie
• FileWriter
• Invoer
• Uitvoer

als je het FileWriter-object wilt gebruiken als een hulpmiddel voor het loggen binnen het Database-object, zou je normaal gesproken een variabele hebben met de naam $FileWriteren u zou het algemene trefwoord gebruiken in Database-object

Maar door het volgende te doen:

Registry::set('Database', new Database())
Registry::set('Session', new Session())
Registry::set('FileWriter', new FileWriter())
Registry::set('Input', new Input())
Registry::set('Output', new Output())

Je slaat alles op in je Registry-object, dus laten we eens kijken naar ons Database-object / -klasse

class Database
{
    //..
    public function connect()
    {
        if(!$this->connected())
        {
            try
            {
                $this->connect();
            }catch(Exception $e)
            {
                Registry::get('FileWriter')->Write('db_logs',array($this,$e),'unable to connect to database');
            }
        }
    }
    //..
}

Zoals je kunt zien, is het register beschikbaar binnen het bereik van de klasse, en het is schoon, veilig, je neemt geen extra variabelen op of gebruikt meer soorten code met globalization, gewoon schoon eenvoudig en veilig

Ik hoop dat je het leuk vond om te lezen.

Antwoord 16, autoriteit 5%

Ik weet dat dit vreselijke code is en het verdient om te worden gedownvote. Ik wilde alleen een voorbeeld geven dat Content Negotiationeigenlijk gemakkelijk te bereiken is.

function q_order($src) {
    $src = str_replace(",", ";q=0.99,", "$src;last;q=0.975");   // inject placeholder values
    foreach (explode(",", $src) as $prt) {   // split entries
        $q[trim(substr($prt, 0, strpos($prt, ";")))]   // append TOKEN until ";" 
        = floatval(substr($prt, strpos($prt, "q=") + 2));  // and first float after "q="
    }  
   arsort($q);
   return($q);
}   

Hierdoor kunnen HTTP_ACCEPT-headers snel worden gesorteerd, wat handig is voor het automatisch wisselen tussen RSS- en Atom-feedformaten. Of alleen voor het instellen van de standaardtaal. (Je hebt sowieso vaak taalvlaggen/links nodig, maar het is een betere standaard dan alleen Engels te gebruiken.)

$lang = q_order($_SERVER["HTTP_ACCEPT_LANGUAGE"]);
if ($lang["de"] >= $lang["en"]) { ...