Visar inlägg med etikett kodstandard. Visa alla inlägg
Visar inlägg med etikett kodstandard. 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!



tisdag 8 februari 2011

Sätt på output buffering i PHP

Artikeln är flyttad till det nya dbwebb-forumet: http://dbwebb.se/forum/viewtopic.php?t=3556

--

Output buffering är ett sätt att undvika felmeddelanden i form av :
Warning: Cannot modify header information - headers already sent by (output started at /home/saxon/teachers/tek/mos/www/test/1.php:2) in /home/saxon/teachers/tek/mos/www/test/2.php on line 4
eller
Warning: Cannot modify header information - headers already sent by (output started at /usr/home/mos/htdocs/dbwebb.se/htmlphp/kmom04/me2/incl/config.php:4) in /usr/home/mos/htdocs/dbwebb.se/htmlphp/kmom04/me2/incl/test/kmom03_sessiondestroy.php on line 17 
Med output buffering så buffras all output och skickas när den är klar. Du ändrar detta beteende i php.ini-filen eller med en .htaccess-fil.

Välj något av alternativen för att sätta på eller stänga av output buffering.

php.ini:
output_buffering=4096
output_buffering = Off

.htaccess i samma katalog som din webbapplikation:
php_value output_buffering 4096
php_value output_buffering Off

I studentmiljö och för utveckling så kan det vara okey att använda output_buffering för att komma runt problemet. Om du kodar för en riktig webbplats så bör du dock ta reda på det egentliga problemet och skriva din kod rätt.

Men, det funkar utmärkt som en snabb "workaround".

Felmeddelandet "Cannot modify header" beskrivs i följande artikel:
http://db-o-webb.blogspot.com/2010/02/warning-cannot-modify-header.html

tisdag 10 augusti 2010

Ändra teckenkodning i jEdit

Detta är för dig som vill byta teckenkodning för texteditorn jEdit.

Du kan ändra teckenkodning dels i nuvarande fil och dels som globala default inställning för alla nya filer.

Så här ser det ut när du byter till UTF-8 för nuvarande fil (Utilities - Buffer Options).
Ändra till UTF-8 för nuvarande öppna fil.
Så här ser det ut när du ändrar till UTF-8 i de globala default inställningarna (Utilities - Global Options).
Ändra till UTF-8 för alla nya filer.
Dubbelkolla vilken teckenkodning som gäller för nuvarande fil, antingen genom att öppna (Utilities - Buffer Options) eller genom att titta längst ned i statusraden på sidan.

Ett bra tips är att starta om applikationen när du gjort ändringarna. De filer som redan är öppna har kvar sina "buffer options".

Visar UTF-8 som nuvarande teckenkodning.

torsdag 22 april 2010

PHP: Intern kodstandard och namngivning av variabler, funktioner, mm

För att förstå hur namngivning av variabler, funktioner, klasser, mm sker i PHP så bör du läsa manualsektionen som handlar om Namngivning (Userland Naming Guide). Den finns som ett appendix till manualen.

http://www.php.net/manual/en/userlandnaming.rules.php
http://www.php.net/manual/en/userlandnaming.tips.php

Därefter så är det lika bra att läsa kodstandarden för de som utvecklar PHP, den gäller alltså inte för oss som skriver PHP-kod utan för de som utvecklar PHP-motorn.

http://svn.php.net/viewvc/php/php-src/trunk/CODING_STANDARDS?view=co

torsdag 15 april 2010

Teckensätt, varför blir mina åäö konstiga (character set, charset, collation)

Detta är en minnesanteckning till mig själv att bättre förklara hur man som utvecklare kan och bör hantera teckenkodning i databaser, webb och php.

Följande har jag hittills.

iso8859-1 och utf8, så här ser filerna ut i webbläsaren vid mixtrade teckensätt.
http://www.student.bth.se/~mos/charset/

Det är utf8 i databasen men inte i min webbapplikation?
Sätt teckensätt på klient/server-kopplingen med php-mysqli-funtionen:
http://se.php.net/manual/en/mysqli.set-charset.php

