Arrays in java

[mmc.java]

I am just starting to learn java and wanted to know when creating an array if there is any reason why you choose one of the following over the others or if it is just a styling choice by the developer

int productIDs[] = {10,20,30};
int []productIDs = {10,20,30};
int[] productIDs = {10,20,30};

I did notice the the following will cause a compilation error
[]int productIDs = {10,20,30}; //causes an error

 

[Eric Sosman]

I am just starting to learn java and wanted to know when creating an array if there is any reason why you choose one of the following over the others or if it is just a styling choice by the developer

int productIDs[] = {10,20,30};
int []productIDs = {10,20,30};
int[] productIDs = {10,20,30};

All are equivalent. The first suggests the code was written by
an immigrant from C or C++, the last is the style usually seen in
Java, and the middle is just plain ugly.

I did notice the the following will cause a compilation error
[]int productIDs = {10,20,30}; //causes an error

So will

int productIDs = []{10,20,30};
int productIDs = {10,20,30}[];
int productIDs = {[10,20,30]};
productIDs int[] = {10,20,30};

.... and a lot of other random stuff, too.

 

[markspace]

I am just starting to learn java and wanted to know when creating an
array if there is any reason why you choose one of the following over
the others or if it is just a styling choice by the developer

It's "style choice" but there a convention too, most of the code I've
seen uses the style below. For readability, I'd recommend it.
(Readability = it's what everyone is used to seeing.)

int[] productIDs = {10,20,30};

 

[Joshua Cranmer]

I am just starting to learn java and wanted to know when creating an
array if there is any reason why you choose one of the following over
the others or if it is just a styling choice by the developer

int productIDs[] = {10,20,30};

This one, I suspect, is a holdover from C/C++, where the array specifier
has to come after the variable name. I'd recommend not using it, since
it makes it less clear that 'int[]' is the type.

int []productIDs = {10,20,30};
int[] productIDs = {10,20,30};

These two are effectively equivalent, differing only in whether you
think "int []" or "int[]" is a more natural way to specify the type. I
tend towards the latter, since "[]" is bound to the int type and not to
the name of productIDs.

 

[Roedy Green]

int[] productIDs = {10,20,30};

the [] are part of the type so I like to keep them together. The
other style was to make Java look more like C.

see http://mindprod.com/jgloss/array.html
for things a newbie needs to know about arrays.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Why do so many operating systems refuse to define a standard
temporary file marking mechanism? It could be a reserved lead character
such as the ~ or a reserved extension such as .tmp.
It could be a file attribute bit. Because they refuse, there is no
fool-proof way to scan a disk for orphaned temporary files and delete them.
Further, you can't tell where the orhaned files ame from.
This means the hard disks gradually fill up with garbage.

 

[Lew]

I am just starting to learn java [sic] and wanted to know when creating an
array if there is any reason why you choose one of the following over
the others or if it is just a styling choice by the developer

The brackets with the type is the more sensible style.

Putting brackets on the variable splits the type information between the
beginning and the end of the declaration. It's more sensible to keep
all the type part of the declaration together.

It's "style choice" but there a convention too, most of the code I've
seen uses the style below. For readability, I'd recommend it.
(Readability = it's what everyone is used to seeing.)

int[] productIDs = {10,20,30};

It's also logic.

The array dimensions are part of the type. So the type of 'productIDs'
in your example is 'int[]'. Splitting that into 'int productIDs[]' is both
less logical and less readable.

Regardless of your style choice (i.e., the right style or the wrong one)
the code conventions require that you not mix types on one line of
declaration. This is moot of you follow the other convention to
declare only one variable per line.

<http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141270.html#2992>

Note also that the return type of a method must use the 'int[]' form,
so varying that for variables makes even less sense.

 

[Daniel Pitts]

On 7/9/2012 10:54 AM, mmc.java wrote: ...

I did notice the the following will cause a compilation error
[]int productIDs = {10,20,30}; //causes an error

So will

int productIDs = []{10,20,30};
int productIDs = {10,20,30}[];
int productIDs = {[10,20,30]};
productIDs int[] = {10,20,30};

... and a lot of other random stuff, too.

I think the OP may be trying to find out why one totally illogical
placement of the "[]" works, although another, slightly less illogical,
placement does not. At least "[]int" keeps all the type information
together.

The answer, already given, is to allow C and C++ programmers to use a
familiar order.

Patricia

Here is one that'll blow your mind:

int[] arr[] = {{},{1},{2,3},{4,5,6}};

I'm guessing you could even do "int[] []arr[]"

 

[Lew]

Here is one that'll blow your mind:

int[] arr[] = {{},{1},{2,3},{4,5,6}};

I'm guessing you could even do 'int[] []arr[]';

Yes, but the JLS strongly discourages that.

“Brackets are allowed in declarators as a nod to the tradition of C and C++. The general rules for variable declaration, however, permit brackets toappear on both the type and in declarators, so that the local variable declaration:

“ float[][] f[][], g[][][], h[]; // Yechh!

“We do not recommend "mixed notation" in an array variable declaration, where brackets appear on both the type and in declarators.”

<http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html#jls-10.2>

Know. Don't guess. Read the JLS.

Chant 12 times until it's ingrained in your subconscious.

 

[Daniel Pitts]

Here is one that'll blow your mind:

int[] arr[] = {{},{1},{2,3},{4,5,6}};

I'm guessing you could even do 'int[] []arr[]';

Yes, but the JLS strongly discourages that.

“Brackets are allowed in declarators as a nod to the tradition of C and C++. The general rules for variable declaration, however, permit brackets to appear on both the type and in declarators, so that the local variable declaration:

“ float[][] f[][], g[][][], h[]; // Yechh!

“We do not recommend "mixed notation" in an array variable declaration, where brackets appear on both the type and in declarators.”

<http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html#jls-10.2>

Know. Don't guess. Read the JLS.

If it was something I cared to know, I would have. I know that even if
it was valid, I would never use it. If I ever encountered it, I would
look up the rules on how exactly it works.

I was mostly just being goofy with examples of what can be done, even if
it should be avoided.

 

[Lew]

Here is one that'll blow your mind:

int[] arr[] = {{},{1},{2,3},{4,5,6}};

I'm guessing you could even do 'int[] []arr[]';

Yes, but the JLS strongly discourages that.

“Brackets are allowed in declarators as a nod to the tradition of C and C++.
The general rules for variable declaration, however, permit brackets to
appear on both the type and in declarators, so that the local variable
declaration:

“ float[][] f[][], g[][][], h[]; // Yechh!

“We do not recommend "mixed notation" in an array variable declaration,
where brackets appear on both the type and in declarators.â€

<http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html#jls-10.2>

Know. Don't guess. Read the JLS.

If it was something I cared to know, I would have. I know that even if it was
valid, I would never use it. If I ever encountered it, I would look up the
rules on how exactly it works.

I was mostly just being goofy with examples of what can be done, even if it
should be avoided.

Sorry, I should have made it clear that I was speaking of general principle
for the wider audience. If anything I should have emphasized the validity of
your observation.

But lately in particular, and for a long time in general, I have seen a
tendency for programmers to assume or guess or infer or imagine technical
information that is readily and authoritatively available. The Internet
removes much of the excuse for uncertainty, pretty much all of it when it
comes to Java. Especially things that are baldly and rather aggressively
stated in the single most seminal and normative Java specification there is,
the Java specification itself.

I found the under-five minutes to confirm this particular nugget, via a link
that had been posted in this very thread multiple times already by Roedy and
others, to be a negligible burden to incur prior to averring the validity of
your observation.

 

[Roedy Green]

Know. Don't guess. Read the JLS.

And I have explained to you many times that not everyone can make hide
nor tail of that lawyerly document. YOU can, but perhaps only one in
100 programmers can accurately decode it. It is plain rude to demand
newbies use it. Encourage them yes, but don't pretend it as a skill
everyone is suppose to master to justify their existence. You are
using it like some frat hazing.

I further hazard a guess your own ability to decode is somewhat higher
than it is in reality. You just assert your interpretation is the
correct one. Any time I read that fool think I can come up with 4
possible interpretations. . The fault it is the document. It was not
written for average programmers but to settle lawyerly disputes over
compiler compliance. That is why they are so many text books to
explain these things in English to programmers.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Mathematicians and computer scientists are far more interested
in impressing you than informing you. If this were not
so, the tutorials on building a robots.txt file, for example,
would consist primarily of an annotated example. What you get
instead are nothing but inscrutable adstract fragments in some
obscure dialect of BNF.

 

[Lew]

Lew wrote, quoted or indirectly quoted someone who said :
&gt;Know. Don't guess. Read the JLS.

And I have explained to you many times that not everyone can make hide
nor tail of that lawyerly document. YOU can, but perhaps only one in
100 programmers can accurately decode it. It is plain rude to demand
newbies use it. Encourage them yes, but don't pretend it as a skill

It is plain stupid and evil of you to recommend that newbies not use it.

It is the seminal authoritative document that defines Java.

Your rabid insistence that people ignore it is a huge disservice to those
learning the language.

everyone is suppose to master to justify their existence. You are
using it like some frat hazing.

Which is the better advice in computer programming, to study toward
an understanding in depth the core definition of the language, or
to avoid studying the definition of the language?

What is your problem that gets you foaming at the mouth for the
mere suggestion that the JLS is the core and pinnacle of knowledge
about the definition of the language? Your attitude is as inexplicable
as it is hostile and damaging to those seeking better knowledge.

I further hazard a guess your own ability to decode is somewhat higher
than it is in reality. You just assert your interpretation is the
correct one. Any time I read that fool think I can come up with 4

Show me where I'm wrong. I'm open to learning new things.

Are you?

Why are you so adamant that others recapitulate your shortcomings?

possible interpretations. . The fault it is the document. It was not
written for average programmers but to settle lawyerly disputes over
compiler compliance. That is why they are so many text books to
explain these things in English to programmers.

What exactly do you find unclear about

“Brackets are allowed in declarators as a nod to the tradition of C and C++. The general rules for variable declaration, however, permit brackets toappear on both the type and in declarators, so that the local variable declaration:

“ float[][] f[][], g[][][], h[]; // Yechh!

“We do not recommend "mixed notation" in an array variable declaration, where brackets appear on both the type and in declarators.”

<http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html#jls-10.2>

I would be glad to help you with it.

 

[Gene Wirchenko]

It is plain stupid and evil of you to recommend that newbies not use it.

Why? It probably is not intelligible by them.

It is the seminal authoritative document that defines Java.
Sure.

Your rabid insistence that people ignore it is a huge disservice to those
learning the language.

He is not doing that.

Which is the better advice in computer programming, to study toward
an understanding in depth the core definition of the language, or
to avoid studying the definition of the language?

How about not excluding the middle? I read the spec for
JavaScript and had to give it up partway because so much of it was
just not worth the trouble. Some of it, yes, but other parts were not
very clear for someone studying for use. I expect the JLS has the
same trouble. Most language specs are not written for app programmers
but rather language implementers.

What is your problem that gets you foaming at the mouth for the
mere suggestion that the JLS is the core and pinnacle of knowledge
about the definition of the language? Your attitude is as inexplicable
as it is hostile and damaging to those seeking better knowledge.

If you are looking for hostility, consider your own.

Show me where I'm wrong. I'm open to learning new things.

Are you?

Why are you so adamant that others recapitulate your shortcomings?

I think he is trying to avoid them hitting a wall.

possible interpretations. . The fault it is the document. It was not
written for average programmers but to settle lawyerly disputes over
compiler compliance. That is why they are so many text books to
explain these things in English to programmers.

What exactly do you find unclear about

“Brackets are allowed in declarators as a nod to the tradition of C and C++. The general rules for variable declaration, however, permit brackets to appear on both the type and in declarators, so that the local variable declaration:

“ float[][] f[][], g[][][], h[]; // Yechh!

“We do not recommend "mixed notation" in an array variable declaration, where brackets appear on both the type and in declarators.”

<http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html#jls-10.2>

I would be glad to help you with it.

That an individual example is clear does not prove that the whole
is clear. Even if all examples are clear, it does not mean that the
whole coheres.

Sincerely,

Gene Wirchenko

 

[Lew]

Lew wrote:
&gt;What exactly do you find unclear about
&gt;
&gt;“Brackets are allowed in declarators as a nod to the tradition of Cand C++. The general rules for variable declaration, however, permit brackets to appear on both the type and in declarators, so that the local variable declaration:
&gt;
&gt;“ float[][] f[][], g[][][], h[]; // Yechh!
&gt;
&gt;“We do not recommend &quot;mixed notation&quot; in an array variable declaration, where brackets appear on both the type and in declarators.”
&gt;
&gt;&lt;http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html#jls-10.2&gt;
&gt;
&gt;I would be glad to help you with it.

That an individual example is clear does not prove that the whole
is clear. Even if all examples are clear, it does not mean that the
whole coheres.

It is the individual example that sparked Roedy's diatribe. Ergo
I concluded it must have posed him some difficulties for him to
gripe about it.

Regardless, Roedy has expressed difficulty with the JLS and I am
happy to help him wherever that difficulty lies.

I am astounded that you join him in apologetics for ignorance.

Programming is a game of knowledge and mastery. If you deliberately
exclude the normative documentation for the platform you use,
you are hurting yourself. If you recommend that others do so as well,
you are hurting them.

I extend you the same offer I did to Roedy, Gene. I'd be glad to help
you with anything in the JLS you find obscure.

What really puzzles me is Roedy's apparent anger at me for recommending
the JLS. What the F? Spend the freaking time reading and understanding it,
reaching for auxiliary sources (such as those by the JLS's own authors) for
the parts that puzzle you. Study it. I've been studying the various
incarnations for over a decade. There's no magic, despite how hard Roedy
tries to enmystify the process. It's just determination and diligence, and
I dare say a modicum of raw talent for programming that many who
frequent this forum can lay claim to.

Don't be an advocate for laziness and ignorance.

Know. Don't guess. Read the JLS.

Excoriate anyone who tries to discourage you from doing so.

 

[Daniel Pitts]

And I have explained to you many times that not everyone can make hide
nor tail of that lawyerly document. YOU can, but perhaps only one in
100 programmers can accurately decode it. It is plain rude to demand
newbies use it. Encourage them yes, but don't pretend it as a skill
everyone is suppose to master to justify their existence. You are
using it like some frat hazing.

I resent being called a newbie I'll admit that I was being lazy (due
to pain, low blood sugar, and sleep deprivation), and should have looked
up, or at least tested, the assertion that I wrote "I guess" to instead.

 

[Gene Wirchenko]

Lew wrote:
&gt;What exactly do you find unclear about
&gt;
&gt;“Brackets are allowed in declarators as a nod to the tradition of C and C++. The general rules for variable declaration, however, permit brackets to appear on both the type and in declarators, so that the local variable declaration:
&gt;
&gt;“ float[][] f[][], g[][][], h[]; // Yechh!
&gt;
&gt;“We do not recommend &quot;mixed notation&quot; in an array variable declaration, where brackets appear on both the type and in declarators.”
&gt;
&gt;&lt;http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html#jls-10.2&gt;
&gt;
&gt;I would be glad to help you with it.

That an individual example is clear does not prove that the whole
is clear. Even if all examples are clear, it does not mean that the
whole coheres.

It is the individual example that sparked Roedy's diatribe. Ergo
I concluded it must have posed him some difficulties for him to
gripe about it.

Regardless, Roedy has expressed difficulty with the JLS and I am
happy to help him wherever that difficulty lies.

I am astounded that you join him in apologetics for ignorance.

I do no such thing.

Programming is a game of knowledge and mastery. If you deliberately
exclude the normative documentation for the platform you use,
you are hurting yourself. If you recommend that others do so as well,
you are hurting them.

I do not. I do suggest that it is not an appropriate document
for a newbie.

I extend you the same offer I did to Roedy, Gene. I'd be glad to help
you with anything in the JLS you find obscure.

What really puzzles me is Roedy's apparent anger at me for recommending
the JLS. What the F? Spend the freaking time reading and understanding it,
reaching for auxiliary sources (such as those by the JLS's own authors) for
the parts that puzzle you. Study it. I've been studying the various
incarnations for over a decade. There's no magic, despite how hard Roedy
tries to enmystify the process. It's just determination and diligence, and
I dare say a modicum of raw talent for programming that many who
frequent this forum can lay claim to.

Don't be an advocate for laziness and ignorance.

Know. Don't guess. Read the JLS.

Excoriate anyone who tries to discourage you from doing so.

I have not read the JLS, but as I noted in my post, I did read
much of the JavaScript standard. There were parts of it that were
very lucid indeed. I expect that the JLS has lucid portions, too.
However, there were parts of the JavaScript standard that were very
obtuse. Were I interested in implementing a JavaScript processor,
they would probably be just about what I needed, but for app
programmer level, no, very unclear. I expect that the same is true
for the JLS.

Langauge standards and language documentation for programmers are
two different things with some overlap. I would not wish the standard
for any language on a newbie to the language. After he has the
basics, yes, it would be appropriate then.

Sincerely,

Gene Wirchenko

 

[Lew]

Gene Wirchenko wrote:
....

I have not read the JLS, but ...

 

[Gene Wirchenko]

Gene Wirchenko wrote:
...

Ad hommuch?

Patricia Shanahan states that she has read the JLS several times
and that she agrees with me. What cheap shot are you going to use
against her?

Language standards have uses, but one of them is not learning the
language from the start.

Sincerely,

Gene Wirchenko

 

[Lew]

Lew wrote:
&gt;Gene Wirchenko wrote:
&gt;...
&gt;&gt; I have not read the JLS, but ...

Ad hommuch?

Patricia Shanahan states that she has read the JLS several times
and that she agrees with me. What cheap shot are you going to use
against her?

Language standards have uses, but one of them is not learning the
language from the start.

I don't advocate reading the JLS in order to learn the language from the
start. If you think that's what I'm saying, read it again.

I am advocating not ignoring the JLS, and using it as a reference and an
adjunct to learning the language, so that by the time you consider
yourself competent in Java there is a reality to that assessment.

Let me repeat this to avoid misunderstanding:

I do not advocate using the JLS (by itself) to learn Java.

I advocate using the JLS to know what is really real about Java

I excoriate the advice to avoid the JLS. I didn't hear Patricia say
not to study the JLS. I did hear others say that.

It is not an ad hominem attack to point out that you are judging
the JLS without having even made the attempt to read it. That is
a legitimate consideration when considering whether your opinion
about the JLS should carry weight. It is nice that you know the
term ad hominem; now you need to apply it correctly.

Patricia actually has read the JLS, so of course that criticism
cannot apply as it does to you, Gene.

I also never said that reading the JLS is easy. I am saying that
it is necessary.

I also claim that actively discouraging people from reading the
JLS, most particularly if you yourself have never made the effort,
is advocacy for laziness and incompetence.

Secondary materials can tell you what they think the JLS means,
but you have to watch your sources. I now know, for example, that
any opinion Gene has about what is or is not so about Java is
suspect, because he has not read it. He depends entirely on
indirect sources. If his sources are the likes of Gilead Bracha,
James Gosling, Brian Goetz and Josh Bloch then he might have
very good knowledge, but I cannot be sure of that. His resistance
to the JLS is a telling point against trusting his advice.

Patricia has demonstrated again and again that she knows
Java better than most people, and that she bases that knowledge
in part on studying the JLS.

So, Gene, here's to your straw-man arguments:

- You refuted the proposition that one should use the JLS to
learn Java. Congratulations. No one said you should.

- You refuted the proposition that the JLS is an easy read.
Congratulations. No one said that it is.

Here are the points not refuted and still standing:

- I claimed that the JLS is an essential tool to learning Java,
along with recommending other useful sources. No one
has even said that it isn't, much less established that it isn't.

- I claimed that it doesn't take special intelligence to
study the JLS, only diligence and continued study. No one
has tested that proposition either.

- I claimed that actively discouraging newbies (or anyone
else) from studying the JLS is a disservice to their learning
and professional progress. No one has addressed this point.

I don't understand why anyone sane or helpful would attempt
to dissuade Java programmers from studying the JLS, or worse
yet, be proud that they themselves have not.

No wonder there are so many poor programmers in the business.

 

[Arun GOPI]

I am just starting to learn java and wanted to know when creating an array if there is any reason why you choose one of the following over the others or if it is just a styling choice by the developer

int productIDs[] = {10,20,30};
int []productIDs = {10,20,30};
int[] productIDs = {10,20,30};

I did notice the the following will cause a compilation error
[]int productIDs = {10,20,30}; //causes an error

By java convention the standard is int[] productIDs = {10,20,30};
the brackets must indicate the data type.The other way is also allowed but discourager.refer : http://docs.oracle.com/javase/tutorial/java/nutsandbolts/arrays.html