mboost-dp1
unknown
Hvilket igen understreger at den største sikkerhedsrisiko er personen bag computeren.
Selv hvis huller blev lappet 0.1 mikrosekund efter det blev opdaget, og patchen lagt ud, så nytter det ikke det mindste hvis folk ikke patcher.
Selv hvis huller blev lappet 0.1 mikrosekund efter det blev opdaget, og patchen lagt ud, så nytter det ikke det mindste hvis folk ikke patcher.
HELT utroligt at sådan en reklame kan slippe igennem på Myspace som er så store (51.441.000 unikke besøgende i maj (ca halvdelen af google)).
Det er da for dårlig af en så stor side
"Vi vil gerne tjene penge men vi gider da ikke bruge tid på sådanne pjat som at opdatere"
"Vi vil gerne tjene penge men vi gider da ikke bruge tid på sådanne pjat som at opdatere"
#10
Okay hvor er det lige forskellen er:
1. I windows var der en fejl der stammer helt fra 3.1 åbenbart, da den bliver fundet bliver den rettet.
2. I linux kernen er der en fejl der også er meget gammel, da den bliver fundet bliver den rettet ?
Eller vil du påstå at linux er 100% fejlfrit ?
Okay hvor er det lige forskellen er:
1. I windows var der en fejl der stammer helt fra 3.1 åbenbart, da den bliver fundet bliver den rettet.
2. I linux kernen er der en fejl der også er meget gammel, da den bliver fundet bliver den rettet ?
Eller vil du påstå at linux er 100% fejlfrit ?
#9 Det er rigtigt at man kan finde rigtig mange fejl ved at lade folk bruge sit software og derved få dem frem i lyset.
Men man kan faktisk også forudsige en stor mængde fejl ved at kigge på sin kode og se hvad for en type data der kommer ind hvor, hvordan den behandles og hvad der kommer ud igen.
Nåeh back on track, synes godt nok det skræmmende at folk er så bange for at bruge den Windows-funktion til automatiske opdateringer. Nogen der desuden ved om MySpace selv administrerer deres bannerplads osv. (for så er det godt nok lidt af en bommer fra deres side) eller om de har en 3. part til at stå for det?
Men man kan faktisk også forudsige en stor mængde fejl ved at kigge på sin kode og se hvad for en type data der kommer ind hvor, hvordan den behandles og hvad der kommer ud igen.
Nåeh back on track, synes godt nok det skræmmende at folk er så bange for at bruge den Windows-funktion til automatiske opdateringer. Nogen der desuden ved om MySpace selv administrerer deres bannerplads osv. (for så er det godt nok lidt af en bommer fra deres side) eller om de har en 3. part til at stå for det?
#10 du beder ham nævne en fejl i linux kernen der endnu ikke er blevet fundet! Disky kan mange ting, men jeg tror du har fundet hans grænse...
#12
Det vås har du lært i en skoleklasse et eller andet sted ikke? Hvad fanden tror du vi gør? Koder, uden at kigge koden igennem og frigiver den vel vidende at hvis vi brugte et par timer på at kigge på koden ville vi kunne rette massevis af bugs?
Ja ja, der er naturligvis steder man er særlig opmærksom, hvor der f.eks. kan opstå buffer-overrun i unmananged kode osv, men hvis det var så simpelt ville der ikke være så mange fejl i software!
#12
Men man kan faktisk også forudsige en stor mængde fejl ved at kigge på sin kode og se hvad for en type data der kommer ind hvor, hvordan den behandles og hvad der kommer ud igen.
Det vås har du lært i en skoleklasse et eller andet sted ikke? Hvad fanden tror du vi gør? Koder, uden at kigge koden igennem og frigiver den vel vidende at hvis vi brugte et par timer på at kigge på koden ville vi kunne rette massevis af bugs?
Ja ja, der er naturligvis steder man er særlig opmærksom, hvor der f.eks. kan opstå buffer-overrun i unmananged kode osv, men hvis det var så simpelt ville der ikke være så mange fejl i software!
#14
Hvor er det lige jeg bliver blandet ind i #10's kommentar til posting #9's svar til #2 ? :-)
p.s. Du har helt ret finde fejl i Linux kernen gad jeg aldrig bruge tid til. Den kodestil de bruger er i mine øjne af den grimmeste slags, så jeg gider ikke engang kigge for sjov (okay har jeg gjort, men jeg smuttede hurtigt, da jeg opdagede hvordan de satte {'ere osv )
Hvor er det lige jeg bliver blandet ind i #10's kommentar til posting #9's svar til #2 ? :-)
p.s. Du har helt ret finde fejl i Linux kernen gad jeg aldrig bruge tid til. Den kodestil de bruger er i mine øjne af den grimmeste slags, så jeg gider ikke engang kigge for sjov (okay har jeg gjort, men jeg smuttede hurtigt, da jeg opdagede hvordan de satte {'ere osv )
#9
Jeg sagde ikke noget om at de ikke blev rettet, NÅR de bliver opdaget. Jeg vil æde min hat på, at der i Linux (og alle andre OS'er) findes fejl, som ikke opdages før om mange år når en eller anden fru Jensen, laver noget som ingen programmør i sin vildelse fantasi kunne forstille sig.
#12
Ja - en del fejl kan findes hvis man giver sig tid til at programmere ordentligt. Gennem de sidste mange år har det dog til stadighed chokeret mig hvordan vores kunder kan finde på at bruge en computer! F.eks. er der mennesker der synes at det nemmeste er at tage hovedafbryderen, når arbejdspladsen forlades. På den måde slukker man jo hurtigt for 25 Windows 98 maskiner på engang. De troede faktisk at checkdisk var en del af den normale opstart i Windows?!?!?!
En anden sjov episode, var da en kunde i perioder fik oprettet sine records dobbelt. I lang tid troede jeg det var en fejl i vores system, indtil en kunde en dag ringe og klagede over at nabomaskinen skrev ting helt af sig selv. Sådan går det, når man har to tastaturer kørende på samme kanal!!
Ovenstående eksempler skyldes så ikke fejl i koden, men viser bare hvor svært det er af forudse hvordan mennesker tænker og arbejder.
Jeg sagde ikke noget om at de ikke blev rettet, NÅR de bliver opdaget. Jeg vil æde min hat på, at der i Linux (og alle andre OS'er) findes fejl, som ikke opdages før om mange år når en eller anden fru Jensen, laver noget som ingen programmør i sin vildelse fantasi kunne forstille sig.
#12
Ja - en del fejl kan findes hvis man giver sig tid til at programmere ordentligt. Gennem de sidste mange år har det dog til stadighed chokeret mig hvordan vores kunder kan finde på at bruge en computer! F.eks. er der mennesker der synes at det nemmeste er at tage hovedafbryderen, når arbejdspladsen forlades. På den måde slukker man jo hurtigt for 25 Windows 98 maskiner på engang. De troede faktisk at checkdisk var en del af den normale opstart i Windows?!?!?!
En anden sjov episode, var da en kunde i perioder fik oprettet sine records dobbelt. I lang tid troede jeg det var en fejl i vores system, indtil en kunde en dag ringe og klagede over at nabomaskinen skrev ting helt af sig selv. Sådan går det, når man har to tastaturer kørende på samme kanal!!
Ovenstående eksempler skyldes så ikke fejl i koden, men viser bare hvor svært det er af forudse hvordan mennesker tænker og arbejder.
#14 Det kan godt være at det er noget vås jeg har hørt i en skoleklasse. Men hvis man foretager en analyse af koden, kan man i større grad forsikre sig om hvor koden ikke fejler, hvorimod man i tests bedre kan sige hvornår. Og fint nok, sig du at sådanne analyser er noget vås, jeg siger bare at foretager man sådanne analyser grundigt, reducerer man fejlraten betydeligt, at du til et vidst niveau tager det med når du sidder og koder on-the-fly er jo bare godt for dig. Men når man sidder og ser det ene buffer overrun efter det andet titte frem på alverdens exploitsider, sidder man jo og tænker, det måske kunne ha været undgået hvis man havde analyseret koden lidt bedre.
Og jeg siger desuden ikke man programmørerne slet ikke foretager sig såddanne analyser, men der er bare tilfælde hvor det af den ene eller anden årsag ikke bliver gjort godt nok.
Og jeg siger desuden ikke man programmørerne slet ikke foretager sig såddanne analyser, men der er bare tilfælde hvor det af den ene eller anden årsag ikke bliver gjort godt nok.
#18, måske du skal læse den her post på TheDailyWTF og så se at det med at læse og analysere kode ikke altid er nok til at finde huller.. ;)
#14 Sure løg
Men nok om det. Det som Killing_Rain er inde på er helt rigtigt.
Faktisk skal man bruge utroligt lidt tid på kodning og enorm meget tid på at efter analysere koden og forudanalysere koden,
Derefter bør man naturligvis teste koden med de mulige fejl scenarier man kan tænke sig frem til.
Man kan faktisk sige at det er testeren der har den vigtigste funktion i software programmering, alligevel er det sgu nok programmøren der får flest penge.
#19 nogle gange er de dailywtf måske også noget kode der ikke er blevet efter analyseret. :-D
Men nok om det. Det som Killing_Rain er inde på er helt rigtigt.
Faktisk skal man bruge utroligt lidt tid på kodning og enorm meget tid på at efter analysere koden og forudanalysere koden,
Derefter bør man naturligvis teste koden med de mulige fejl scenarier man kan tænke sig frem til.
Man kan faktisk sige at det er testeren der har den vigtigste funktion i software programmering, alligevel er det sgu nok programmøren der får flest penge.
#19 nogle gange er de dailywtf måske også noget kode der ikke er blevet efter analyseret. :-D
#14
Jeg tror ikke det er noget vås du har hørt i en skoleklasse. Jeg tror bare der er stor forskel på teori og praksis.
Jeg tror stadigvæk at de fleste fejl findes efter et produkt når ud til kunderne og mange af dem findes måske aldrig. For at tjene penge, skal produkterne ud hurtigst muligt. Her er en af fordelene ved open source og frivillige arbejdskraft. De bliver ikke fyret når deadlines overskrides :)
Vista består af måske 50 millioner linier kode, og alligevel forventer man at systemet udvikles på ultra kort tid.
Hvis man er rigtig god til at udvikle skal man regne med ca. en bug pr. KLOC og i Vista ville det betyde ikke mindre en 50.000 fejl! (se How many bugs will be in Microsoft's Windows Vista?).
NASA ligger selv på omkring 20 KLOC (se Bugs or Defects?). Det skulle dog være blevet bedre efter de er begyndt at skrive noget af deres kode i Java.
Jeg tror ikke det er noget vås du har hørt i en skoleklasse. Jeg tror bare der er stor forskel på teori og praksis.
Jeg tror stadigvæk at de fleste fejl findes efter et produkt når ud til kunderne og mange af dem findes måske aldrig. For at tjene penge, skal produkterne ud hurtigst muligt. Her er en af fordelene ved open source og frivillige arbejdskraft. De bliver ikke fyret når deadlines overskrides :)
Vista består af måske 50 millioner linier kode, og alligevel forventer man at systemet udvikles på ultra kort tid.
Hvis man er rigtig god til at udvikle skal man regne med ca. en bug pr. KLOC og i Vista ville det betyde ikke mindre en 50.000 fejl! (se How many bugs will be in Microsoft's Windows Vista?).
NASA ligger selv på omkring 20 KLOC (se Bugs or Defects?). Det skulle dog være blevet bedre efter de er begyndt at skrive noget af deres kode i Java.
#6 - Det interessante ved den metafile fejl er at det var skruet sammen på sådan en måde at det ikke var en fejl, men simpelthen en feature! Der var en indbygget feature i WMF håndteringen der gjorde det intentionelt muligt at eksekvere kode. Det var alstå ikke et bufferoverflow eller lignende som den slags somregel er, men en feature man har lavet og ikke lige tænkt over kunne skabe sikkerhedsproblemer. Var vel også derfor der var et par enkelte (ældre) programmer der holdt op med at virke, fordi de brugte denne feature i WMF håndteringen.
Så lige den "fejl" er vel snarere et tegn på at nogen har glemt at tænke i sikkerhed i henhold til nutiden, mens det næppe var det store sikkerhedsproblem tilbage ved Windows 3.11.
Men ang. nyheden er det da mindst ligeså beskæmmende at MySpace ikke har styr på hvad deres reklamer laver, som at så mange ikke opdaterer.
Så lige den "fejl" er vel snarere et tegn på at nogen har glemt at tænke i sikkerhed i henhold til nutiden, mens det næppe var det store sikkerhedsproblem tilbage ved Windows 3.11.
Men ang. nyheden er det da mindst ligeså beskæmmende at MySpace ikke har styr på hvad deres reklamer laver, som at så mange ikke opdaterer.
#15
Tog lige en kigger også ;). Den kode jeg så bruger da ikke en grim stil. Jeg bruger faktisk præcis den samme, f.eks:
while(TRUE) {
work_for_world_domination();
}
At have { på samme linje som for, if etc. er smart da det sparer vertikal plads og man kan lettere overskue koden?
p.s. Du har helt ret finde fejl i Linux kernen gad jeg aldrig bruge tid til. Den kodestil de bruger er i mine øjne af den grimmeste slags, så jeg gider ikke engang kigge for sjov (okay har jeg gjort, men jeg smuttede hurtigt, da jeg opdagede hvordan de satte {'ere osv )
Tog lige en kigger også ;). Den kode jeg så bruger da ikke en grim stil. Jeg bruger faktisk præcis den samme, f.eks:
while(TRUE) {
work_for_world_domination();
}
At have { på samme linje som for, if etc. er smart da det sparer vertikal plads og man kan lettere overskue koden?
#24
Absolut ikke enig.
while(TRUE)
{
work_for_world_domination();
}
Er meget mere læseligt da man tydeligt kan se hvilke {}'ere der hænger sammen uden først at man skal få editoren til at vise det.
Og med de skærm opløsninger vi kører idag, betyder det intet om en while fylder en linie mere,
Når jeg udvikler på arbejdet kører jeg Visual Studio i 1600*1200 på en 20" skærm, og hele skærmen er source editoren, resten af tingene er på min laptop skærm. Oceaner af plads, og når en metode er færdig folder jeg den sammen så den kun fylder en linie :)
I gamle dage hvor man sad i 80*25 char og editerede gav det lidt mening, men i dag ? Ikke efter min mening.
Men det er selvfølgelig smag og behag, eller mangel på det samme afhængig af synsvinklen :)
Absolut ikke enig.
while(TRUE)
{
work_for_world_domination();
}
Er meget mere læseligt da man tydeligt kan se hvilke {}'ere der hænger sammen uden først at man skal få editoren til at vise det.
Og med de skærm opløsninger vi kører idag, betyder det intet om en while fylder en linie mere,
Når jeg udvikler på arbejdet kører jeg Visual Studio i 1600*1200 på en 20" skærm, og hele skærmen er source editoren, resten af tingene er på min laptop skærm. Oceaner af plads, og når en metode er færdig folder jeg den sammen så den kun fylder en linie :)
I gamle dage hvor man sad i 80*25 char og editerede gav det lidt mening, men i dag ? Ikke efter min mening.
Men det er selvfølgelig smag og behag, eller mangel på det samme afhængig af synsvinklen :)
#11
Er der dømt personlig hetz mod mig eller hvad? Oh well, gerne for mig, du er underholdende nok når du prøver at lade som om du forstår ting.
Endnu engang vil jeg dog bede dig om at lade være med at lægge ord i munden på mig, linux er på ingen måde perfekt. Elacris kommer med den påstand, at der er åbne huller i linux der har eksisteret i årevis, og som aldrig er blevet rettet. Jeg vil såment bare gerne se et eksempel på denne påstand, det er skam det hele.
#14
Uhm, nej. Læs og forstå min ven. For det første, så snakkede jeg overhovedet ikke til Desky? For det andet, så beder jeg ham da på ingen måde nævne fejl der ikke er fundet? Læs venligst tingene igennem inden du går igang med et random rant.
#16
Selvfølgelig findes der fejl der ikke er blevet opdaget endnu, det kan vi hurtigt blive enige om. Men med den formulering du kom med tidligere lød det som om du antydede at der fandtes år-gamle fejl, som aldrig var blevet rettet. Åbenbart ikke det du mente.
Er der dømt personlig hetz mod mig eller hvad? Oh well, gerne for mig, du er underholdende nok når du prøver at lade som om du forstår ting.
Endnu engang vil jeg dog bede dig om at lade være med at lægge ord i munden på mig, linux er på ingen måde perfekt. Elacris kommer med den påstand, at der er åbne huller i linux der har eksisteret i årevis, og som aldrig er blevet rettet. Jeg vil såment bare gerne se et eksempel på denne påstand, det er skam det hele.
#14
Uhm, nej. Læs og forstå min ven. For det første, så snakkede jeg overhovedet ikke til Desky? For det andet, så beder jeg ham da på ingen måde nævne fejl der ikke er fundet? Læs venligst tingene igennem inden du går igang med et random rant.
#16
Selvfølgelig findes der fejl der ikke er blevet opdaget endnu, det kan vi hurtigt blive enige om. Men med den formulering du kom med tidligere lød det som om du antydede at der fandtes år-gamle fejl, som aldrig var blevet rettet. Åbenbart ikke det du mente.
#26
Han sagde da ellers at man finder fejl der har eksisteret i årevis. Hvilket vel betyder at man finder fejl i gamle komponenter. Han sagde ikke Man finder de samme fejl gang efter gang - eller fejlene blev fundet for længe siden eller lignende.
Det ville være super hvis du prøvede at forstå de andre indlæg inden du fyrer skumle ting af...
#16
Selvfølgelig findes der fejl der ikke er blevet opdaget endnu, det kan vi hurtigt blive enige om. Men med den formulering du kom med tidligere lød det som om du antydede at der fandtes år-gamle fejl, som aldrig var blevet rettet. Åbenbart ikke det du mente.
Han sagde da ellers at man finder fejl der har eksisteret i årevis. Hvilket vel betyder at man finder fejl i gamle komponenter. Han sagde ikke Man finder de samme fejl gang efter gang - eller fejlene blev fundet for længe siden eller lignende.
Er der dømt personlig hetz mod mig eller hvad? Oh well, gerne for mig, du er underholdende nok når du prøver at lade som om du forstår ting.
Det ville være super hvis du prøvede at forstå de andre indlæg inden du fyrer skumle ting af...
#26 Jeg mente det faktisk som #27 drbrave skriver.
Jeg har dog efterfølgende været ind på bugzilla.kernel.org, og her kan man jo se at der er en hel del meget gamle sager som stadigvæk er åbne. Fx:
ISA_DMA_THRESHOLD fra november 2002
og
machine check handler can deadlock fra maj 2003.
Det må så være svar på spørgsmålet fra #10
Jeg har dog efterfølgende været ind på bugzilla.kernel.org, og her kan man jo se at der er en hel del meget gamle sager som stadigvæk er åbne. Fx:
ISA_DMA_THRESHOLD fra november 2002
og
machine check handler can deadlock fra maj 2003.
Det må så være svar på spørgsmålet fra #10
#27
Måske du skulle prøve at lytte til dit eget råd, inden du beder andre om at forstå indlæggene? Men for at gøre det helt enkelt for dig: Jeg misforstod ham, hvilket jeg beklager inderligt.
#29
Skulle måske have nævnt at det var sikkerhedsmæssige fejl jeg mente, nu nyheden drejer sig et sikkerhedshul. Min fejl, kan godt se det var nemt at misforstå.
Edit: Argh, dobbeltpost, nogen der gider slette #30?
Måske du skulle prøve at lytte til dit eget råd, inden du beder andre om at forstå indlæggene? Men for at gøre det helt enkelt for dig: Jeg misforstod ham, hvilket jeg beklager inderligt.
#29
Skulle måske have nævnt at det var sikkerhedsmæssige fejl jeg mente, nu nyheden drejer sig et sikkerhedshul. Min fejl, kan godt se det var nemt at misforstå.
Edit: Argh, dobbeltpost, nogen der gider slette #30?
#25 Smag og behag. For mig er indent-level der er vigtigst når man skal have overblik over strukturer - mere end de enkelte { }. Derfor unlader jeg også {} når jeg kan slippe af sted med det. Koden bliver mere kompakt og der er bedre plads til kommentarer. Det kræver selvfølgelig streng disciplin med indentation.
Men der er da ikke noget grimmere og mere pladsspildende end f.eks. :
}
else if (hokus_pokus)
{
..// Dont do this at home
..magic();
}
else
{
..unmagic();
}
Tre linjer kode fylder det tredobbelte...
Men man kan jo blive tvunget til det når Visual studio editoren tvinger den bestemte kodestil igennem med vold og magt... ;)
Men der er da ikke noget grimmere og mere pladsspildende end f.eks. :
}
else if (hokus_pokus)
{
..// Dont do this at home
..magic();
}
else
{
..unmagic();
}
Tre linjer kode fylder det tredobbelte...
Men man kan jo blive tvunget til det når Visual studio editoren tvinger den bestemte kodestil igennem med vold og magt... ;)
#32
Ja men heldigvis bruger Visual Studio editoren den pæne og overskueligt kode stil jeg foretrækker :)
Det med bare at skrive:
if (x==y)
doSomething();
Bryder jeg mig heller ikke om, for når der er MANGE af dem inden i hindanden ryger overblikket meget ment, men et par {}'ere stående under hinanden så er det dejligt læseligt.
Men det værste er helt klart når folk forsøger at presse en helt funktions funktionalitet ned i return statement.
Har set grumme eksempler, hvor der var funktions kald, ternary operatorer osv, i et return stament. Det gavnede absolut intet ud over ingen kunne læse det.
Smag og behag, jeg har en stor skærm det sagtens kan være på, så jeg fortrækket åben kode, og ikke noget sindsygt kompakt noget.
Jeg ved godt nogle kodere har en mærkelig ide om at det compilede kode er meget mindre og hurtigere, bare fordi de spare 3 liniers plads i sourcen (dette er ikke ment mod dig)
Men som sagt:
Smag og behag, eller i mange tilfælde Firmaets codestandard
Ja men heldigvis bruger Visual Studio editoren den pæne og overskueligt kode stil jeg foretrækker :)
Det med bare at skrive:
if (x==y)
doSomething();
Bryder jeg mig heller ikke om, for når der er MANGE af dem inden i hindanden ryger overblikket meget ment, men et par {}'ere stående under hinanden så er det dejligt læseligt.
Men det værste er helt klart når folk forsøger at presse en helt funktions funktionalitet ned i return statement.
Har set grumme eksempler, hvor der var funktions kald, ternary operatorer osv, i et return stament. Det gavnede absolut intet ud over ingen kunne læse det.
Men der er da ikke noget grimmere og mere pladsspildende end f.eks. :
Smag og behag, jeg har en stor skærm det sagtens kan være på, så jeg fortrækket åben kode, og ikke noget sindsygt kompakt noget.
Jeg ved godt nogle kodere har en mærkelig ide om at det compilede kode er meget mindre og hurtigere, bare fordi de spare 3 liniers plads i sourcen (dette er ikke ment mod dig)
Men som sagt:
Smag og behag, eller i mange tilfælde Firmaets codestandard
Hvis det endelig er man vil have kildekoden formateret på en anden måde, så findes der da simple værktøjer der lige kan vekslevirke mellem forskellige formateringer og opstillinger. Så sværre er det da heller ikke. Behøver man da ikke gøre et voldsomt problem ud af. Koden bliver jo ikke dårligere af den grund.
#34
Formatering er ganske rigtigt smag og behag, men en stor skærm er da ikke noget argument. Jeg har også masser af skærmplads, og jeg hader når det bliver brugt på marginer o. lign. Koden skal være så kompakt som muligt, uden den bliver uoverskuelig.
Til daglig har jeg heldigvis en en genvejstast, som formaterer koden for mig. På arbejde har de andre samme genvejstast, så det er blevet firmaets kodestandard. No problem.
Smag og behag, jeg har en stor skærm det sagtens kan være på, så jeg fortrækket åben kode, og ikke noget sindsygt kompakt noget.
Formatering er ganske rigtigt smag og behag, men en stor skærm er da ikke noget argument. Jeg har også masser af skærmplads, og jeg hader når det bliver brugt på marginer o. lign. Koden skal være så kompakt som muligt, uden den bliver uoverskuelig.
Til daglig har jeg heldigvis en en genvejstast, som formaterer koden for mig. På arbejde har de andre samme genvejstast, så det er blevet firmaets kodestandard. No problem.
Disky
Lige gyldig hvilken opløsning du kører i , bør du stadig ikke have længere linjer end 80 tegn. Man skulle jo gerne kunne læse koden uden at skulle dreje hovedet.
Det er også rimelig sjældent man har brug for længere linjer, f.eks. i SQL bruger bør man også bruge linebreaks så det er mere læseligt, sådan her: http://phpfi.com/133937
Men hvis i mener at http://phpfi.com/133938 er mere læseligt, så vær da velkommne.
Lige gyldig hvilken opløsning du kører i , bør du stadig ikke have længere linjer end 80 tegn. Man skulle jo gerne kunne læse koden uden at skulle dreje hovedet.
Det er også rimelig sjældent man har brug for længere linjer, f.eks. i SQL bruger bør man også bruge linebreaks så det er mere læseligt, sådan her: http://phpfi.com/133937
Men hvis i mener at http://phpfi.com/133938 er mere læseligt, så vær da velkommne.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund