1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
<?xml version="1.0" encoding="utf-8"?>
<page xmlns="http://projectmallard.org/1.0/" xmlns:its="http://www.w3.org/2005/11/its" type="topic" id="writing-good-code" xml:lang="sv">
<info>
<link type="guide" xref="index#general-guidelines"/>
<credit type="author copyright">
<name>Federico Mena-Quintero</name>
<email its:translate="no">federico@gnome.org</email>
<years>2013</years>
</credit>
<credit type="author copyright">
<name>Miguel de Icaza</name>
<email its:translate="no">miguel@gnome.org</email>
</credit>
<credit type="author copyright">
<name>Morten Welinder</name>
<email its:translate="no">mortenw@gnome.org</email>
</credit>
<include xmlns="http://www.w3.org/2001/XInclude" href="cc-by-sa-3-0.xml"/>
<desc>Bra, läsbar kod gör att det går att underhålla projektet</desc>
<mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
<mal:name>Anders Jonsson</mal:name>
<mal:email>anders.jonsson@norsjovallen.se</mal:email>
<mal:years>2018</mal:years>
</mal:credit>
</info>
<title>Vikten av att skriva bra kod</title>
<p>GNOME är ett väldigt ambitiöst projekt inom fri programvara, och består av många programvarupaket som är mer eller mindre oberoende av varandra. En stor del av arbetet i GNOME utförs av frivilliga: även om det finns många som arbetar med GNOME som ett heltids- eller deltidsjobb, så är frivilliga fortfarande en stor andel av våra bidragsgivare. Programmerare kan komma och gå när som helst, och de kommer kunna ägna olika mängder tid till GNOME-projektet. Det ansvar folk har i ”verkliga livet” kan ändras, och detta kommer reflekteras i hur mycket tid de kan lägga ner på GNOME.</p>
<p>Programvaruutveckling tar mycket tid och stor möda i anspråk. Detta är orsaken till att de flesta deltidsfrivilliga inte kan starta stora projekt på egen hand; det är mycket enklare och mer belönande att bidra till befintliga projekt, då detta ger resultat som omedelbart är synliga och användbara.</p>
<p>Vi kan därför dra slutsatsen att det är mycket viktigt för befintliga projekt att göra det så enkelt som möjligt för folk att bidra till dem. Ett sätt att göra detta är genom att säkerställa att program är lätta att läsa, förstå, modifiera och underhålla.</p>
<p>Rörig kod är svårläst, och folk kan tappa intresset om de inte kan tolka vad koden försöker göra. Det är också viktigt att programmerare kan förstå koden snabbt så att de på kort tid kan börja bidra med felkorrigeringar och förbättringar. Källkod är en sorts <em>kommunikation</em>, och det är mer för människor än för datorer. Precis som få personer skulle vilja läsa en roman med stavfel, dålig grammatik och slarvig användning av skiljetecken, så bör programmerare sträva efter att skriva bra kod som är lätt att förstå och modifiera för andra.</p>
<p>Följande är några viktiga kvaliteter hos bra kod:</p>
<terms>
<item>
<title>Renhet</title>
<p>Ren kod är enkel att läsa med minimal ansträngning. Detta låter folk börja förstå den lätt. Detta inkluderar både kodstilen själv (parentesplacering, indentering, variabelnamn) och kodens faktiska kontrollflöde.</p>
</item>
<item>
<title>Konsekvens</title>
<p>Konsekvent kod gör det lätt för folk att förstå hur ett program fungerar. Då man läser konsekvent kod formar man undermedvetet ett antal antaganden och förväntningar på hur koden fungerar, så det är lättare och säkrare att göra ändringar i den. Kod som <em>ser ut</em> på samma sätt på två ställen bör också <em>fungera</em> på samma sätt.</p>
</item>
<item>
<title>Utökningsbarhet</title>
<p>Kod för allmänna syften är lättare att återanvända och modifiera än väldigt specifik kod med många hårdkodade antaganden. Då någon vill lägga till ny funktionalitet till ett program kommer det uppenbart vara lättare att göra detta om koden från början designats för att vara utökningsbar. Kod som inte har skrivits på detta sätt kan leda folk till att behöva implementera fula hack för att lägga till funktionalitet.</p>
</item>
<item>
<title>Korrekthet</title>
<p>Slutligen låter kod som designats för att vara korrekt folk spendera mindre tid på att oroa sig om fel, och mer tid på att förbättra ett programs funktioner. Användare uppskattar korrekt kod, eftersom ingen tycker om programvara som kraschar. Kod som skrivits för korrekthet och säkerhet (d.v.s. kod som explicit försöker försäkra sig om att programmet förblir i ett konsekvent tillstånd) förhindrar många sorters fåniga fel.</p>
</item>
</terms>
<section id="book-references">
<title>Bokreferenser</title>
<list>
<item><p><link href="http://www.cc2e.com">Code Complete</link>, av Steve McConnell.</p></item>
<item><p><link href="http://martinfowler.com/books/refactoring.html"> Refactoring: Improving the Design of Existing Code </link>, av Martin Fowler.</p></item>
<item><p><link href="https://en.wikipedia.org/wiki/Design_Patterns"> Design Patterns: Elements of Reusable Object-Oriented Software</link>, av Erich Gamma, Richard Helm, Ralph Johnson och John Vlissides.</p></item>
<item><p><link href="http://astore.amazon.com/gnomestore-20/detail/020163385X"> Object-Oriented Design Heuristics</link>, av Arthur Riel.</p></item>
</list>
</section>
</page>
|
