Avoid lines longer than 80 characters

Avoid lines longer than 80 characters
februari 14, 2013 squeedconfig

En del av Oracles kodkonvention är idag, 2013, denna:

Avoid lines longer than 80 characters, since they’re not handled well by many terminals and tools.

Jag är mycket kritisk till denna begränsning. Jag möter väldigt få skärmar som inte kan visa åtminstone 120 tecken per rad. I min mening ligger logiken på höjden och därför vill man se så mycket på höjden som möjligt i meningen: radbryt inte för att koden skall se vacker ut om man skulle skriva ut den på papper. Jag ser oftast kod som att varje rad har ett syfte, en uppgift. När en uppgift börjar ta upp 7-8 rader pga en kodkonvention från 1990-talet så känns det som en suboptimering.

Jag skickade nyligen följande mail (ett utdrag), som svar till förslaget ”låt oss köra på Eclipse standardformatering, den är ju ändå standard”.

Radbredd påverkar läsning, och som
välbekant sitter vi och läser kod mån-
ga gånger fler än vi sitter och skriver.
Därför är det intressant att hitta den
modell som de flesta är bekväma
med – så att man får så få överrask-
ningar som möjligt i det dagliga
arbetet.

Mer intressant vore det att införa
en riktlinje i antal rader per metod,
och per klass, och se hur påverkar
läsbarheten och hur underhållsvän-
lig koden blir!

Övningar på dessa lite svårare frågor –
frågor som kan bli ”religiösa” och på-
verka teamkänsla uppåt och nedåt –
är något jag kört de senaste två åren
med 9 andra bolag, men inte XXX.

Software Craftmanship handlar om:
* det är människor som läser källkod
* den stora flaskhalsen är inte pre-
standa i form av CPU- och minnesåt-
gång (XYZ undantaget) – de flesta
kämpar med att få ut mer features
ur sina projekttimmar. För att lyckas
med detta behövs inte bättre algo-
ritmer, det behövs bättre arbetssätt
inom team. Se därför till att optime-
ra de mänskliga aktiviteterna, såsom
minska kodlästid genom bättre
namngivning, mindre klumpar kod
och så få överraskningar som möj-
ligt (vilket ju blir per team).

Så, nu har jag delgett några tankar
och visat hur annorlunda det är att
begränsa radbredd på ett så snävt
sätt som Eclipse built-in code form-
atter gör. Jag hoppas detta upp-
fattas lagom rebelliskt. 🙂

Med omtanke om människan, och
därmed organisationen,

Fredrik

Det finns en hög med brasklappar man kan slänga ut här (merge-scenario t ex), men avstår för att inte föregå en eventuell diskussion.

1 Kommentar

  1. avajadi 6 år sedan

    Åter ett exempel på vilken dinosaur Oracle är, och då är det inte storleken jag syftar på. Företaget lever helt och hållet på sina bedrifter med Oracle DB, vilka ju i stort sett hör hemma i just 90-talet. På senare år har de mer gjort sig kända för att köpa upp framgångsrika OSS-projekt, som MySQL, OpenOffice och även Java, och rasera utvecklingsprocessen. I fallet MySQL så hade ju dessvärre Sun redan innan de köptes av Oracle lyckats alienisera kärntruppen av utvecklare, men det tog ju inte lång tid att tappa greppet om OpenOffice med splittring som följd. Av allt att döma lägger de nu stora resurser på att skjuta Java i sank.
    Ursäkta min rant, som ju definitivt är OT, men det blev så tydligt med det här blogginlägget hur stendött Oracle är framstegsmässigt… 🙂

Lämna ett svar

E-postadressen publiceras inte. Obligatoriska fält är märkta *

*

Denna webbplats använder Akismet för att minska skräppost. Lär dig hur din kommentardata bearbetas.