Laravel

Først og fremst gir Laravel mest mulig verdi når du skriver ting slik Laravel hadde tenkt deg å skrive. Hvis det er en dokumentert måte å oppnå noe, følg det. Når du gjør noe annerledes, må du forsikre deg om at du har en begrunnelse for hvorfor du ikke fulgte standardene.

Alltid tenk på det å videreføre kundens domene inn i koden. I veldig mange av våre applikasjoner benyttes namespace App, dette for å lettere kunne gjenbruke kode vi har skrevet tidligere. Men tenk at App alltid er kundes navn Fks: PostNord dette gjør det enklere å definere hvilke klasser og funksjoner som er sentrale i applikasjonen fks: PostNord\User hvor User er en “first class citizen”. Imens en implementasjon av et interface kan defineres slik: PostNord\Billing\StripePaymentGateway dette gjør at plassering av filer også faller på plass naturlig slik kunden ville ha formidlet dette selv. Benytt deg av mappestrukturen laravel har i fra før, dette er veldig enkelt å følge hvis en benytter seg av de mange innebygde hjelpekommandoene fks:

php artisan make:job MyJob

---

Konfigurasjon

Konfigurasjonsfiler med orddeling skal alltid deles med bindestrek.

config/
    pdf-generator.php

Konfigurasjonsnøkler med orddeling skal alltid deles med understrek(samt alltid store bokstaver for environment-nøkler).

// config/pdf-generator.php
return [ 
    'chrome_path' => env('CROME_PATH'),
];

Forøvrig så skal en aldri refferere til env() direkte i koden, denne hjelpefunksjonen skal kun brukes i konfigurasjonsfilene. Årsaken til dette er at vi alltid skal "cache" konfigurasjonsfilene våre som en del av deployment prosessen for å gjøre oppslag raskere. Dette vil fungere helt fint lokalt, men alle kall til env() etter koden har kommet i produksjon vil returnere null.

Artisan kommandoer

Navnet gitt til en artisan kommando med orddeling skal alltid deles med bindestrek.

Dårlig praksis: deleteOldRecords God praksis: delete-old-records

Kommandoer skal alltid ende med Command fks: PublishScheduledPostsCommand i filnavn. Dette for å unngå problemer med like navn som andre typer fks. jobber(jobs).

Routing

Alle urler skal benytte bindestrek ved orddeling.

https://my.postnord.no/about-us
https://my.postnord.no/privat/about-us

Rutenavn med orddeling skal skilles med punktum.

Route::get('/tracking/{id}', 'TrackingController@show')->name('tracking.show');

Http-verb skal alltid komme først for å gi en umiddelbar oversikt.

// Dårlig praksis:

Route::name('tracking.show')->get('/tracking/{id}', 'TrackingController@show');

// God praksis:

Route::get('/tracking/{id}', 'TrackingController@show')->name('tracking.show');

Alle parametere i ruter skal begynne med liten bokstav(camelCase).

Route::get('/tracking/{shipmentId}', 'TrackingController@show');

Kontrollere

Kontrollere som fungerer som ressurser skal benytte flertall.

class PostsController
{
    // ...
}

Kontrollere skal utelukkende bestå av de vanlige CRUD operasjonene: index, create, store, show, edit, update og destroy.

Dette betyr istedenfor å legge til nye funksjoner i en kontroller som ikke passer inn med operasjonene nevnt over så skal det opprettes en ny kontroller med et beskrivende navn og der benytte de “gyldige” operasjonene.

//Dårlig praksis:

class PostsController
{
    public function favorite(Post $post)
    {
        request()->user()->favorites()->attach($post);

        return response()->json([], 204);
    }

    public function unfavorite(Post $post)
    {
        request()->user()->favorites()->detach($post);

        return response()->json([], 204);
    }
}

// God praksis:

class FavoritePostsController
{
    public function store(Post $post)
    {
        request()->user()->favorites()->attach($post);

        return response()->json([], 204);
    }

    public function destroy(Post $post)
    {
        request()->user()->favorites()->detach($post);

        return response()->json([], 204);
    }
}

Views

I alle filer og mapper så skal orddeling seppareres med bindestrek.

views/
    loyalty-program/
        guest-index.blade.php

Indentering skal være 4 mellomrom lik PSR.

Språkstyring

Hvis det er krav til språkstyring i applikasjonen i fra kunde så burde dette legges opp til i fra starten av.

I laravel skal __ metoden benyttes. Denne er foretrukket over @lang fordi dette gir oss muligheten til å bruke samme funksjon backend som frontend.

<h2>{{ __('Welcome to the jungle') }}</h2>

<p>{!! __('This is our jungle') !!}</p>

Navngivning av klasser

Å navngi ting blir ofte sett på som en av de vanskeligere tingene i programmering. Det er derfor vi har etablert noen retningslinjer på høyt nivå for klasser.

Kontrollere

Generelt blir kontrollere navngitt av flertallsformen for den tilhørende ressursen og en `Controller suffiks. Dette for å unngå å navngi kollisjoner med modeller som ofte er like navngitte.

eks: UsersController eller EventDaysController

Når du skriver ikke-ressursbaserte kontrollere, kan det hende du støter på påberettbare kontrollere som utfører en enkelt handling. Disse kan bli navngitt av handlingen de utfører.

eks: PerformCleanupController

Disse kan med fordel inneholde en funksjon __invoke

Jobber (jobs)

Navnet på en jobb skal alltid beskrive intensjonen.

eks: CreateUser eller PerformDatabaseCleanup

Events

Events blir ofte avfyrt før eller etter selve hendelsen. Dette skal være veldig tydelig i deres navn.

Før en handling er fullført: ApprovingLoan etter en handling er utført: LoanApproved

Kilder

For å følge med på nyheter og trender i laravelmiljøet så anbefaler vi å benytte twitter. På twitter burde følgende personer følges:

Laravel - @laravelphp
Taylor Otwell - @taylorotwell
Jeffrey Way - @jeffrey_way
Mohamed Said - @themsaid
Adam Wathan - @adamwathan
Jonathan Reinink - @reinink
Jake Bennett - @JacobBennett
Matt Stauffer - @stauffermatt
Chris Fidao - @fideloper
Eric L. Barnes - @ericlbarnes
Laravel News - @laravelnews
Laravel Podcast - @LaravelPodcast