Slashdot Mirror
Your Java Code Is Mostly Fluff, New Research Finds
itwbennett writes In a new paper (PDF), researchers from the University of California, Davis, Southeast University in China, and University College London theorized that, just as with natural languages, some — and probably, most — written code isn't necessary to convey the point of what it does. The code and data used in the study are available for download from Bitbucket. But here's the bottom line: Only about 5% of written Java code captures the core functionality.
I'll admit I just read the summary article and not the paper itself, but I wouldn't say that this is overly surprising.
Right off the bat due to this preoccupation we Java types seem to have with accessor methods (which I think if we admit, do something besides just set or get a private member variable like 1% of the time, why the hell we still do this I don't know..), and the frequent necessity for hash, clone, and equals methods, most of which is auto-generated, you end up with a bunch of small methods that do very little but up the code count.
Beyond that, I think good design usually works out this way. You (or at least I like to) build up in layers, each layer using the previous layer at a higher level, until you get to the top where you have a few seemingly simple bits of code that pull it all together. When you get big complex functions doing a bunch of stuff vs the described small functions adding little bits of functionality along the way, I think you are doing things wrong.
That's not to say people (and this is common in Java) go way overboard and end up with huge chains of methods that just pass the buck and complex control structures where you need a debugger to figure out whats going on, but if done right it can make for easily maintained and readable code.
This article uses a lot of words to say absolutely nothing.
No. This is what happens with a language with an extremely verbose API and extreme boiler-plate requirements. The best Java developer in the universe isn't going to be able to get around this.
But I shoot to make 100% of the code I write fluff.
Democracy Now! - your daily, uncensored, corporate-free
Yes
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
Did you know that only about 5% of the average house is actually load bearing? The rest is just fluff. Why are we wasting so much valuable material in houses?
Ok, here's the deal, sometimes readability is in fact a function of how succinct something is, not how verbose it is. In human (verbal) languages and in cross-cultural communication we refer to this as high-context and low-context language. In code, a parallel could be applied. Succinctness is not a value in itself (read Paul Graham's defense of Lisp vs. Python, I disagree with Graham), but it can often be a good means to an end when context surrounding your identifier choice is clear as freakin' day.
But contrary to python or ruby code, for example, most Java code is not written by hand. No one ever writes import statements for example. Eclipse is so excellent at understanding Java code structure that the writing efficiency is comparable. It brings other benefits too -- I have found re-factoring of large code bases is substantially easier in Java than any other language. This is thanks to the strong structure implied by the language, which can be exploited by tools. In other languages this is prohibited, e.g. Ruby, where every word can mean something different and you can not know until runtime, or C when cluttered with macros.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
Yes, but the point is silly anyway.
The notion that everything that isn't core functionality is "fluff", gives the impression that it is non-essential.
Let's say I have a weather application that reports meteorological data for a specific zipcode. Let's say that I have a super slick user interface, and I display animated weather graphics in HD.
Fluff?
Not at all. A spartan application which displayed a bunch of plaintext data might have zero downloads. Sexy, eye candy might equate to 20 million downloads.
Which raises the question: What is the actual point of this app? Is it to display weather information?
No. The point of this app is to get downloaded.
So what's "core" again?
------ The best brain training is now totally free : )
Agreed. As the saying goes: "The devil is in the details".
It's often very easy and quick to write the "core" functionality, but dealing with exceptions (both in workflow and code), one-offs and special rules, shifting requirements, scope creep, etc, etc... It may not be core, but it's a huge amount of work to write it all. I remember a saying that went something like "80 percent done... now you've only got 80 percent to go", meaning that the perception of being "nearly finished" is much different than the reality.
It's especially bad when you're racing to meet a milestone with payment tied to specific functionality (I've seen this in the videogame industry), and just barely write enough code to more or less hit that "easy" initial 80 percent, but never get that "last 80 percent" until the end of the project. It ends up as a hellish crunch-mode disaster at the end of the projects, with managers not understanding why the project seems to implode near the end.
Irony: Agile development has too much intertia to be abandoned now.
So they tossed methods that were wrtten well. (methods that only do one thing) So if you wrote a simple 2 line validation of an input field. Field must be populated. Field must match regex. They tossed that as chaff?
Why the Hell should you have to write code over and over to validate that a reference isn't null, or an int is positive, or other such cases. Sure that's all part of the interface contract anyhow, right? For that matter, why is "allowed to be null" the default rather than an exceptional special case. Why isn't there a simple operator that decorates a parameter as "nullable" with a single character.
Why not simply
public Foo foo;
No getter or setter needed, by default it can't be null. For those odd cases where null actually means something useful, then just write:
public Foo? foo;
This goes double for C#, where "?" is already established as the "nullable" decorator.
Worth noting that many Java coders use Lombock to effectively achieve this already, just with auto-generated getters and setters, since we lack the courage ad/or authority to just have public members instead of pointless getters and setters.
And, above all else, give us a way to declare that the returned value can't be null, and auto-throw if it is, so the caller never has to check!
Socialism: a lie told by totalitarians and believed by fools.