if (hours < 24 && minutes < 60 && seconds < 60){ return true;}else{ return false;}

og

if (hours < 24 && minutes < 60 && seconds < 60) return true;else return false;

og

return hours < 24 && minutes < 60 && seconds < 60;

1.tilgang, som er meget mere almindeligt anvendt, er betydeligt større end 3. Især bruger den 5 gange mere skærm lodret plads (linjer) og 97 tegn versus 52 (selvom redigeringsværktøjer kan reducere forskellen i faktisk indtastning). Det kan dog diskuteres, hvilket er”enklere”. Den første har en eksplicit If/Then else, med en eksplicit returværdi, der naturligvis er forbundet med hver; selv en nybegynder programmør bør ikke have svært ved at forstå det. 2. kasserer blot seler og skærer den “lodrette” størrelse i to med lidt ændring i konceptuel kompleksitet. På de fleste sprog kunne “return” – udsagnene også tilføjes til de foregående linjer, hvilket bringer den “lodrette” størrelse til kun en linje mere, som den 3.formular.

den tredje form minimerer naturligvis størrelsen, men kan øge kompleksiteten: Det efterlader de “sande” og “falske” værdier implicitte og blander begreberne “tilstand” og “returværdi”. Det er sandsynligvis indlysende for de fleste programmører, men en nybegynder forstår måske ikke straks, at resultatet af evaluering af en tilstand faktisk er en værdi (af typen boolsk eller tilsvarende på hvilket som helst sprog) og dermed kan manipuleres eller returneres. I mere realistiske eksempler kan den 3.formular have problemer på grund af operatørens forrang, måske returnere en uventet type, hvor de tidligere formularer på nogle sprog ville rapportere en fejl. Således er” enkelhed ” ikke kun et spørgsmål om længde, men om logisk og konceptuel struktur; at gøre kode kortere kan gøre den mindre eller mere kompleks.

for store, langlivede programmer, der bruger verbose alternativer, kan bidrage til opblussen.

kompaktitet kan give kodere mulighed for at se mere kode pr.side, hvilket reducerer rullebevægelser og tastetryk. I betragtning af hvor mange gange kode kan ses i processen med at skrive og vedligeholde, det kan udgøre en betydelig besparelse i programmør tastetryk i livet af koden. Dette synes måske ikke vigtigt for en studerende, der først lærer at programmere, men når man producerer og vedligeholder store programmer, reducerer reduktionen af, hvor mange kodelinjer der er mulighed for, at mere af koden passer på skærmen, kan mindre kodeforenkling forbedre produktiviteten og også mindske finger -, håndled-og øjenbelastning, som er almindelige medicinske problemer, som produktionskodere og informationsmedarbejdere lider under.

terer kodning hastigheder kompilering meget lidt, som færre symboler skal behandles. Desuden kan den 3.tilgang gøre det lettere at sammenligne lignende kodelinjer, især når mange sådanne konstruktioner kan vises på en skærm på samme tid.

endelig kan meget terses layouts bedre udnytte moderne computerskærme på bred skærm, afhængigt af skærmens layout og opsætning. Tidligere var skærme begrænset til 40 eller 80 tegn (sådanne grænser opstod langt tidligere: manuskripter, trykte bøger og endda ruller har i årtusinder brugt ganske korte linjer (se for eksempel Gutenberg Bible). Moderne skærme kan nemt vise 200 eller flere tegn, hvilket giver ekstremt lange linjer. De fleste moderne kodningsstile og standarder tager ikke hele bredden op. Således, Hvis du bruger et vindue så bredt som skærmen, spildes en stor ledig plads. På den anden side, med flere vinduer eller ved hjælp af et IDE eller andet værktøj med forskellige oplysninger i sideruder, er den tilgængelige bredde for kode i det område, der er kendt fra tidligere systemer.

det er også værd at bemærke, at det menneskelige visuelle system er stærkt påvirket af linjelængden; meget lange linjer øger læsehastigheden lidt, men reducerer forståelsen og tilføjer øjensporingsfejl. Nogle undersøgelser tyder på, at længere linjer klarer sig bedre online end på tryk , men dette går stadig kun op til omkring 10 tommer, og hovedsageligt for rå hastighed ved læsning af prosa.

PortabilityEdit

programkode bør ikke indeholde “hardkodede” (bogstavelige) værdier, der henviser til miljøparametre, såsom absolutte filstier, filnavne, brugernavne, værtsnavne, IP-adresser, URL ‘ er, UDP / TCP-porte. Ellers vil programmet ikke køre på en vært, der har et andet design end forventet. En omhyggelig programmør kan parametrisere sådanne variabler og konfigurere dem til hostingmiljøet uden for selve applikationen (for eksempel i ejendomsfiler, på en applikationsserver eller endda i en database). Sammenlign mantraet for et”enkelt definitionspunkt” (SPOD).

som en udvidelse skal ressourcer som f.eks. For eksempel med J2EE-applikationer, der kører i en applikationsserver, kan sådanne miljøparametre defineres i omfanget af JVM, og applikationen skal få værdierne derfra.

ScalabilityEdit

Designkode med skalerbarhed som designmål, fordi der ofte i programmelprojekter altid tilføjes nye funktioner til et projekt, der bliver større. Derfor bliver muligheden for at tilføje nye funktioner til en programmelkodebase en uvurderlig metode til at skrive programmer

ReusabilityEdit

Genbrug er et meget vigtigt designmål i programmeludvikling. Genbrug reducerer udviklingsomkostningerne og reducerer også tid til udvikling, hvis de komponenter eller moduler, der genbruges, allerede er testet. Meget ofte starter programmelprojekter med en eksisterende basislinje, der indeholder projektet i sin tidligere version, og afhængigt af projektet genbruges mange af eksisterende programmoduler og komponenter, hvilket reducerer udviklings-og testtiden, hvilket øger sandsynligheden for at levere et programmelprojekt til tiden.

retningslinjer for konstruktion i korte træk

en generel oversigt over alle ovenstående: