back to article Well, this makes scents: Kotlin code quality smells better than Java

Kotlin, which Google blessed last year as an alternative to Java for programming Android apps, has already made its way into almost 12 per cent of open source Android apps, and in so doing has elevated their code quality. So we're told by computer scientists Bruno Gois Mateus and Matias Martinez, affiliated with University of …

  1. Fruit and Nutcase Silver badge
    FAIL

    Just give it time...

    Looking at the given reference

    https://sourcemaking.com/antipatterns/the-blob

    Typical Causes:

    Lack of an object-oriented architecture.

    Lack of (any) architecture.

    Lack of architecture enforcement.

    Too limited intervention. In iterative projects,

    Specified disaster.

    ...the right tool in the wrong hands will only end in disaster - wait for the great unwashed to move over en-mass to Kotlin and it too will start to stink

  2. Overflowing Stack

    Yes, great, lovely

    I don't have the time to learn it....I'm in the pub... oh I do.

    I should be attacked with sharks with mini non-lethal lasers

  3. Jay Lenovo
    IT Angle

    Sitting on my thinking chair

    "Paprika" as the name of the testing app?

    Code quality detective work, inspired by our gang on "Blue's Clues"

  4. Friendly Neighbourhood Coder Dan

    Fewer lines of code == fewer bugs?

    Sounds to me like saying that if I use 40% fewer words the quality of an essay will improve

    Dunno, maybe if people develop using a plain text editor rather than Eclipse? And that would just be typos and syntax errors, rather than fewer bugs.

    But it's just my opinion, maybe I am missing something obvious.

    1. a_yank_lurker

      Re: Fewer lines of code == fewer bugs?

      Concise text or code is generally easier to follow its logic. Clarity begets understanding. In code concise languages have less pointless boiler plate to wade through (and make sure it is correct). However one can be too concise to point of being cryptic (the concern you alluded to) such as nesting several functions that could be hard for someone not intimately familiar with the functions and the language to be confused.

      Java is accused of having excessive boiler plate that has to be waded through to get to the meat. And this boiler plate needs to be syntactically and logically correct. So adding boiler plate, the theory goes, adds more places for subtle errors to creep in and more items to keep track of. So any removal of boiler plate removes sources of bugs and means there is less to keep track of. Thus, the idea goes, less to worry about the less potential sources of errors and the more likely one is more focused on the meat to begin with.

      1. Friendly Neighbourhood Coder Dan

        Re: Fewer lines of code == fewer bugs?

        @ a_yank_lurker - Ah, that makes sense, thanks for the reply...

        It makes sense to me now. I was mainly thinking about former colleagues whose work could only have been helped by a miracle, couldn't see how less typing would have helped :-) Proper Thedailywtf grade material

      2. Doctor Huh?

        Re: Fewer lines of code == fewer bugs?

        You can argue that boiler-plate patterns ought to be incorporated into the language. Any case where the IDE could automatically generate code (Java bean pattern, for example), could be made a case for a language extension that would allow the compiler to generate the code.

        So that code DOES offer an opportunity for bugs, but they are only likely to occur if the meatsack at the keyboard messes with the generated code.

        I choke at the notion of counting lines as a measure of conciseness, but I'm from a time where the size of the input file mattered, so readability would be sacrificed to the Great God of the 180K Floppy Disk. I much prefer readability. I _like_ if statements that take up 3 or more lines, with one of them devoted solely to the closing bracket. I _like_ always using brackets for clauses, even where they are optional. It vastly increases readability and decreases screw-ups.

        Often concise code uses obscure or infrequently-used features of the language. You may be a bad-ass C programmer who can go 5 levels deep into ?: constructs with multiple comma operators and fit 50 lines' worth of if statements in a single line, but if you are lucky, in any given country the number of people who can make sense of such a line might fit into a single bathroom stall. If you are very lucky, YOU still might be eligible for the stall 6 months after having written that monstrosity.

    2. ecofeco Silver badge

      Re: Fewer lines of code == fewer bugs?

      It's called "bumming the code" and it's generally always a good thing.

    3. deadlockvictim

      Re: Fewer lines of code == fewer bugs?

      FNCD» Sounds to me like saying that if I use 40% fewer words the quality of an essay will improve

      Very often it will, unless it is made too terse.

      Writers often tend to the verbose. I learnt this a newspaper editor who told me about writing articles for mainstream and tabloid papers. Often an article can be re-written without loss of content and reduced in size by as much as 60%. One has to train one's self to write succinctly.

    4. HmmmYes

      Re: Fewer lines of code == fewer bugs?

      The logic describes what a program does.

      The syntax describes how it does it.

      Java's syntax is way too verbose so the wheat (logic) gets lost in the chaff (syntax).

      It takes years to see thru syntax and see the logic.

      Whats missing from Java is a decent run-time, something to join up programs.

      Objective_C has one and its proved very successful.

      The closest Java comes is a hulking server.

      Oh, and being able to easily and safely split a java program into libraries. 20 odd years they are solving that. Way too slow.

      To quote Joe Armstrong - If you are writing code for a DV player then Java is fine.

  5. Kevin McMurtrie Silver badge

    Smells like code analizers

    Sniffers need a sniff.

    I've worked at a place that enforced certain metrics before a check-in could continue. One metric was that you can't have constructors with too many arguments, even if they're for ORM. You couldn't access class fields without getters and setters, even if that class was private. Complex branching was forbidden, but it was analyzed from optimized bytecode rather than the source. Bit shifting a number by 32 failed with the assertion that "32 is a magic number." On the other hand, 250 lines of nested streams and lambdas, so deep that not even an IDE understood it, was OK.

    1. Charlie Clark Silver badge

      Re: Smells like code analizers

      FWIW Python's PEP 8 notes that foolish consistency is the hobgoblin of tiny minds".

      Any good static code analysis setup should allow the rules to be changed to suit the particular task in hand. Most modern tools do go well beyond the simple and restrictive rules you describe and focus on good idiomatic practice. Never worked with Paprika but the descriptions sound reasonable. Not that they should necessarily block a check-in but to provide feedback to developers as part of code review.

      1. disgruntled yank

        Re: Smells like code analizers

        In the spirit of PEP 8, I ignore a certain number of pylint's messages....

  6. Teiwaz

    Nasal analogies

    Are we to start calling bits of code that are non-buggy but just inelegant 'farts' then.

    I think it's a potentially hairy root to be going down, it'll be taste, next then touch, then may get even more embarrassing. Teaching kids to code is likely to result in being put on a register.

  7. TheMeerkat Silver badge

    Was the average age of apps the same? Kotlin is a newer language and it is a known fact that often the quality goes down with code age.

    1. Ken Hagan Gold badge

      It is also quite possible that the new Kotlin apps are, for those writing them, the second time they've written an app like that (because this is the Kotlin re-write) or that those writing them are just better developers (because they've had the time and inclination to learn another language).

      Similar remarks apply to (nearly?) every comparative study of the effects of language choice on code quality. It is actually extremely difficult to design such a study and remove the effects of people, experience generally, experience with this particular type of problem, and difficulty of the problems under study. I've never seen it done and I'm not sure it can be.

    2. Anonymous Coward
      Anonymous Coward

      Newer versions of Android Studio allow you to automatically upgrade your Java code to Kotlin, so it's reasonably likely old apps have switched to Kotlin automatically.

      From a non-Java dev fiddling around with Android apps, Kotlin looks like an improvement.

      1. TVU Silver badge

        "Newer versions of Android Studio allow you to automatically upgrade your Java code to Kotlin, so it's reasonably likely old apps have switched to Kotlin automatically"

        Google promoting Kotlin at the expense of Java comes as no surprise since it enables them out of the malign clutches of litigious Oracle.

        1. disgruntled yank

          Yes to "malign clutches"

          But what is the legal status of the JVM?

  8. ratfox

    Is it that Kotlin is a better programming language, or is it that people who suck at programming don't use recent programming languages?

    1. Anonymous Coward
      Anonymous Coward

      No, it's a far better programming language.

    2. TonyHoyle

      It's a better programming language overall. Developed by Jetbrains who know what programmers want out of a language (they also developed the IDE for it). It supports multiple programming styles & the community has built up around it like that.. for example if you're into functional programming, go for it, if you prefer OO, that's fine too.

      OTOH it provides you with more than enough tools to shoot yourself in the foot with both barrels, reload then fire again. Which I predict plenty of people will do once it gets more popular.

  9. Nosher

    Proof reading

    Interesting paper and all, but aren't these things supposed to be at least minimally proof-read before publication?

  10. steelpillow Silver badge
    Coat

    The smell of outdated coding practices

    Elderberries?

    1. Teiwaz
      Coat

      Re: The smell of outdated coding practices

      The smell of outdated coding practices

      Elderberries?

      GooseberriesIn honour of Ergo the Magnificent*

      * Well I liked Krull.

    2. dajames

      Re: The smell of outdated coding practices

      Elderberries?

      Only if your mother was a hamster.

  11. This post has been deleted by its author

  12. HmmmYes

    What is 'Lack of an object-oriented architecture.'

    What is 'object-orientated'

    Can I measure it. simply???

  13. stephanh

    40 per cent less code than they would with Java.

    Only 40% ? Man, Kotlin is verbose.

  14. J27

    "With fewer lines of code, in theory, one can expect fewer bugs."

    This sentence doesn't "smell" right. Lines of code is mostly an irrelevant metric with high-level languages. It's definitely not something you can just take as a given that less lines = fewer expected bugs. You can pack a tonne of things into one line in a lot of languages, that doesn't make it more readable.

    Kotlin is less verbose than Java (which is not hard), and that's great, but that isn't the reason it's better for catching mistakes. Kotlin has better compile time support for finding certain errors and better signalling for Nullable/Nonnullable/various other things. Android Java is like a old warship that's been rennovated 10 times, new hardware bolted all over it. Kotlin is a new warship designed from the ground up with all that new technology.

    Is anyone else surprised that Android is using Kotlin instead of Dart? You'd think Google would to slowly move us towards Flutter.

    1. HmmmYes

      No.

      300 column lines apart, the less code, the clearer the ptogram.

      CAR Hoare

      'There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. '

      Its one reason why Ansi C is successful - simple lannguage, simple libraries.

      My issue with complex languages and complex libraries is not whether i can use them - I can! Trust me!!

      Its whether the 3rd party delivering and maintaining them doesnt fuckup on some version down the line.

      The success of any long running software products depends on hiw easy the product is to test and update.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like