Sjekket 925 Android-apper: De som var skrevet i Kotlin hadde «høyere kodekvalitet» enn de skrevet i Java

[Erlend Tangeraas Lygre]

Færre «blobber» og «sveitserknivklasser».

Sjekket 925 Android-apper: De som var skrevet i Kotlin hadde «høyere kodekvalitet» enn de skrevet i Java

[Gjest Slettet+5132]

Jeg er ikke enig i konklusjonen:

 

«Når man ser på den umiddelbare effekten av å introdusere Kotlin i Android-applikasjoner, ser vi at introduksjonen står for en økning i kodekvaliteten på minst 50 prosent», konkluderer forskerne.

 

Her kan en grunn være at folk som velger Kotlin er i gjennomsnittet mer opptatt av kodekvalitet enn den gjennomsnittlige Java-utvikler, i og med at de har gjort et bevisst valg i å bytte språk bort fra default-språket. Det finnes mange java-utviklere som er opptatt av kodekvalitet, men siden Java er default-språket for Android, ender alle som ikke er opptatt av kodekvalitet også opp med Java.

 

Samtidig er Kotlin et nytt språk, som betyr at programmer skrevet i Kotlin er relativt nye og ikke sliter med gammel bagasje. 

Endret 3. august 2018 av Slettet+5132

[Erlend Tangeraas Lygre]

Jeg er ikke enig i konklusjonen:

 

«Når man ser på den umiddelbare effekten av å introdusere Kotlin i Android-applikasjoner, ser vi at introduksjonen står for en økning i kodekvaliteten på minst 50 prosent», konkluderer forskerne.

 

Her kan en grunn være at folk som velger Kotlin er i gjennomsnittet mer opptatt av kodekvalitet enn den gjennomsnittlige Java-utvikler, i og med at de har gjort et bevisst valg i å bytte språk bort fra default-språket. Det finnes mange java-utviklere som er opptatt av kodekvalitet, men siden Java er default-språket for Android, ender alle som ikke er opptatt av kodekvalitet også opp med Java.

 

Samtidig er Kotlin et nytt språk, som betyr at programmer skrevet i Kotlin er relativt nye og ikke sliter med gammel bagasje. 

Dette er interessant. Studien tar ikke for seg årsakene til økningen i kodekvaliteten, men slår bare fast at den finnes.

 

De sier ikke om det er språket i seg selv, eller andre faktorer som forårsaker funnene. Andre årsaker kan være at mer kompakt kode – altså mindre kodemengde – i seg selv minsker antall feil.

 

En annen årsak kan igjen være at enkelte skriver om Java-appene sine i Kotlin. Når man skriver den samme programvaren på nytt, blir jo kodekvaliteten stort sett bedre uansett hvilket språk man velger.

 

Sjekk forøvrig ut kommentarfeltet hos The Register, som omtaler den samme studien. Her har de en interessant debatt om det du nevner her. https://forums.theregister.co.uk/forum/1/2018/08/02/kotlin_code_quality/

 

Mvh artikkelforfatter.

[Gjest Slettet+5132]

Dette er interessant. Studien tar ikke for seg årsakene til økningen i kodekvaliteten, men slår bare fast at den finnes.

 

De sier ikke om det er språket i seg selv, eller andre faktorer som forårsaker funnene. Andre årsaker kan være at mer kompakt kode – altså mindre kodemengde – i seg selv minsker antall feil.

 

En annen årsak kan igjen være at enkelte skriver om Java-appene sine i Kotlin. Når man skriver den samme programvaren på nytt, blir jo kodekvaliteten stort sett bedre uansett hvilket språk man velger.

 

Sjekk forøvrig ut kommentarfeltet hos The Register, som omtaler den samme studien. Her har de en interessant debatt om det du nevner her. https://forums.theregister.co.uk/forum/1/2018/08/02/kotlin_code_quality/

 

Mvh artikkelforfatter.

Takk for utfyllende svar, men mener du ikke at ordlyden i konklusjonen du siterer i artikkelen hevder at kodekvalitetsforbedringene kom på grunn av Kotlin? "den umiddelbare effekten av å introdusere Kotlin i Android-applikasjoner, ser vi at introduksjonen står for en økning i kodekvaliteten på minst 50 prosent", jeg klarer ikke å tolke den setningen som noe annet enn at de mener Kotlin fører til bedre kodekvalitet.

[RulleRimfrost]

Studier og 'forskning' kan være ymse. Mengder av kvalitative studier presenteres med suspekt utvalg, og kvantitative med naive konklusjoner uten hensyn til konfunderende faktorer.

 

Tror kanskje en mer korrekt hypotese her kunne være: Kotlin-uviklere skriver mer korrekt kode enn java-utviklere?

[tommyb]

Kan det være at de som har fått tid til å sjekke ut Kotlin er under mindre tidspress enn de som skrev java-appene? Det kan være det til og med er de samme utviklerne, før og etter tidspresset.

[Erlend Tangeraas Lygre]

Pengent: Tror du kan ha rett her. Har fjernet konklusjonen fra vår artikkel, da jeg synes oversettelsen ble litt muggen etter å ha sett på den igjen.

 

Her er originalkonklusjonen i studien, på engelsk.

 

«We concluded our study analyzing the impact of Kotlin on the quality of an

Android application. Regarding the immediate impact of introducing Kotlin on

Android applications, i.e., the first version that has Kotlin code, we found that

the adoption of Kotlin produces a rise of the quality from, at least, 50% of the applications».

 

Her skriver de at "the adoption of Kotlin produces a rise of the quality...". I mine øyne er dette litt tvetydig. Dette tolker i alle fall jeg som at de gir Kotlin æren for kvalitetsøkningen,

[quantum]

Er null i Kotlin noe annet enn i Java? Hvis ikke vil jeg si det er en smule bedre kodekvalitet i javakoden her ...

[Gjest Slettet+5132]

Er null i Kotlin noe annet enn i Java? Hvis ikke vil jeg si det er en smule bedre kodekvalitet i javakoden her ...

 

Tenker du på sjekken "checkNotNull"? Såvidt jeg har lest, kan variable kun være null hvis typen tillater null (altså mer eller mindre hvis man har ? etter typenavnet), ellers tillater ikke språket at variable blir satt til null. Det vil si at parameterne konstruktøren mottar, ikke kan være null (ellers får man kompileringsfeil). 

[quantum]

Tenker du på sjekken "checkNotNull"? Såvidt jeg har lest, kan variable kun være null hvis typen tillater null (altså mer eller mindre hvis man har ? etter typenavnet), ellers tillater ikke språket at variable blir satt til null. Det vil si at parameterne konstruktøren mottar, ikke kan være null (ellers får man kompileringsfeil). 

 

 

Aha, takk for oppklaringen. Så kodesnutten vi ser tillater altså at funksjonen returnerer null, mens Java-koden returnerer Optional. Spørsmålet blir da hvordan koden som kaller getOrder kodes for å håndtere gullverdien i Kotlin.

[Gjest Slettet+5132]

Aha, takk for oppklaringen. Så kodesnutten vi ser tillater altså at funksjonen returnerer null, mens Java-koden returnerer Optional. Spørsmålet blir da hvordan koden som kaller getOrder kodes for å håndtere gullverdien i Kotlin.

 

Disclaimer: Jeg er ingen Kotlin-utvikler

 

Vel, returverdien "Order?" ser ut å være Kotlins utvida version av Javas Optional. Hver gang du vil bruke medlemmer i returverdien, må du sjekke at verdien ikke er null på en eller annen måte (eg.

 

var order: Order?= blah.getOrder(0)

// Kompilerer (name blir null hvis order er null, ellers returnerer den orgName)
var name: String? = order?.orgName

// Kompilerer ikke: (mangler ? foran .)
var name: String? = order.orgName

// Kompilerer ikke: (typen kan være null)
var name: String = order?.orgName

// (Hvis variabelen er lokal, kan man også eksplisitt sjekke for null før man gjør noe)
if (order != null) {
   // kompilerer, inne i if-setningen, har vi garantert at order ikke er null 
   // (gitt at order er en lokal variable kun tilgjengelig fra en traad. Antar kompilatoren sjekker dette)
   var name: String = order.orgName
}

)

