Visar inlägg med etikett Grön programmering. Visa alla inlägg
Visar inlägg med etikett Grön programmering. Visa alla inlägg

tisdag 22 mars 2011

Är det fel att göra layout med tabeller?

Fundering / Fråga:
Jag gör ibland webproduktioner till företag och har fram tills nu använt tabeller för att designa sidorna. Jag vet att det är smidigare att använda css för att göra layouten men jag har hängt kvar med det arbetssättet då det känts bekvämare och ett vant sätt för mig att arbeta. Sidorna validerar hyfsat när jag kör i Unicorn.
Är det på något sätt "fel" att göra layouten i tabeller?
Svar:

Fel och fel... funkar det så funkar det. Det är ju ändå det som kunden bryr sig om, eller hur?

Men ja, alla trender och tekniker väljer att layouta webbplatserna med CSS. Det är oundvikligt att layout med tabeller är "gammalt" och på väg bort.

Det är intressant att även layout med bilder är på väg bort. Historiskt så används bilder som grafiska element för att skapa effekter, tex runda hörn. Med framväxt av CSS3 så kommer vi se mer och mer webbplatser som väljer CSS3 framför bilder. Detta är i min mening en bra utveckling, CSS3 ger mer flexibilitet, färre sidaccesser för att hämta bilderna och förenklar utveckling och underhåll av webbplatser. Det räcker att skriva en rad i stylesheeten, istället för att hantera en bild.

Det som hindrar utveckling är kompabiliteten mellan browsers och det ännu så länge bristfälliga och browserspecifika stödet för CSS3. Vill man bygga en webbplats som fungerar i "alla" webbläsare så är det än så länge enklare att göra detta med bilder än med CSS3. Men, detta kommer att ändra sig snabbt, iallafall över de närmaste åren. 

Första stegen in i CSS är lite klurigt, men när man väl kan hantera det så glömmer man snabbt tabeller.

Ett tips är att kolla på hur CSS-ramverken blueprint eller 960gs gör, de är lite komplexare men kan ändå ge en fingervisning om hur man kan göra avancerad layout med CSS. Blueprint och 960gs använder ett rutnät, ett grid, för att underlätta layouten. Studera exemplen på deras siter. Det kan vara väl spenderad tid.
http://blueprintcss.org/
http://960.gs/
Lycka till!



torsdag 25 mars 2010

Grön programmering, en programmeringsfilosofi

Till och från ser ni benämningen "Grön programmering" eller "Grön programmering -> spara kodrader". Det är en programmeringsfilosofi som jag vill lyfta fram, eller egentligen så vill jag lyfta fram vikten av att ha en programmeringsfilosofi.  En egen. En tanke bakom sin programmering.

Vad är då "Grön programmering" och vad innebär det?
För att svara på den frågan behövs ett större utrymme, dessutom är den som vilken filosofi som , den formar sig efterhand som individens erfarnhet växer.

Följande post ger en första liten insyn i vad det handlar om.
http://db-o-webb.blogspot.com/2010/03/gron-programmering-att-spara-kodrader.html

Kodstandard för PHP
Ordning och reda i koden, jag kan inte nog nämna hur viktigt det är. Läs följande artikel och se vilka varianter som finns för kodstandarder för PHP.
http://db-o-webb.blogspot.com/2009/10/kodstandard-for-php.html

HTML och PHP, hur mixa koden?
Hur skall man mixa HTML och PHP-koden? I kursen htmlphp gör vi på ett sätt, "skriptsättet". I de andra kurserna gör vi enligt "programmeringssättet". Se hur dessa sätt skiljer sig åt.
http://db-o-webb.blogspot.com/2009/10/html-och-php.html

Hur många mellanslag per tabb?
Hur många mellanslag skall en tab representera?
http://db-o-webb.blogspot.com/2010/03/kodstandard-hur-manga-mellanslag-per.html

PHP's interna kodstandard
Detta är den kodstandard som utvecklarna av PHP-motorn använder. Den är inte för oss som skriver PHP-kod. Men den kan vara kul att läsa ändå.
http://db-o-webb.blogspot.com/2010/04/php-intern-kodstandard-och-namngivning.html

Grön programmering - att spara kodrader?

Handlar Grön programmering om att enbart spara kodrader?

Fråga:

I intruktionen till Kmom04 läser jag:

Grön programmering -> spara kodrader

Är detta alltid vad som gäller?

Jag har lyckats skriva...

if(($rolls = filter_input(INPUT_POST, 'rolls', FILTER_VALIDATE_INT)) <= 0) $rolls = 6;

...vilket får ner exemplets tvåraderskod på en rad + lägger till ytterligare funktionalitet.

Men det är fruktansvärt oläsligt. Vad den gör är att den skapar variabeln $rolls, kollar av om post-variabeln 'rolls' är ett heltal större än noll och defaultar till 6 om den inte är det, vare sig det finns data eller inte i post-variabeln.

Jag undrar alltså om vi alltid ska försöka skriva så få kodrader som möjligt?

Och påverkar det hur mycket processor/minne som används?

Det är en filosofi som jag nu tvingas sätta ord på...

Det handlar om att skriva bra kod, läsbar och underhållbar kod. Det handlar om att koda intelligent och spara antalet kodrader genom att strukturera i filer, klasser, funktioner. Det handlar om att återanvända kod. Det handlar om att veta vilka möjligheter som finns funktioner som är inbyggda i språket. Det handlar om att använda dessa inbyggda möjligheter på bästa sätt och undvika att uppfinna egna (onödiga) lösningar på problem som någon annan redan löst.