Läs om bakgrunden i MySQL's manual (flera sidor, pekar till ett bra ställe att börja läsa):
http://dev.mysql.com/doc/refman/5.1/en/charset.html

Mer?
Var konsekvent, använd samma teckensätt i alla delar av applikationen, då funkar det.

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

torsdag 11 mars 2010

Kodstandard: Hur många mellanslag per tabb?

Jag sitter på många olika datorer med olika inställninger, det är frustrerande att kodningen in-tabbning skiljer. Så, jag tänkte att en gång för alla bestämma hur många mellanslag skall en tab vara.

När vi skriver kod så är det vanligt att en tab (\t) ersätts av ett visst antal mellanslag. Googlar vi så finner vi olika synpunkter på antalet tabbar.

Google: php coding standard spaces per tab

En kort översikt säger 2 eller 4. För mig handlar det mest om PHP, HTML, CSS, JavaScript och SQL-kod och framförallt om läsbarhet. Efter en kort överläggning med mig själv så väljer jag 2.

2 mellanslag räcker för att strukturera läsbarheten, funkar för mig. Funkar tydligen för Drupal också.

2 blir det.

fredag 22 januari 2010

Kom igång med HTML5

Låt oss ägna en stund åt HTML5.

HTML, XHTML eller XML?

Börja med att snabbt studera vad Wikipedia säger om HTML5.

HTML eller XHTML? HTML eller XML? Många är kallade att diskutera men få (någon?) har svaret. WHATWG startades av en grupp individer som var missnöjda med W3C's fokus på XHTML och brist på fokus på HTML. Numer jobbar W3C och WHATWG tillsammans för att skapa HTML5. Gruppernas hemsida, gör ett snabbt besök på dem.


För att förstå vad som driver utvecklingen av HTML så läser vi FAQ:en från WHATWG. Ägna 10 minuter åt detta. Det är väl värda minuter. Dokumentet ger oss en insikt i HTML5 men även hur utveckling av webbstandarder drivs.

HTML5 resurser

De båda grupperna WHATWG och W3C samarbetar och jobbar på samma dokument som är HTML Draft. Studera draften översiktligt för att se vad det innehåller och hur det är strukturerat. Betrakta det som en referensmanual. Referensmanualer är bra.


Det finns en spec som beskriver skillnaderna mellan HTML4 och HTML5. Läs igenom det för att bilda dig en uppfattning om de stora skillnaderna mellan HTML4 och HTML5.


W3Schools hjälper oss med en snabb överblick av HTML5. Där ser du snabbt vilka nya element som finns och vilka som tagits bort.


Det finns en tidig validator till HTML5. Testa gärna dina webbsidor i den.


Detta räcker för att guida oss på vår väg till HTML5. Via följande länk kan du testa en HTML5 validerad applikation.


måndag 19 oktober 2009

HTML och PHP, hur mixa koden

Ofta mixas HTML-kod och PHP-kod om vartannat. Beroende på vilken domän och applikation som man jobbar med kan webb-sidorna bli mestadels HTML-kod eller mestadels PHP-kod.  Vilket sätt är rätt?

Betrakta följande exempel på en mestadels HTML-sida med ett litet inslag av PHP.
http://www.student.bth.se/~mos/html-or-php/mostly_html.php?namn=mask
Här hittar du en liknande sida där programmeraren valt att mestadels jobba i PHP.
http://www.student.bth.se/~mos/html-or-php/mostly_php.php?namn=mussemask
Låt dig inte luras av ovanstående exempel, när koden växer och applikationerna blir större så ökar behovet av ordning reda och struktur. Det finns fördelar och nackdelar med de olika sättet (och andra sätt), låt din sinne för ordning, reda, struktur och underhållbarbar kod styra så kommer du hitta rätt.

I kursen dbowebb (Databaser och Webbapplikationer, intro) jobbar vi en hel del med tankesätt kring ordning, reda struktur i koden.

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.