Stijn Rensen

Junilu Lacar wrote:"Experience is what allows you to recognize a mistake when you make it again."

wow the wisdom spouts of this quote

Thanks Junilu for your comment. Yes there is a lot of merit to the more compressed version. And the more I think of it the more I get enticed to follow you in this one. Especially when moving the comments to the top of the method explaining the logic (liking the www reference btw).

Maybe it also comes down to some experience. Having a lack of that I'm more inclined to write things out more to be sure I will understand it later when reading it back. Though I should trust myself and others reading my code to understand some degree of abstraction in the actual code.

Ah thank you!

That is a good one to take out of this.

I know that there is an alternative for this code in the following:

public boolean isLeapYear (int year) {      return ((year % 4 == 0) && (year % 100 != 0)) || (year % 400 == 0); }

And I feel that this is probably better coding. However I cannot grasp what risks I'm running in the first version. Where I do think it is easier for me to follow "the story of the code" in the first version.

Kind Regards,

Stijn

Hi,

I was wondering if the code below is proper coding. I know it functions as how I want it*. However I'm not sure if this way off coding opens me up to nasty bugs. The book I'm currently using does not go into a lot of detail whether this is good or bad coding.
Thanks for the replies.

public boolean isLeapYear (int year) { boolean isLeapYear=false; //Deafault not a Leap Year if (year%4!=0) {return isLeapYear;} //Not divisible by 4, never a Leap Year if (year%100!=0) {isLeapYear = true; return isLeapYear;} //Divisble by 4, not divisbile by 100 > Leap Year if (year%400==0) {isLeapYear = true; return isLeapYear;} //Both divisible by 100 and 400 > Leap Year return isLeapYear; //Divisible by 100, but not by 400 > not a Leap Year }

*Note: This is not the exact code as the exact code has dutch comments en dutch named variables. So this code could have some type errors in the variable names.

That's not really needed I think. I was just interested in the principal of where to place things in a class. Thanks for the offer though.

Update: I finished the coding and all is working as planned. In case one is interested I can post the code of the MovingBall class. However in real this code is a little bit Dutch language based, meaning in the variables and comments have dutch in it.

Thank you Paul for this reply. It is good to get this just before you go to sleep. It gives one something to wander off with ;).

By the way: I do somewhat agree that a list of existing option could have been fruitful. However they all went into the detail of here is the code, problem solved next. Where the used code contained a lot of methods I haven't heard about yet, even remotely. Plus I was not interested in een piece of code as a reply. I rather get a better understanding on the concept of where I can do what with certain information (like where I will be getting a usefull response of the getWidth() of the JPanel).

With you strong and good hint I ended with the following:
- I can only initialize or reset the x Position of the ball within the paintComponent method
- By default I want to initialize/reset the position of  the bal
- Only when I press a button I do not want to reset the position but actually move the ball

So to do this I: will add a new variable to the class: resetBallxPosition with the default value true.
Within the actionPerformed method I set the variable of resetBallxPosition to false and update the position of the ball based on the button pressed. then I call repaint()
Within the paintComponent method I check resetBallxPosition. When true I reset the position to this.getWidth()/2.
At the end of the paintComponent I set the value of resetBallxPosition back to default true.

I feel this quite an ok solution for it, not too janky at all. However I do still wonder if there is a default way to go with this.

Learning the Basics of Java I'm trying the following exercise:

write a program that starts off showing a ball in the middle of the the screen and 2 buttons: left, right
have the ball move to the left or to the right based on the button pressed.
Make sure the ball does not drop of the screen.
Size of the ball and the delta x are pre determined.

I've written 2 classes:
A class that holds main method and creates a JFrame which adds a JPanel of the type MovingBall to its JFrame
A class MovingBall with 3 methods:
- MovingBall(): contains the creation of the Panel with 2 Buttons
- ActionPerformed(): Determines which button was pressed. Calculates new ballxPos calls repaint ()
- paintComponent (Graphics g): paints the actual ball

in the class I declare the following variables:
private JButton Left, Right;
private int ballxPosition = getWidth()/2;
private final int BALLRADIUS = 50;
private final int STEPSIZE = 13;


All these variables are declared at the beginning of the class outside of any methods. The problem I'm having is with the variable ballxPosition. It returns 0 where I would like to get the actual width of the JPanel.
with some Googling I learned that this is supposed to happen because the Panel hasn't been created yet. But all alternatives given as solution feel all kind of janky.

I did think up of an alternative way and initialize the variable within paintComponent and add a variable the tracks the amount off times I have to offset to left or right. however this feels very janky as well.

What is a clean spot to get the Width of the screen before I kick off any recurring methods (ie: actionPerformed, paintComponent)?

Kind regards,


Newbie Stijn

Stefan Evans wrote:Actually, my solution would have been :

nextDate = "the day after " + month +"-" + day + "-" + year + " is " + nextMonth + "-" + nextDay + "-" + nextYear + "."; return nextDate;

But then I like stepping through code with a debugger, and this format lets you stop and inspect the return value of the method very easily, whereas your first example doesn't directly.

That has some merrit to it too, Especially for a noob like me.

Liutauras Vilda wrote:

Stijn Rensen wrote:Is this also good coding practice?

I'd suggest you to choose variable names more carefully: day, nextDay, nextDate it's rather confusing and error prone. You can easily misplace variable and it would take hours to find out what is wrong.

What would you suggest in this case? The goal of the method is to construct a string that will tell you the the next date of a given date.

Liutauras Vilda wrote:

Stijn Rensen wrote:Or is this adjustment purely to positively influence the mood of eclipse?

Nothing is wrong with Ecplise, actually it says what it is. In any expression you never used this nextDate variable.

I wasn't saying eclipse is wrong. I guess I was naive in thinking I could be humoristic... :/ ;)

Oh wait, found the answer myself in the book. Guess I shouldn't read to fast in order to get to the next excersize more quickly.

Ah cheers! I didn't know it is allowed to write a return like that. Is this also good coding practice? Or is this adjustment purely to positively influence the mood of eclipse?

As a studyproject I'm currently writing a class the allows me to get al fun dates (like when eastern is in a given year, what day a given date has, calculate the date of tomorrow).

While working on the following method:

public String getNextDate (int day, int month, int year) { String nextDate; int nextDay = getNextDay(day, month, year); int nextMonth = getNextMonth (day, month, year); int nextYear = getNextYear (day, month, year); return nextDate = "the day after " + month +"-" + day + "-" + year + " is " + nextMonth + "-" + nextDay + "-" + nextYear + "."; }

I get a notion in my lovely IDE (eclipse) reminding me I'm not using nextDate ("The value of the local variable nextDate is not used")
But I feel I really do use nextDay here. So either I'm making a coding(style) mistake giving me this notion or I should just ignore this notion.

Any elaboration on this is really appreciated. Any other feedback (compliments/ critism) is also always welcome ;)

Stijn

thanks Bear and Thomas,

Seems like we are on the same page. good Naming is important. And adding the type of the element to a variablename isn't a bad thing. cryptic abbreviations is the thing you want to avoid. Unless they are widly accepted. Like i for a counter, or g for the graphics.