Ett enkelt exempel är att använda funktionen för auto_load av klasser.

http://php.net/manual/en/language.oop5.autoload.php

Det "sparar" rader varje gång man skapar ett nytt objekt. Enkelt. Korrekt. Mindre kod att underhålla. Kräver att man har koll på olika inbyggda möjligheter i språket. Kräver att man läst manualen.

Det handlar INTE om att skriva kryptisk kod. Svårt att underhålla. Min syn på nedanstående exempel är till att börja med att alla if-staser bör innehålla måsvingar. Om man använder en if-sats så skall man även använda måsvingar. I vissa fall, undantagsfall, så kan jag skriva en liknande if-sats men då använder jag alltid måsvingar.

//Original
if(($rolls = filter_input(INPUT_POST, 'rolls', FILTER_VALIDATE_INT)) <= 0) $rolls = 6; 



//Better 
if(($rolls = filter_input(INPUT_POST, 'rolls', FILTER_VALIDATE_INT)) <= 0) {
  $rolls = 6; 
}

Ovanstående är en vanlig konstruktion för att hantera GET eller POST variabler. För egen del föredrar jag dock konstruktionen ? :. Den må vara lite kryptisk men den är enkel när man lärt sig den och den sparar kodrader utan att vara svår att underhålla.

//Original 
if(($rolls = filter_input(INPUT_POST, 'rolls', FILTER_VALIDATE_INT)) <= 0) $rolls = 6; 


//This is how I would do it, easier to read the code 
$rolls = filter_input(INPUT_POST, 'rolls', FILTER_VALIDATE_INT)); 
$rolls = ($rolls <= 0) ? 6 : $rolls;

Men, i längden så vet jag att detta är något som jag gör om och om igen, då hade jag valt att lägga det i en egen funktion.

$articleId = $pc->GETisSetOrSetDefault('article-id', 0);
$pc->IsNumericOrDie($articleId, 0);


Ett exempel på sådan kod finns här:

http://github.com/mosbth/Persia/blob/v0.32/pages/forum/PArticleEdit.php

Så långt om Grön programmering. Antar att jag får tillfälle att förtydliga denna filosofi framöver...

måndag 19 oktober 2009

Kodstandard för PHP

(uppdaterad 2010-10-31)

Alla som kodat i grupp, eller läst någon annans kod, förstår vikten av kodstandard. Ett antal regler och riktlinjer som anger hur man döper variabler, funktioner, klasser och metoder samt var måsvingarna skall finnas och hur man tabbar in koden.

Vikten av kodstandard går inte underskatta.

Olika språk har olika kodstandard, olika företag likaså. Nedan finns länkar till 3 olika siter som visar varianter av kodstandard för PHP. Lär dig en och använd den. Sedan är det inte så svårt att anamma en annan vid behov.

http://framework.zend.com/manual/en/coding-standard.html
http://pear.php.net/manual/en/standards.php
http://drupal.org/coding-standards
http://www.dagbladet.no/development/phpcodingstandard/

Den kod vi jobbar med i kurserna är delvis influerad av en kodstandard som användes av UIQ Technology AB. Där gällde det C++ men det fungerar lika bra på PHP. Nedan följer ett par uttdrag av denna kodstandard.

Namngivning av klasser, metoder, medlemsvariabler och funktioner
Variabelnamn startar med liten bokstav. Bryt av med stor bokstav vid längre namn.

$key
$keyToCurrent
Funktioner startar med liten bokstav.
addNewCard()
printPage()
Argument till funktioner startar med litet a.
addNewCard($aCard)
printPage($aText)
Klassnamn startar med C.
CCard
CDeck
Namn på medlemsvariabler startar med i.
iDeckSize
iTypeOfDeck
Det är okey att namnge medlemsvariabler på utan prefix i. De startar då med små bokstäver.

Metodnamn i en klass börjar med stor bokstav.
DealCard()
ShuffleDeck()
Namngivning av filer
Klassfiler heter samma som klassens namn + filändelse.


CCard.php
CDeck.php

Filer som enbart innehåller funktioner startar på F.

FCommonFunctions.php


Filer som är tänkta att inkluderas (och exekveras) startar på I.

ISessionDestroy.php

Intendering och måsvingar
Intendera koden med tab, använd 2 space per tabb. (Läs hur många space per tab)

Måsvinge anges på samma rad som start av funktionen, metoden, loopen, etc samt ensam på sista raden.
myFunction() {
 /* some nice code */
}
Använd alltid måsvingar, även om loopen/if-satsen endast innehåller ett statement.

Kommentarer
Använd // för kommentarer i filhuvud och för att separarer delar av koden.
Det blir då möjligt att använda /* */ för att kommentera bort en större kodmassavilket är bra vid felsökning.

Använd kommentarer som avdelare ovanför funktioner, metoder, klasser och övriga fristående delar av koden. Det underlättar när läsaren kollar i koden och försöker hitta delar av den. Raden med streck bör vara 75 tecken lång.

// --------------------------------
//
// Common header
//

Se följande länk som exempel.
http://github.com/mosbth/Greco/blob/master/common.php

Använda inte PHP-sluttag

Om koden i filen enbart är PHP-kod så är det ok (rekommenderat) att ej använda PHP sluttag.

http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html

Formattering av filer
Använd Unix style för linefeed i filerna. Ej Windows style.