Skip to main content

It's more important that Java programs be easy to read than to write

21 replies [Last post]
fuerte
Offline
Joined: 2004-11-22

Graham Hamilton says (http://java.sun.com/developer/technicalArticles/Interviews/hamilton_qa2....) that

"It's more important that Java programs be easy to read than to write".

Is the following easy to read?

String link="";
String regexpForLink="<\\s*a\\s+href\\s*=\\s*\"http://widgets.acme.com/interface.html#([^\"]+)\">";

Wouldn't it be easier if Java had literal strings like C#, so that backslashes would not need to be doubled, and quotation marks wouldn't need to be escaped?

String link=@""@;
String regexpForLink=@"<\s*a\s+href\s*=\s*"http://widgets.acme.com/interface.html#([^"]+)">"@;

How about the following SQL code at
http://dorm.tunkeymicket.com/cs311/mp1/mp1.java

String sql = "SELECT DISTINCT " +
" name," +
" store_location," +
" format," +
" length," +
" year," +
" price" +
" FROM" +
" movie," +
" rental" +
" WHERE" +
" movie.id_number = rental.movie_id" +
(loc.equalsIgnoreCase("*") ? " " : " AND store_location = '" + loc + "'") +
" AND " +
" (start_date - TO_DATE('" + startdate + "', 'YYYY/MM/DD')) >= 0" +
" AND " +
" (return_date - TO_DATE('" + returndate + "', 'YYYY/MM/DD')) <= 0" +
(name != null ? " AND name = '" + name + "'" : " ") +
(format != null ? " AND format = '" + format + "'" : " ") +
(year != null ? " AND year = '" + year + "'" : " ") +
(price != null ? " AND price = '" + price + "'" : " ") +
" ORDER BY " +
" year," +
" name," +
" format ";

Wouldn't it be easier to read if it was written like

String sql = String.format(@"
SELECT DISTINCT
name,
store_location,
format,
length,
year,
price
FROM movie,
rental
WHERE movie.id_number = rental.movie_id
%s
AND (start_date - TO_DATE('%s', 'YYYY/MM/DD')) >= 0
AND (return_date - TO_DATE('%s', 'YYYY/MM/DD')) <= 0
%s%s%s%s
ORDER BY
year,
name,
format
"@,
loc.equalsIgnoreCase("*") ? "" : " AND store_location = '" + loc + "'",
startdate,
returndate,
name != null ? " AND name = '" + name + "'" : "",
format != null ? " AND format = '" + format + "'" : "",
year != null ? " AND year = '" + year + "'" : "",
price != null ? " AND price = '" + price + "'" : ""
);

If you agree, then go here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4472509

The current evaluation is: "This is yet another request for a syntactic sugar to save some user from
typing. It's not worth it."

On the contrary, verbatim strings would make the code more readable and would also ease development.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
patrikbeno
Offline
Joined: 2004-10-11

> There are pros and cons to having everything as
> virtual. Performance is a prime reason. It also
> makes it easier to see what methods are intended to
> be overridden. Of course, the con is that sub
> classes might be limited to what is allowed.

Performance of virtual call can be safely left up to JVM and hotspot, it can optimize it quite fine. Besides this, performance bottlenecks usually are elsewhere.

If any method is not intended to be overriden, make it final. That's what it is for. You can even make whole class final which makes all its methods final, too.

yishai
Offline
Joined: 2003-11-16

> It is one of the things that makes C# better. I am
> not saying that it is THE thing that makes C# better.

I don't think it is enough to rate a feature (unless you evaluating a scriptiong language). Which gets me to my point. For what kind of project is C# better than Java? That is the first question to provide some context about what feature is useful and what isn't.

> Another one: the
> way I can declare methods as virtual instead of
> having everything as virtual.

Everything isn't virtual in Java. They can be declared final. Everything is virtual by default. In C# you have a three state inheritence model which tries to solve a problem, but it introduces complexity. There is no question about it that Java has a simplicity streak in it. That is the core language concepts attempt to balance functionality with simplicity, and simplicity has a pull.

A non-final-but-non-virtual default behavior is more complex, and it both solves and creates problems. I don't think that constitutes superiority. Definitely from the perspective of flexibility the Java way gives you options if you are dealing with a limited API. C# can cut you off at the knees at a critical junction. Or at least it seems that way to me. I've only read about C#'s features.

> Look at the way C# handles properties, it's much
> h more elegant than getter/setter that Java has to
> offer (OK, I know Java is working to include
> properties in the next release).

See, that is another example of Java simplicity. Properties are a macro-expanded method. In Java, you just have methods. That they are, or are not, properties is an implementation question, not another one-off feature of the language. I prefer it that way.

Besides, C# allows operator overloading, and that is the line for me. It is just plain evil.

And then there is the lack of checked exceptions.

patrikbeno
Offline
Joined: 2004-10-11

> See, that is another example of Java simplicity.
> Properties are a macro-expanded method. In Java, you
> just have methods. That they are, or are not,
> properties is an implementation question, not another
> one-off feature of the language. I prefer it that
> way.

I do not. If you want to model simple straightforward Java bean, you have to declare each property three times: field, getter, setter. It should be easier. C# has a better solution in this..

yishai
Offline
Joined: 2003-11-16

> I do not. If you want to model simple straightforward
> Java bean, you have to declare each property three
> times: field, getter, setter. It should be easier. C#
> has a better solution in this..

I think the get/set/is convention is a hack for real beans. Real beans should be done in the java.beans package, where currently with a lot of code you could make a bean descriptor which could, via one method in a superclass, modify member variables as a property. Fixing *that* would be worth it.

If you wanted the introduction of properties to be an improvement on the java.beans package, with some language changes to support compile-time checking, and make using java.beans a real possibility, instead of a ton of code for a few use-cases, I would be all for it. A one-off hack in the language, which invisions a bean as nothing more than methods substituting for public variables, isn't much for OO and doesn't rank a language feature, in my opinion.

patrikbeno
Offline
Joined: 2004-10-11

I am not sure I get you :-(

> I think the get/set/is convention is a hack for real
> beans.
> Real beans should be done in the java.beans
> package, where currently with a lot of code you could
> make a bean descriptor which could, via one method in

First of all, get/set/is is a requirement of JavaBeans specification. That cannot be changed dramatically, I guess. And I am not talking about some bean descriptor.

To guarantee OO encapsulation, you have to hide data (make member variables private) and make them accessible via public accessor methods so that you had the control of the get/set process.

I want language to support this OO encapsulation. This is what C# properties do better and Java does not at all (you have to code it manually).

I hope you understand what i want.
Now, please, give me an example of what you have in mind, because I am a little confused by your explanation :-(

yishai
Offline
Joined: 2003-11-16

> I am not sure I get you :-(
I'll try to explain myself better ;)

> First of all, get/set/is is a requirement of
> JavaBeans specification. That cannot be changed
> dramatically, I guess. And I am not talking about
> some bean descriptor.

Not exactly. It is a way to define properties, but it is not the only way. You can have properties which do not do that, provided you write your own descriptors.

> To guarantee OO encapsulation, you have to hide data
> (make member variables private) and make them
> accessible via public accessor methods so that you
> had the control of the get/set process.

I would say that is a very low level of encapsulation. All you get out of that is the ability to do some transformation on the field. You can do much better with beans, but right now the API is so much work that few bother.

> I want language to support this OO encapsulation.
> This is what C# properties do better and Java does
> not at all (you have to code it manually).

Yes, but that is provided in a very primative way. Beans can be so much richer, it would be a shame to calcify the poor understanding of beans into the language, rather than making beans something better.

> I hope you understand what i want.
> Now, please, give me an example of what you have in
> mind, because I am a little confused by your
> explanation :-(

What I want is a better/more usable/easier to use java.beans concept, that could avoid the manual effort, provide the static checking (that part might require some language changes, or annotations might do it, I don't know) that has Java help users make better beans, and design more encapsulated data objects. Encapsulation shouldn't be about just intercepting variable setting. It should be about hiding the data behind the behavior. Otherwise you don't have much of an OO abstraction, and abstraction is what OO is supposed to be about.

patrikbeno
Offline
Joined: 2004-10-11

> Not exactly. It is a way to define properties, but it
> is not the only way. You can have properties which do
> not do that, provided you write your own
> descriptors.

Repeating myself - I don't care about descriptors in this scenario. Properties are about plain data in this use case (and I agree they may be much more). And I need to access them but I do not want to use data fields directly

> I would say that is a very low level of
> encapsulation. All you get out of that is the ability
> to do some transformation on the field. You can do
> much better with beans, but right now the API is so
> much work that few bother.

What much better? How much better? If I won't be able to do this simple thing, it will not be any better.
So what do you suggest? Give an example.

> objects. Encapsulation shouldn't be about just
> intercepting variable setting. It should be about
> hiding the data behind the behavior.

Hiding data behind behaviour is already possible. Where is the problem with this? Or how can this be improved?

What we cannot do (simply) is just that stupid thing: intercepting variable setting.
Define property with corresponding accessor methods in a single step

podlesh
Offline
Joined: 2004-07-26

> It's funny because Java is supposed to be a more mature
> technology, but more and more we see that Java needs to
> learn a lot more from C#.

Funny? It's only logical.

C# is newer, based on Java, but is has some features from other languages, too.

tuthach
Offline
Joined: 2004-09-17

I am glad that somebody finally agrees. There are pros and cons to Java being simple, but being stubborn and not admit to certain weak features of Java is just not going to help Java get any better. Let's just say that if Java does not need a tweak, there would not be the Mustang (1.5) release since most of the features in there are things that already exist in C#/.NET: attributes, for each loop, enum, etc......

yishai
Offline
Joined: 2003-11-16

> I am glad that somebody finally agrees. There are
> pros and cons to Java being simple, but being
> stubborn and not admit to certain weak features of
> Java is just not going to help Java get any better.
> Let's just say that if Java does not need a tweak,
> , there would not be the Mustang (1.5) release since
> most of the features in there are things that already
> exist in C#/.NET: attributes, for each loop, enum,
> etc......

I don't think the Java and C# enum constructs are equivalent. Java's is much better because an enum is an object not a 1/2 primative. ( http://cleveralias.blogs.com/thought_spearmints/2004/01/more_c_enum_wac.... )

But besides that, the objection you are getting is not because you are claiming Java has weaknesses. The whole form topic is because Java has weaknesses. The objection you are getting is that you seem to define strength as simply about who has more syntactical sugar. Syntactical sugar can be important, but that depends on context, and what you are trying to accomplish, and how readable your code would become if it could use such sugar.

tuthach
Offline
Joined: 2004-09-17

It's funny because Java is supposed to be a more mature technology, but more and more we see that Java needs to learn alot more from C#.

dog
Offline
Joined: 2003-08-22

You're trolling.. but I'll bite.

1. Some of us believe that less is more in a computer language (instead you enhance the library)

2. C# is hardly the first language to have this feature (I'm pretty sure PHP's "heredoc" was around before C#, for example)

tuthach
Offline
Joined: 2004-09-17

First of all, I am not trolling. This is the attitude that will get you nowhere. Read my original statement carefully before you speak. I am not talking about PHP, or what language is here first or what comes after or whatever library. I am saying that C# is a superior programming language compare to Java.

> You're trolling.. but I'll bite.
>
> 1. Some of us believe that less is more in a computer
> language (instead you enhance the library)
>
> 2. C# is hardly the first language to have this
> feature (I'm pretty sure PHP's "heredoc" was around
> before C#, for example)

yishai
Offline
Joined: 2003-11-16

> First of all, I am not trolling. This is the
> attitude that will get you nowhere. Read my original
> statement carefully before you speak. I am not
> talking about PHP, or what language is here first or
> what comes after or whatever library. I am saying
> that C# is a superior programming language compare to
> Java.

Because you can quote strings without escape characters? That doesn't define the superiority of any language.

First, any superiority of a language has to be defined in the context of what you are trying to accomplish. If you are trying to write the equivalent of a 10 line bash script, Java won't do it for you, won't do it well, and won't be worth your while. Neither will c#

So lets define some context for which you think C# is more appropriate.

tuthach
Offline
Joined: 2004-09-17

It is one of the things that makes C# better. I am not saying that it is THE thing that makes C# better. Look at the way C# handles properties, it's much more elegant than getter/setter that Java has to offer (OK, I know Java is working to include properties in the next release). Another one: the way I can declare methods as virtual instead of having everything as virtual.

patrikbeno
Offline
Joined: 2004-10-11

> Look at the way C# handles properties, it's much
> h more elegant than getter/setter that Java has to
> offer (OK, I know Java is working to include
> properties in the next release).

??? do they work on it? how do you know? it would be great!

> Another one: the
> way I can declare methods as virtual instead of
> having everything as virtual.

why do you need this? it much better as it is in Java.

tuthach
Offline
Joined: 2004-09-17

I have heard rumors that they are working on it, but knowing Sun, good luck. I responded to another post about this before (http://forums.java.net/jive/thread.jspa?forumID=23&threadID=87&messageID...). Nothing against them, but from time to time, whatever Sun tries to copy Microsoft, it is always worse. Don't believe me? Look at JSF vs ASP.NET, JavaServer Faces is crap and that's TWO YEARS after ASP.NET debut.

There are pros and cons to having everything as virtual. Performance is a prime reason. It also makes it easier to see what methods are intended to be overridden. Of course, the con is that sub classes might be limited to what is allowed.

subanark
Offline
Joined: 2004-11-26

If there are pros and cons to stuff being virtual, then why not some way of indicating a default value
e.g.

@AutoVirtual(true)
@DefaultAccess(public)
class Test
{
static void main(String[] args)
{
//blah, blah
}
}

jwenting
Offline
Joined: 2003-12-02

This is basically what in Python is achieved by using """ (3 quotes) to start a string instead of " (1 quote).

Could come in handy once in a while but I'm basically opposed to extending Java any further (in fact IMO the language should be seriously trimmed).

patrikbeno
Offline
Joined: 2004-10-11

It sounds like a good idea to disable escaping for special use cases. And regular expressions are great one. But if you get rid of escaping (backslashes, primarily) yet still need to double all your quotes (which is escaping, too), there's not too much benefit in this.

Further, I feel that if you need multiline complex literal similar to your SQL, you should place such literals in extra resource that is optimized for such purpose (XML, SQL, whatever) and load the literal from the resource. It is not good idea at all to have it all in Java source.

Good idea would be to have escape character configurable per literal, so that neither backslash nor quote would need to be escaped.
Anyway, inventing a reasonable syntax is a hard task.
I don't find C# one that good.

For multiline verbatim literals, you either cannot use source indentation or end up with improperly formatted literal anyway:

[code]
void test() {
System.out.printn("some code");
String sql = @"
select *
from tableA
where id = 123
"
System.out.println(sql);
}
[/code]

fuerte
Offline
Joined: 2004-11-22

I suggested having @" in the beginning and "@ in the end, so that quotation marks do not need to be escaped.

Also other character codes could be considered. How about ASCII 96: `

It is not as easy to write on Finnish keyboard, requires Shift pressing, but it is standard and rarely used, so it would not interfere with normal strings.

I agree that it would be nice if the whole multi-line string could be inteded according to the code before it, but then we would need to have some character in the beginning of each line, and it would spoil the verbatim string. Python uses """ for multi-line strings and it works very well.