• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Junilu Lacar
  • Martin Vashko
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Scott Selikoff
  • salvin francis
  • Piet Souris

Using methods with arrays

 
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Friends,

yet another question which is super basic but I don't understand the answer.

My method below should start the game:



But I don't know how I can use the method in my main class to create the two dimensional array?
How do I need to write the code so my methods creates the array?
 
Marshal
Posts: 14530
242
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That code already does that. Line 4 creates the array and the subsequent lines fill it up. The only thing that's missing is for you to return the array you created. Right now, the method is declared as void. Also, it receives an array as an argument but line 4 immediately overwrites that reference with a new array.

That code is basically doing this:
- (parameter) - Give me an array playerCards
- Line 4 - ok, I'm going to throw away that array you just gave me and create an entirely new one
- Rest of the method - I'll fill the new array with a bunch of cards.
- (exit the method) - And I'll throw away the array that I just filled with cards.

Instead, you want to do this:
- (no parameter) - you just want to create a new array
- Line 4 - ok, I'll create a new array
- Rest of the method - I'll fill the array with cards
- Exit the method by returning the array I just created and filled up.

Do you think you can translate that into Java?
 
Michael Grünau
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you very much for the detailed help.

Just one more question, how can I return my array for the Main class?
I can't write return playerCards; or something similar...
 
Junilu Lacar
Marshal
Posts: 14530
242
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Michael Grünau wrote:Thank you very much for the detailed help.

Just one more question, how can I return my array for the Main class?
I can't write return playerCards; or something similar...



Why not? Right now you've declared the method as having a void return type, i.e. it returns nothing. If you're going to return an array, you have to declare in the method header that you're returning an array.
 
Junilu Lacar
Marshal
Posts: 14530
242
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Programming is a precision sport. You have to say what you're doing and do what you're saying.

If you declare that your method doesn't return anything, you can't put a return something; statement in your method. You can simply fall out of the method by running out of statements or simply return; without an argument.

Conversely, if you declare that your method returns something, then you have to exit out of the method with a return something; statement where "something" is actually the type that you declared you'd return. You can't declare you're going to return one type of thing and then have a return statement that returns some other type of thing. For example, you can't declare your method returns an int and then have a return someString; statement. You can't fool the compiler. It expects the method body to live up to the promise made in the method declaration and it will complain loudly if that isn't the case.
 
Michael Grünau
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry still no idea....



What am I doing wrong?
 
Junilu Lacar
Marshal
Posts: 14530
242
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Read my description again.

In the method header, you're still saying "I expect to be given an int[][]" -- that's not what you want to do!

Instead, inside the method, declare that you're creating an int[][] - (a local variable)
 
Michael Grünau
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Holy shit, I think I got it...



And in main i can just

int [] [] playerCards = givePlayerCards();
 
Junilu Lacar
Marshal
Posts: 14530
242
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, but don't put too many spaces. Write this instead:

And choose names that are expressive enough without being too verbose. If a shorter name expresses the idea just as well, prefer the shorter name.
 
Marshal
Posts: 7323
497
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:If a shorter name expresses the idea just as well, prefer the shorter name.


Does this apply to abbreviations? I personally not a fan of them, but in quite a few cases I can understand what they mean. Do you prefer shorten the names by abbreviating them?
 
Junilu Lacar
Marshal
Posts: 14530
242
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Liutauras Vilda wrote:

Junilu Lacar wrote:If a shorter name expresses the idea just as well, prefer the shorter name.


Does this apply to abbreviations? I personally not a fan of them, but in quite a few cases I can understand what they mean. Do you prefer shorten the names by abbreviating them?


The key phrase is "expresses the idea just as well."  Abbreviations tend to be well-known to those who have been using them for a while or if it's a widely-used and widely-known abbreviation. In those cases, it's probably fine. For example, cd vs. compactDisc or atm vs. automatedTellerMachine. If there's enough context, then a more domain-specific abbreviation might be fine, like bmi vs. bodyMassIndex.

It's all about context though. As long as there's enough to reasonably inform whoever comes into the code without prior knowledge or experience what the abbreviation means, then I'd say abbreviations are fine. I wouldn't go overboard though.

Speaking of context, the advice I gave to prefer shorter names was in the context of what OP did: getPlayerCards() is a bit verbose. Also, why do we have to qualify "cards" with "player" -- that name implicitly links the ideas of a collection of cards and the players who are going to use them. I'm not sure the link is really necessary here, at least not in this area of the program. The name getCards() conveys the intent well enough without unnecessarily complicating the idea by injecting the concept of a related player or players in it. That idea might be better expressed elsewhere in the code. But then again, if it's important to emphasize that the cards you're getting from this method has a strong link to the players using them then maybe the longer getPlayerCards() is in fact more appropriate.

Decisions like this are actually quite nuanced so it's good to ask these kind of questions and experiment with different alternatives. My main guidelines are whether or not the code clearly expresses intent and whether or not I'm creating duplication. Other considerations usually fall out of discussions around these two basic design guidelines.
 
Liutauras Vilda
Marshal
Posts: 7323
497
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:It's all about context though. As long as there's enough to reasonably inform whoever comes into the code without prior knowledge or experience what the abbreviation means, then I'd say abbreviations are fine. I wouldn't go overboard though.



Thankful for the thorough answer. That drew for me a clearer line comparing to what I had in my mind.
 
Junilu Lacar
Marshal
Posts: 14530
242
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Glad I could help clear things up. I actually wanted to add a little more about "don't go overboard" with abbreviations. What I'm specifically thinking about when I say that are the kind of abbreviations that make code more difficult to read, like usr vs. user or chkout vs. checkout.  This is going overboard. Don't sacrifice readability for brevity.
 
Yup, yup, yup. Tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!