(sikkert et par typos i koden over )

Endret 6. august 2018 av Slettet+5132

[quantum]

 

Disclaimer: Jeg er ingen Kotlin-utvikler

 

Vel, returverdien "Order?" ser ut å være Kotlins utvida version av Javas Optional. Hver gang du vil bruke medlemmer i returverdien, må du sjekke at verdien ikke er null på en eller annen måte (eg.

 

var order: Order?= blah.getOrder(0)

// Kompilerer (name blir null hvis order er null, ellers returnerer den orgName)
var name: String? = order?.orgName

// Kompilerer ikke: (mangler ? foran .)
var name: String? = order.orgName

// Kompilerer ikke: (typen kan være null)
var name: String = order?.orgName

// (Hvis variabelen er lokal, kan man også eksplisitt sjekke for null før man gjør noe)
if (order != null) {
   // kompilerer, inne i if-setningen, har vi garantert at order ikke er null 
   // (gitt at order er en lokal variable kun tilgjengelig fra en traad. Antar kompilatoren sjekker dette)
   var name: String = order.orgName
}

)

(sikkert et par typos i koden over )

 

 

Hm, ser mer ut som default nullpointer exception catching ... litt usikker på om jeg syns det er et framskritt. Hvis man er disiplinert med hvor man bruker det kanskje ...

[Gjest Slettet+5132]

Hm, ser mer ut som default nullpointer exception catching ... litt usikker på om jeg syns det er et framskritt. Hvis man er disiplinert med hvor man bruker det kanskje ...

See for meg at ?.-operatoren fort kan by på hodebry ved debugging. Istedenfor å gi nullpointerexception hvor det første objektet er null, risikerer man at I en funksjon langt borte er medlemsverdien av medlemsverdien av ... av medlemsverdien null, kun fordi det første objektet var null et sted og noen bare aggregerte opp ?. hele tida.

[Anders Hagelin Abrahamsen]

 

Hm, ser mer ut som default nullpointer exception catching ... litt usikker på om jeg syns det er et framskritt. Hvis man er disiplinert med hvor man bruker det kanskje ...

See for meg at ?.-operatoren fort kan by på hodebry ved debugging. Istedenfor å gi nullpointerexception hvor det første objektet er null, risikerer man at I en funksjon langt borte er medlemsverdien av medlemsverdien av ... av medlemsverdien null, kun fordi det første objektet var null et sted og noen bare aggregerte opp ?. hele tida.

Ideen er at man uansett ser dette i kompileringsøyeblikket, se https://kotlinlang.org/docs/reference/null-safety.html

[Gjest Slettet+5132]

Ideen er at man uansett ser dette i kompileringsøyeblikket, se https://kotlinlang.org/docs/reference/null-safety.html

 

Joda, har lest den sida der. Poenget mitt var vel mer at siden det er så lett å skrive "?.", blir defaultoppførselen for de fleste rett og slett å propagere det utover i koden. Så en kan ha tilfeller ala

(bruker her et veldig forenkla eksempel med frie funksjoner for å få ned kodemengden):

fun orgNameOf(orderService: OrderService): String? {
    // her er det tenkt at man gjoer litt annet snacks i tillegg, men
    // lar funksjonen vaere ganske enkel her 
    // masse skjer
    return orderService.getOrder(0);
}
// for aa ta en lokal variant
fun getBroennoeysunnRegisterNumber(String? orgName) : String? {
    return orgName?.someFunctionEgSplit()
}

fun displayRegisterNumber(orderService: OrderService) {
    print(getBroennoeysunnRegisterNumber(orgNameOf(orderService)))
}

Kjører man denne koden, får man en utskrift med null, men man ser ikke hvor man fikk null, og en har ingen stacktrace for å finne ut hvor man først fikk returnert null. Endret 6. august 2018 av Slettet+5132