Källkods formatering - 160 tecken/rad

[GoogleCodeExporter]

Software and Version
********************
Källkods formatting.
Radlängd bör ökas till 160 tecken.

Reason for change
*****************
Radlängden är idag satt till 115 tecken. Detta är ofta för kort för att 
kunna uttrycka metodsignaturer på en rad, vilket gör källkoden svårare att 
läsa.

- Problemet beror till viss del på att vi använder SpringPortletMVC där 
metodsignaturer innehåller många annoteringar som tar stor plats.
- En annan orsak till problemet är att vi i allt högre grad använder oss av 
självbeskrivande namn på metoder och parametrar - dessa blir därför längre 
och man får lätt omotiverade radbrytningar i signaturerna.

Metodsignaturer med radbrytningar innebär att man förlorar läsbarhet. Med 
för korta rader riskerar man att helt förlora vinsten med läsbara namn.

- De främsta konsumenterna av källkod (och därmed de som framför allt skall 
tillgodoses) är vi själva. Idag sitter vi alla med dubbla skärmar med hög 
upplösning. Det är inga problem att läsa filer med rader på 160 tecken.
- Läsbarhet är en väldigt viktig faktor för att kunna producera kod av hög 
kvalitet, när man dessutom väger in att man i snitt läser kod 80% av tiden, 
mot skriver den 20% så inses lätt att genom att göra koden mer lättläst 
så kan mer tid ägnas åt att skapa värde.

Vi har redan insett att kod-stilguider behöver anpassas över tiden.
- Sun's 10 år gamla style-guide säger 80 tecken/rad.
- För tre år sen hade vi skärmar som klarade 115 tecken.
- Nu har vi skärmar som klarar 160 tecken.

Impacts
*******
- License cost
0

- Education
Berätta på en standup.

- Migration / adaption of existing software
Ändra checkstyle mallen.
Ändra utvecklings miljön (Eclips/IntelliJ)

- Risks
None

Does this replace some existing, already approved, software
***********************************************************
(Please specify what software and version)

Earlier experiences of the suggested software
*********************************************

Original issue reported on code.google.com by wmda...@gmail.com on 11 Oct 2011 at 7:43

[GoogleCodeExporter]

started investigation

Original comment by Hans.Gyl...@gmail.com on 11 Oct 2011 at 11:30

• Changed state: InProgress

[GoogleCodeExporter]

Status:
*******
Declined

Decision and limitation:
************************
The length per line remains 115 characters as stated in 
http://code.google.com/p/oppna-program/wiki/Anpassningar_av_VGRs_utvecklingsmilj
o

Motivation:
***********
The guidelines are set up to take in to account several consideration:
- pair programming situations (that is why the font size is defined as 14 pixel)
- enabling developers with a specific computer set up (e.g. 15" lap top) to work

Research:
*********
- After research there seems to be a attitude that SUN´s old 80 characters 
suggestion is outdated and moved to more like max 120 characters per line.
- Asking people in the team as well as ICC team about oppinion
- Java Ranch max 120 characters: http://www.javaranch.com/styleLong.jsp#length
- Android: Max 100 characters: 
http://source.android.com/source/code-style.html#limit-line-length
- Take into account people with dissabilities or laptops
  http://krbtech.wordpress.com/2010/03/06/sun-java-coding-conventions-revisited/
  "4.1. Line Length
   The line length limit of 80 is an anachronism, a relic of text mode terminals and days gone by when printing source code was common. 
   These days, though, it is no longer practical. Source code is rarely printed, lines are longer, and a short line maximum means more 
   line continuations, which means code that is less readable. 
  There should be a maximum, but it should be higher than 80. It should take into account typical use cases of developers 
  (e.g. screen size/resolution and window width), but also accommodate less common cases (e.g. developers who use larger font sizes due to vision issues)."

Suggestion to solve problem with long method signatures
*******************************************************
If long methodnames arrise having lots of annotations then line up each 
argument on a separate row like:
@RequestMapping(value = "/add", method = RequestMethod.GET)
public ModelAndView addUserMethodWithVeryLongName(
                                   @ModelAttribute("userVariableName") Event event,
                                   @Annotation(paramname) ClassX xname,
                                   @Annotation(paramname) ClassY yname,
                                   @Annotation(paramname) ClassZ zname
                                                  ) throws ... {

Original comment by Hans.Gyl...@gmail.com on 14 Oct 2011 at 12:45

• Changed state: Declined