1 / 10
De fleste programmører har deres egen idé om, hvad der er den bedste måde at skrive kode på.
Konventionerne kan variere fra sprog til sprog og fra organisation til organisation, men også fra udvikler til udvikler.
Klik videre og se nogle af de mest udbredte konventioner, som GitHub har målt sig frem til er de klart mest udbredte metoder.
2 / 10
Nogle udviklere mener, at kodens læsevenlighed øges, hvis man anvender et ekstra mellemrum på hver side af parametrene/argumenterne, så man eksempelvis skriver
function fn( arg1, arg2 ) {
// ...
Men de er ikke mange.
Hele 94 procent af næsten halvanden million GitHub-commits i JavaScript, Java, C# og PHP vil i hvert fald gøre det anderledes.
De vil i stedet skrive
function fn(arg1, arg2) {
// ...
3 / 10
Skal du sætte komma mellem værdierne i begyndelsen af hver linie for at forbedre læsevenlighed og debugging, eller skal du sætte kommaet ved slutningen af en linie.
Svaret fra GitHub er klart:
I 92 procent af en million JavaScript-commits sættes kommaet ved liniens slutning.
Så skal du følge konventionen, skal du skrive eksempelvis
var obj = {
foo: 1,
bar: 2,
baz: 3
};
og ikke
var obj = {
foo: 1
, bar: 2
, baz: 3
};
4 / 10
Helt tilbage fra IBM's hulkort og de første primitive skærme har vi arbejdet med en maksimal linielængde på 80 tegn.
I dag er det selvfølgelig muligt at arbejde med langt længere linier, men konventionen gælder stadig.
Det bliver fastslået af hele 92 procent af mere end fem millioner GitHub-commits på fem forskellige sprog (Java, Python, Scala, Ruby, C# og PHP).
Blot seks procent skriver linier på maksimalt 120 tegn, mens to procent arbejder med linier på maksimalt 150 tegn.
5 / 10
Vi har tidligere skrevet om, at programmører ofte finder det svært at navngive kode.
Det kan du læse mere om her: Her er de allersværeste programmør-opgaver.
Programmørerne er også ret enige om, hvordan navnet skal skrives, hvis valget står mellem eksempelvis camelCase, snake_case eller PascalCase.
87 procent af GitHub-commitsene anvender camelCase-reglen, mens blot 11 procent tyr til snake_case og blot to procent til PascalCase.
6 / 10
I programmør-kredse er spørgsmålet om, hvorvidt man skal bruge mellemrum eller tabs en klassisk diskussion.
Svaret fra mere end syv millioner GitHub-indlæg til syv forskellige sprog er imidlertid klokkeklart: Mellemrum anvendes langt oftere end tabs.
De syv sprog er i øvrigt JavaScript, Java, Python, Scala, Ruby, C# og PHP.
7 / 10
Det er normalt, at man anvender parenteser, når man definerer funktioner eller metoder.
I nogle programmeringssprog er det imidlertid valgfrit.
Nogle programmører vil altid anvende dem. Men det gælder ikke Ruby-udviklere, der klart mener, at man ikke skal anvende parenteser i argumenterne, hvis ikke der er noget at fylde i dem (som nogen ellers mener).
Ruby-folkene vil i stedet altid skrive
def some_method
# do something...
end
fremfor
def some_method()
# do something...
end
8 / 10
Mange programmører har lært, at man skal skrive konstant-navne MED VERSALER.
Andre finder det ret gammeldags.
350.000 GitHub-commits i Java, C# og PHP viser, at der faktisk ikke er nogen særlig udbredt enighed om fremgangsmåden.
53 procent foretrækker at skrive konstant-navne MED VERSALER.
9 / 10
Man kan pakke strenge i JavaScript in i enten enkelte eller dobbelte citationstegn, altså:
var foo = 'bar';
eller
var foo = "bar";
1,6 millioner GitHub-commits viser, at begge valgmuligheder er ganske udbredte. Et flertal - 57 procent - anvender dog det enkelte tegn og ikke det dobbelte.
10 / 10
Enhver programmør, der skriver kode-blokke, er nødt til at beslutte, om de krøllede parenteser skal sættes på en ny linie eller på samme linie som deklarationen.
Altså om han skal skrive
class Foo
{
// ...
}
eller
class Foo {
// ...
}
Ud af halvanden million GitHub-commits til Java, C# og PHP blev der alene sat krøllet parentes på en ny linie i 30 procent af tilfældene, så konventionen er ganske klar: Sæt tegnet på samme linie.
