who can tell me why

[Chris Uppal]

int i, j;

is any less clear than

int i;
int j;

To me, the second version is actually less clear, because I have to
notice the type for both.

FWIW, I prefer the first form if the several variables /must/ have the same
type, and the second if the two (or more) types are related only by "accident".

-- chris

 

[tom fredriksen]

What nasty stuff are you thinking of?

What does this mean spelled out in single line form?

int[] c, d[], e;

int array C, int array d and int e.

Its only the first one that might be misunderstood, but only the first
time. As soon as you know this, then its no problem anymore. But as I
said in the other post, the first array syntax it is of course less
readable than the second and the third.

/tom

 

[tom fredriksen]

What nasty stuff are you thinking of?

Probably something like this:

<dangerousCode>
String []c = {"1", "2", "3"}, d[];
</dangerousCode>

Here it looks like d is array of String, but actually it's an array of
array of String.

I just realised something, I dont know if its an error in the jvm or not
but have a look at this: ( My jvm version is "1.5.0_04" )

String [][]c = new String[3][3], d[] = new String[3];

StringArray.java:9: incompatible types
found : java.lang.String[][]
required: java.lang.String[][][]
String [][]c = new String[3][3], d[] = new String[3][3];
^

d is compiled as an [][][] array as you say, but if you do this

String c[][] = new String[3][3], d[] = new String[3];

then d is compiled as [] only.

I am used to writing the array designation after the variable, hence my
interpretation.

Basically, just because the [][] is next to the type definition int it
decides that everything on the line is of at least that type, but if its
on the right side of the variable or used on any of the following
variables then its just what is stated, that's a weird and confusing rule.

Is this the correct function of the jvm or is it a bug?

/tom

 

[tom fredriksen]

What nasty stuff are you thinking of?

What does this mean spelled out in single line form?

int[] c, d[], e;

int array C, int array d and int e.

Its only the first one that might be misunderstood, but only the first
time. As soon as you know this, then its no problem anymore. But as I
said in the other post, the first array syntax it is of course less
readable than the second and the third.

Hold on with this one until the other post is examined, either there is
a bug in the jvm or there is duplicate meanings. Just see the see my
post from 12:38 today.

/tom

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

tom fredriksen schreef:

What nasty stuff are you thinking of?

What does this mean spelled out in single line form?

int[] c, d[], e;

int array C, int array d and int e.

Its only the first one that might be misunderstood, but only the first
time. As soon as you know this, then its no problem anymore. But as I
said in the other post, the first array syntax it is of course less
readable than the second and the third.

Well, you more than justified Roedy's point here, in giving the false
answer. Thus you are only contradicting yourself.

int[] c;
int[][] d;
int[] e;

would have been the single line form.

H.
--
Hendrik Maryns

==================
www.lieverleven.be
http://aouw.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEKRLFe+7xMGD3itQRAqwPAJ41CnEZiou0p1n1EZJiFgC5yyS9XwCfWHk9
13xXsHeGirCfZaSlw021qRQ=
=1rYK
-----END PGP SIGNATURE-----

 

[tom fredriksen]

You will mildly irritate others by refusing
to use the more common idiom, the same way you would if you ignored
the caps conventions. It just trips people up to have things
specified a different way than they expect.

You could also use reverse indentation too. That's legal, but will
make people do a double take to understand your code.

You have to differentiate between what make things more readable and
what are just preferences.

Reverse indentation (don't know what it is though, I presume would
make the code a lot less readable and would make maintenance costs sky
rocket.

Where you put your array definition and whether you write { on the same
line or the next is a preference and is just part of life, you are never
going to get every programmer in the world to follow that unless its a
rule in the compiler. Its just one of those things.

/tom

 

[Chris Uppal]

tom fredriksen wrote:

Basically, just because the [][] is next to the type definition int it
decides that everything on the line is of at least that type, but if its
on the right side of the variable or used on any of the following
variables then its just what is stated, that's a weird and confusing rule.

Is this the correct function of the jvm or is it a bug?

That's the correct way for the compiler to work.

If you write

String[][] v1, v2;

then both v1 and v2 are declared to have the type String[][]. This is just
like how if you write:

String v1, v2;

then both v1 and v2 are declared to have the type String. Now if you decorate
the declaration of either variable:

String v1[], v2[][];

then v1 has type String[], and v2 has type String[][].

It has nothing to do with what's "next to" what, but a [] following a type name
qualifies that type, a [] following a variable name qualifies that variable's
type.

If you mix the two, and especially if you declare multiple variables with mixed
qualification, then it gets confusing (for the reader) pretty quickly. That is
a known problem in C; which is why Java has the more sensible syntax where the
typename itself is qualified. For some reason the Java designers didn't leave
out the old-style C-ish (qualify the variable) approach. I don't know why not,
but the universal recommendation (as far as I can see) is that you don't use
it.

-- chris

 

[tom fredriksen]

tom fredriksen wrote:

Basically, just because the [][] is next to the type definition int it
decides that everything on the line is of at least that type, but if its
on the right side of the variable or used on any of the following
variables then its just what is stated, that's a weird and confusing rule.

Is this the correct function of the jvm or is it a bug?

That's the correct way for the compiler to work.

If you write

String[][] v1, v2;

then both v1 and v2 are declared to have the type String[][]. This is just
like how if you write:

String v1, v2;

then both v1 and v2 are declared to have the type String. Now if you decorate
the declaration of either variable:

String v1[], v2[][];

then v1 has type String[], and v2 has type String[][].

It has nothing to do with what's "next to" what, but a [] following a type name
qualifies that type, a [] following a variable name qualifies that variable's
type.

If you mix the two, and especially if you declare multiple variables with mixed
qualification, then it gets confusing (for the reader) pretty quickly. That is
a known problem in C; which is why Java has the more sensible syntax where the
typename itself is qualified. For some reason the Java designers didn't leave
out the old-style C-ish (qualify the variable) approach. I don't know why not,
but the universal recommendation (as far as I can see) is that you don't use
it.

Ok, fair enough. I wasn't aware that it was an issue with arrays, but
now I know. Thanks.

/tom

 

[tom fredriksen]

Where you put your array definition and whether you write { on the same
line or the next is a preference and is just part of life, you are never
going to get every programmer in the world to follow that unless its a
rule in the compiler. Its just one of those things.

After realising that there are issues with arrays syntax, I agree. But
for other similar issues where there are no semantic difference, I still
hold the opinion that its just a preference.

/tom

 

[Monique Y. Mudama]

FWIW, I prefer the first form if the several variables /must/ have the same
type, and the second if the two (or more) types are related only by "accident".

Actually, yeah, I like to group related variables together. For
example, I am using static Strings in a few places to act as entries
in a drop-down of some sort ... I would typically declare each
drop-down's set of entries on a separate line.

 

[Patricia Shanahan]

tom fredriksen wrote:
....

Basically, just because the [][] is next to the type definition int it
decides that everything on the line is of at least that type, but if its
on the right side of the variable or used on any of the following
variables then its just what is stated, that's a weird and confusing rule.

Is this the correct function of the jvm or is it a bug?

/tom

Another USENET group, to which I used to contribute, had a group virtual
soapbox that one could call for when needed. I need the
comp.lang.java.programmer soapbox. Here, Soapy!

[Patricia climbs on the soapbox]

The first part of the rule, that the type of the variables in the
declaration is the one specified immediately before the first
identifier, is a simple, clean rule and in my opinion should have been
the ONLY way of declaring the type of a variable.

The second part, the ability to add array dimensions for a single
identifier by adding one or more "[]" pairs immediately after it, can
destroy that simple, clean picture, but only if you use it.

I consider the ability to scatter type information among the list of
variable identifiers in a single declaration to be a bug in the JLS,
and very unfortunate. If multiple variables are to be declared in a
single declaration, shouldn't they all have the same type?

It is not a bug in the JVM, because it has follow the JLS.

It had some point in C, because of the ability to declare a struct
without naming the type:

struct{
/* a bunch of field declarations */
} a, b[3], c;

In Java, each type has a name modified by at most a few "[]" pairs. As
far as I can tell, the ability to add array dimensions for a single
identifier is in there for the sake of superficial, but potentially
confusing, familiarity for C programmers. It apparently even managed to
confuse Tom, by making him think Java declarations are more similar to
C declarations than is actually the case.

I don't think C declaration syntax should be emulated by other languages
as a high point of programming language design. There is even a widely
distributed program, cdecl, for encoding and decoding C declarations,
the ultimate condemnation of their usability. See
http://linuxcommand.org/man_pages/cdecl1.html.

[Patricia gets off the soapbox, thanks it, and sends it on its way.]

Patricia

 

[Dimitri Maziuk]

Patricia Shanahan sez:
.... array decl ...

It had some point in C, because of the ability to declare a struct
without naming the type:

struct{
/* a bunch of field declarations */
} a, b[3], c;

NitPick: it had a point in C because C doesn't really have arrays,
it has contiguous storage for n elements of a given type. What
int a, b[3];
says is "allocate space for one int on stack and call it 'a',
allocate 3*sizeof(int) space on stack and call it 'b'".

Which is obviously not what happens in Java.

Dima (and I wish they dropped the "everything is a function" idea too)

 

[Roedy Green]

Is this the correct function of the jvm or is it a bug?

it is a gotcha, the reason I recommend people stay away from multiple
declarations per line. It leads to code that people will misread.

 

[Roedy Green]

Reverse indentation (don't know what it is though, I presume would
make the code a lot less readable and would make maintenance costs sky
rocket.

It is just nutty I idea I made up to poke fun at the idea it is ok to
code in any way that is legal.. Instead of writing:

void myMethod ( int parm )
{
for ( int i=0; i<n; i++)
{
sum+= a;
}
}

you would code:

void myMethod ( int parm )
{
for ( int i=0; i<n; i++)
{
sum+= a;
}
}

 

[Roedy Green]

Where you put your array definition and whether you write { on the same
line or the next is a preference and is just part of life, you are never
going to get every programmer in the world to follow that unless its a
rule in the compiler. Its just one of those things.

I take it, Tom, that you have never worked on a team. In order to
avoid false deltas, usually a team will have EXTREMELY tight coding
conventions, much stricter than the ones Sun suggests. See
http://mindprod.com/jgloss/codingconventions.html

If you don't follow them, you will soon find yourself on the street.

Programming is as much a human-to-human communication enterprise as a
human-to-computer. The conventions also make it easier to see
standard idioms at a glance.

Have a look at Eclipse or IntelliJ. They goes on for pages and pages
defining in minute detail how to format your code. In a team,
everyone uses the same template.

Even if you work solely on your own, you will find you can comprehend
your own code more easily the more consistent you are.

 

[Roedy Green]

After realising that there are issues with arrays syntax, I agree. But
for other similar issues where there are no semantic difference, I still
hold the opinion that its just a preference.

That is illogical. If others disagree with you, then obviously it does
matter even if just to reduce friction. You could only justify your
stance in a vacuum. As soon as you show your code to others, you have
a potential to get their backs up with eccentricities. You then get
into a cost benefit situation. Is the benefit of doing things an
eccentric way worth the hassles when dealing with others.

Usually there are good reasons why the world settles on a consensus,
for example the use of int[] x rather than int x[]. If you pick
conventions just to be different or arbitrarily, you will usually be
missing out on some benefit.

It seems odd to aim to write code as hackneyed as possible, full of as
many trite idioms as possible, but that is what is easiest to
maintain.

 

[Tom Fredriksen]

After realising that there are issues with arrays syntax, I agree. But
for other similar issues where there are no semantic difference, I still
hold the opinion that its just a preference.

That is illogical. If others disagree with you, then obviously it does
matter even if just to reduce friction. You could only justify your
stance in a vacuum. As soon as you show your code to others, you have
a potential to get their backs up with eccentricities. You then get
into a cost benefit situation. Is the benefit of doing things an
eccentric way worth the hassles when dealing with others.

Usually there are good reasons why the world settles on a consensus,
for example the use of int[] x rather than int x[]. If you pick
conventions just to be different or arbitrarily, you will usually be
missing out on some benefit.

It seems odd to aim to write code as hackneyed as possible, full of as
many trite idioms as possible, but that is what is easiest to
maintain.

I take it, Tom, that you have never worked on a team. In order to
avoid false deltas, usually a team will have EXTREMELY tight coding
conventions, much stricter than the ones Sun suggests. See
http://mindprod.com/jgloss/codingconventions.html

If you don't follow them, you will soon find yourself on the street.

Now you are just being silly, is this is how far the discussion has
gone, that you have no more constructive arguments and feel you need to
resort to the "descrediting game"?

I have no problem with your point of view or that you express or
discussing the postives and the negatives of it, but please refrain from
trying to impress on me or others your view. Thats not really very
becoming, of anybody.

I recently had a similar discussion with a consultant working with me at
my workplace. He was trying to set a rule that import should be written
with the class name, not with *. Do you know what his reason was? He
claimed it was faster, implying that it was so for the compiler and the
runtime. Now we all know that it is not so, and I corrected him on that.
Do you know what his motivation was? He had this problem that he is a
Sun Java Champion and he is a chief consultant at his company, so in his
mind he needs to be right, ALL THE TIME, sounds familiar? What he did
not say, which he could have, was that since he uses intellij its
automagic and therefore mixing such statements makes the code look ugly
or something Instead he chose to try to force his will on the rest of
the team. It ended up with with me having to tell him where the line is
in the team.

If these things are such issues, it would have been included in any
langauge spec. Its really a non-issue, which most people dont care about
anymore, they want to spend their time where it matters. I am not saying
readability and maintainability are not important, I am saying some
issues are just to tiny to bother with.

You must realise that the world IS a messy place, you can't go around
with a belief that people are this or that just because they don't
follow your rules. Take any given human language, 99% of all native
speakers make grammatical mistakes while speaking or writing. Do you see
many people care about that, no. What you see, once in a while, is some
language professor going crazy about it in some newspaper under the
section readers comments and calling for the entire nation to stop until
it's fixed. That's the way it is with anything in the world, some things
are minor issue, and people can't be bothered to spend any energy on it.

Most projects I have worked on there has been some rules, but they have
little to do with pretty syntax, but rather with semantics and avoiding
bugs. F.ex at my workplace we are making embedded voip software and one
of the rules we have is:

instead of writing

if(some_var==SOME_MAGIC_NUMBER)
do something

we write

if(SOME_MAGIC_NUMBER==some_var)
do something

(with SOME_MAGIC_NUMBER being a C define), do you see why one would
write it like this?

It has to do with reducing the number of bugs in the software, that's
the kind of things they care about. The consensus in projects I have
worked on is that as long as its readable, semantically the same and
reasonably similar you can do what you want. Most people I have met
don't care about the old syntax pissing contest any more.

So, if you could stop trying to force your will on others that would be
nice, if not, it shows lack of basic human respect on your part. I have
no problem with your opinion on the matter, its your perogative and you
can do what you want. But stop the "I am the senior here, you SHOULD do
what I want" game. If you dont have a decent and constructive argument,
then you should not particiapte in the discussion. I will do my best as
well, I know I have much to learn about java and thats where I want to
focus my energy. Agreed?

Have a look at Eclipse or IntelliJ. They goes on for pages and pages
defining in minute detail how to format your code. In a team,
everyone uses the same template.

Eclipse and intellij are for beginning programmers, I write all my code
in emacs or was it vi? hmm... never mind

/tom

 

[Gordon Beaton]

I take it, Tom, that you have never worked on a team. In order to
avoid false deltas, usually a team will have EXTREMELY tight coding
conventions, much stricter than the ones Sun suggests.

Although I have worked on several teams, I have never encountered
these "EXTREMELY tight coding conventions" of which you speak, just
local recommendations that may or may not vary among code shops.

The programmers I've worked with have sufficient sense to refrain from
reformatting every piece of code they touch, so the idea that lack of
strict rules must necessarily result in a chaos of false diffs is
ridiculous.

/gordon

 

[Oliver Wong]

Usually there are good reasons why the world settles on a consensus,
for example the use of int[] x rather than int x[]. If you pick
conventions just to be different or arbitrarily, you will usually be
missing out on some benefit.

This argument assumes that it's clear to the OP that there is a
consensus, and that the OP is willfully choosing to be contrary; perhaps in
the OP's experience, both styles of declaration are equally common, thus
explaining why the OP came to the conclusion that it was just a matter of
preference.

- Oliver

 

[Oliver Wong]

I recently had a similar discussion with a consultant working with me at
my workplace. He was trying to set a rule that import should be written
with the class name, not with *. Do you know what his reason was? He
claimed it was faster, implying that it was so for the compiler and the
runtime. Now we all know that it is not so, and I corrected him on that.
Do you know what his motivation was? He had this problem that he is a Sun
Java Champion and he is a chief consultant at his company, so in his mind
he needs to be right, ALL THE TIME, sounds familiar? What he did not say,
which he could have, was that since he uses intellij its automagic and
therefore mixing such statements makes the code look ugly or something
Instead he chose to try to force his will on the rest of the team. It
ended up with with me having to tell him where the line is in the team.

The consultant gave a "bad reason", but there IS a point to using full
class names instead of ".*" in import statements: to avoid name conflicts.

- Oliver