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 …
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
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.
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.
@ 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
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.
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.
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.
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.
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.
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.
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.
"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.
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.
This post has been deleted by its author
"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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
