Gode vaner i PHP

[TheClown]

Hei på dere.

 

Jeg har programmert PHP i 6-7-8 år nå og føler meg relativt stabil i språket. Samtidig har jeg også fått jobb som webutvikler, så jeg sitter mye med det. På grunn av sistenevnte ønsker jeg å ha best mulige vaner når jeg skriver kode, slik at andre som tar over seinere ikke river ut alle hårene sine.

 

Jeg lurer derfor på om dere har noen gode vaner når man skriver kode. Da mener jeg alt fra tegnsetting til navngivning.

 

Jeg har et par eksempler:

 

<?php
$var = 'Variabel med enkle quotes';
// Eller
$var = "Variabel med dobble quotes?";

// Skrive if slik:
if ($var == 'test') {

// Eller slik
if ($var == 'test')
{
?>

[etse]

Jeg vil virkelig anbefale å ta en titt på boken Clean Code: A Handbook of Agile Software Craftsmanship

Denne boken tar for seg mye essensielle ting når det kommer til å skrive god kode. Anbefales

 

Akkurat de tingene du snakker om er egentlig mer en smaks-sak; viktigste er at du er konsekvent og gjør det på samme måte hele tiden.

[MikkelRev]

Folk som programmerer, tillegger seg lett egne vaner når det gjelder navnekonvensjoner, curly bracket styles osv. Det viktigste er at du er konsekvent og konsistent iht det firmaet du evt. jobber for. Om du jobber for deg selv/freelancer, så følg en konsistent konvensjon.

 

Generelle gode prinsipper er MVC, OOP, DRY og KISS.

 

Sjekk ut disse artiklene også, underholdende lesestoff

http://net.tutsplus.com/tutorials/php/why-youre-a-bad-php-programmer/

http://net.tutsplus.com/articles/are-you-making-these-10-php-mistakes/

[WhiteFire]

SOLID er også verdt å sjekke ut.

Endret 9. juni 2012 av WhiteFire

[dahuff]

Hei på dere.

 

Jeg har programmert PHP i 6-7-8 år nå og føler meg relativt stabil i språket. Samtidig har jeg også fått jobb som webutvikler, så jeg sitter mye med det. På grunn av sistenevnte ønsker jeg å ha best mulige vaner når jeg skriver kode, slik at andre som tar over seinere ikke river ut alle hårene sine.

 

Jeg lurer derfor på om dere har noen gode vaner når man skriver kode. Da mener jeg alt fra tegnsetting til navngivning.

 

Jeg har et par eksempler:

 

&--#60;?php
$var = 'Variabel med enkle quotes';
// Eller
$var = "Variabel med dobble quotes?";

// Skrive if slik:
if ($var == 'test') {

// Eller slik
if ($var == 'test')
{
?&--#62;

 

Jeg foretrekker doble snutter og if + { på samme linje.

 

F.eks.

 

$foo = "bar";
if ($foo == "bar") {
  return $foo;
}

 

Hvorfor?

 

Doble fnutter er mer konsekvent å holde seg til siden det er mest allsidig selv om man må bruke escape tegn (\) oftere. Lange html-seksjoner hører uansett til i template-filer, så da kan man ta seg råd til å bruke doble fnutter i klasser. Men jeg er ikke så streng på det.

 

If og åpningsparantes på samme linje siden jeg synes det ser visuelt bedre ut og fordi det er meningsløst å lage ekstra linjeskift som kun skaper mer rulling i IDE'en.

 

Imho selvsagt.

Endret 14. juni 2012 av dahuff

[etse]

Men å ha krøllparantesen på egen linje gjør det visuelt lettere å se hvor en funksjon starter og slutter. Scrolling burde uansett ikke være noe problem da en enkel metode og/eller funksjon helst ikke burde være lengre enn 10 linjer; og om den er burde du tenke på å refakturere koden. (min mening - etter å ha lest boka Clean Code har jeg blitt veldig fan av å dele alt opp i masse små funksjoner på cirka 5-6 linjer hver)

[WillY-]

Jeg setter veldig pris på at koden er kommentert med PHPDoc standarden Spesielt når man jobber med PHPStorm som unytter det fullt ut. Gjør jobben så utrolig mye enklere!

[dahuff]

Men å ha krøllparantesen på egen linje gjør det visuelt lettere å se hvor en funksjon starter og slutter.

Når selve if'en er på vertikal linje med lukkeparantes synes ikke jeg det er ett viktig argument i praksis. Med shift+alt+f i Netbeans blir koden automatisk formatert og veldig oversiktlig også.

 

Jeg foretrekker å ha luft "før" if'en, altså ett linjeskift som markerer at kodeavsnitt hører sammen. Med åpningsparantes på egen linje gjør man dette på en måte motsatt, eller man man marker med luft/avstand både før og etter if.. Kanskje.

 

Men alt dette handler naturligvis om smak og behag også.

Endret 14. juni 2012 av dahuff

[MikkelRev]

Det spiller ingen rolle hvilken stil man bruker. Eneste som spiller en rolle er at man er konsekvent konsistent.

http://en.wikipedia.org/wiki/Indent_style

[TheClown]

Jeg foretrekker doble snutter og if + { på samme linje.

 

Jeg mener å ha lest at strenger i enkle quotes blir parset fortere enn de i doble. Det er hovedsaklig derfor jeg gjør det. Samtidig skal man ikke gjøre slik:

 

$var = "string $foobar";

 

Men slik:

 

$var = "string ".$foobar;

 

Og da tenker jeg at det er like greit å bruke enkle:

 

$var = 'string '.$foobar;

 

Ser det har kommet inn mange gode linker og tips i denne tråden. Takk så mye, jeg skal sette meg ned og se på det så fort jeg får mulighet. Kom tilfeldigvis over dette innlegget da jeg skummet gjennom.

[Matsemann]

Jeg mener å ha lest at strenger i enkle quotes blir parset fortere enn de i doble. Det er hovedsaklig derfor jeg gjør det.

Det er mikrooptimalisering, og slikt kan du bare kaste ut av hodet. Ikke tenk på slikt når du programmerer. For det første "mener du å ha lest det", så det er ikke sikkert, og for det andre så har det nok 0 betydning, selv i tyngre programmer.

 

De vanene du prater om her dreier seg kun om syntaks. Jeg ville heller gått inn for å få gode vaner som leselig og forståelig kode, mindre kode per funksjon, gode navn på ting, refaktorert kode til gjenbrukbare komponenter osv. Tross alt kan kodestilen din endres automatisk med et tastetrykk i IDEet du bruker.

 

Med det sagt, så er det i PHP Zend Framework Coding Standard som er normen. Les igjennom de fire punktene der.

[etse]

Enkle quotes parses fortere enn dobbel-quotes av den enkle grunn at man kan ha variabler direkte inn i en dobbelquote - so PHP må sjekke om det er variabler i strengen; mens med enkel quote kan den bare hive den ut slik den er.

 

Men som matsemann sier, dette er mikro-optimalisering som egentlig vil ha lite å si. Det vil ha tilnærmet ingen innvirkning på skalerbarheten på siden; og når man ser på optimalisering er det skaleringen som er viktig.

[aktiv]

Kommentarer med god informasjon er alltid en god vane! Lett for andre å tolke koden.

[etse]

Kommentarer med god informasjon er alltid en god vane! Lett for andre å tolke koden.

men husk å vær forsiktig med kommentarer, for kommentarer brukt feil har helt motsatt virkning.

 

Aldri kommenter hva du gjør, kommenter hvorfor du gjør det. Om du noen gang føler for å skrive en kommentar rundt hva koden din gjør - er koden din ikke tydelig nok.

 

Nothing can be quite so helpful as a well-placed comment. Nothing can clutter up a module more than frivolous dogmatic comments. Nothing can be quite so damaging as an old crufty comment that propagates lies and misinformation.

 

Comments are not like Schindler’s List. They are not “pure good.” Indeed, comments

are, at best, a necessary evil. If our programming languages were expressive enough, or if we had the talent to subtly wield those languages to express our intent, we would not need

comments very much—perhaps not at all.

 

The proper use of comments is to compensate for our failure to express ourself in

code. Note that I used the word failure. I meant it. Comments are always failures. We must

have them because we cannot always figure out how to express ourselves without them,

but their use is not a cause for celebration.

 

So when you find yourself in a position where you need to write a comment, think it

through and see whether there isn’t some way to turn the tables and express yourself in

code. Every time you express yourself in code, you should pat yourself on the back. Every

time you write a comment, you should grimace and feel the failure of your ability of

expression.

 

Why am I so down on comments? Because they lie. Not always, and not intentionally,

but too often. The older a comment is, and the farther away it is from the code it describes,

the more likely it is to be just plain wrong. The reason is simple. Programmers can’t realistically maintain them.

Endret 19. juni 2012 av etse

[Crowly]

Samtidig skal man ikke gjøre slik:

$var = "string $foobar";

Det er gyldig kode, men skal man pirke veldig så bør man bruke krøll parentes rundt variabler, slik at man forteller php hvor variabelen begynner og slutter

$var = "string {$foobar}";

[Matsemann]

Det er gyldig kode, ja, men veldig uleselig. Skummer du fort over koden ser du ikke at det brukes en variabel inne i stringen. Poenget her er gode vaner.

 

Jeg ville brukt

$var = 'string ' . $foobar;

Legg merke til mellomrommet før og etter punktum.

 

Leser man Zend Coding Standard, som jeg lenket til i mitt forrige innlegg, ser man at single fnutter ( ' ) er det en skal bruke til vanlig her. Synes denne standarden er grei å følge. Den brukes mange plasser og da blir det konsekvent, som er det viktigste.

[aktiv]

Aldri kommenter hva du gjør, kommenter hvorfor du gjør det.

 

Det er det jeg snakker om. Dette er god informasjon for en som skal "ta over" koden etter deg!

[NicholasWalkerHD]

En god vane er å bruke Object Oriented Programming (OOP). Er støttet av de fleste frameworks som vil gjøre jobben lettere for deg.

[TheClown]

Samtidig skal man ikke gjøre slik:

$var = "string $foobar";

Det er gyldig kode, men skal man pirke veldig så bør man bruke krøll parentes rundt variabler, slik at man forteller php hvor variabelen begynner og slutter

$var = "string {$foobar}";

Jeg hadde ikke skrevet det om det hadde vært feil kode, men det parses saktere av PHP enn å flytte variabelen utenfor quotesene, og man burde ha teksten i enkeltquotes, ikke dobbelt.

[Crowly]

... og man burde ha teksten i enkeltquotes, ikke dobbelt.

Hvis man skal ha variabler inne i en streng, så må man bruke dobbel quote. $var = 'string {$foobar}'; er ikke gyldig. Kun er presisering, for å unngå missforståelser, hvis andre snubler over dette, og for de som vil bruke variabler inne i strengen. Selv så foretrekker jeg $var = 'string '.$foobar; , enklere å lese, spesielt med fargekoding.