Sign in to follow this  
bgilb

[java] java programming habit

Recommended Posts

bgilb    232
Im getting into a habit. I have subclasses and, whenever I want to access something from the main class, I always make long message calls such as: vanMain.myGame.randomInteger=5; Is there any other way around this? I fear my programs are using lots of bad practices that not only make code hard to read, but also make the program slower.

Share this post


Link to post
Share on other sites
Son of Cain    480
Not directly related to your problem, but a book has been written by four developers (known as the 'Gang of Four'), where 21 design patterns where discussed. These patterns are elegant solutions for many issues, and you should take a look.

Also, Sun has code conventions for the Java programming language.

Son Of Cain

Share this post


Link to post
Share on other sites
Strife    374
I really hate Sun's insistence on not putting opening curly braces on its own line.

That's always bothered me for some reason.

Share this post


Link to post
Share on other sites
Preacher    154
What your descibing is known as the java train or something like that, where a field is accessed by drilling down through layers of classes. look into the facade design pattern which basically is a class that acts as an interface to a group of sub classes.

so instead of calling

myClass.someClass.anotherClass.field

you create a top level class with methods that handles all the drilling down to the property you want.


so now you just call:

myClass.accessField();

and the access field method accesses the field and does whatever you want with it
An example of a facade pattern would be a class that manages a database, opening closing adding removing. one class would provide an interface to all this fuctionallity but in practically the functionality is spread over a number of hidden subclasses

hope that helps:)

Share this post


Link to post
Share on other sites
Son of Cain    480
Quote:
Original post by Strife
I really hate Sun's insistence on not putting opening curly braces on its own line.

That's always bothered me for some reason.


I also hate that, and I do not follow this. I always put the opening curly braces in the same line of the end of the method signature, or class declaration, etc...

And I didn't knew it was on the convention to use these braces in a new line. I never did it, and I don't plan to change the way I do it ;)

Son Of Cain

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Been using the both styles for years, and I can say the Sun's convention wins anytime. Easier to type, saves space and looks nicer when you get used to it. Especially in single-line methods.

Share this post


Link to post
Share on other sites
Sneftel    1788
(K&R braces versus Allman braces) = dumb. It is absolutely trivial to conceptually switch between the two styles.

Share this post


Link to post
Share on other sites
Son of Cain    480
Quote:
Original post by Sneftel
(K&R braces versus Allman braces) = dumb. It is absolutely trivial to conceptually switch between the two styles.


Agreed =D. Pick the one who best suits you, and go for it.

Share this post


Link to post
Share on other sites
Grahf750    122
I hope this is what you uys are talking about.

if (x>9){
.....some code
}

compared to

if (x>9)
{
.....some code
}

Personally I like the second way better you can see where the brackets start and end much easier because they line up it is especially good if you have lots of nesting going on.

Share this post


Link to post
Share on other sites
Lucidquiet    199
I come from a lisp background and all the damn parenthesis make you want to follow the left brace on its own line, but java is so very clean (and for that matter C/C++ as well) that it is trivial...but.

If you don't already have this, or would like to, here is some ant stuff for a beautifier call to JIndent (for copy paste purposes), this is just a ant target:


<!-- ================================================================== -->
<!-- Format Source Code recursively throughout the source tree -->
<!-- ================================================================== -->
<target name="format" depends="compile" description="JIndent Format" >
<java jar="lib/Jindent.jar"
fork="true"
classpathref="classpath" >
<arg value="-r" />
<arg value="${src}" />
</java>
</target>







You'll also need the JIndent pure java downloads from JIndent.com, and to put the jars from that download in the /lib dir of your project. This is not the JIndent-ant.jar but nearly all the other jars that come with the d/l.

It's nice, and you can edit this to accept a file with your custome format preferences.

Slightly off subject -- sorry bgilb,
L-

Share this post


Link to post
Share on other sites
Lucidquiet    199
Quote:
Original post by Strife
That's not necessarily a bad thing, but not using way too many nested classes seems to make the most sense.


You mean parent classes not nested classes right?

Its a pretty good question though: what is a good rule of thumb for the depth of a heirarchy/ancestry in a game say for something like a game entity -- spaceship or robot or monster? They're moveable, renderable, ID-able, destroyable, reproduceable, customizeable, effectable (many-to-one), runnable, seraializeable, event-firers, etc. Now if all of these were super classes -- would that be acceptable. Hmmmm. Most of this would be just interfaces, but some of those interfaces would be found in super classes. Still this could lead to an ancestry say 3-4 classes deep.

I haven't seen any metrics that say this is bad -- but someone with more experience could probably say for sure.

L-

Share this post


Link to post
Share on other sites
tebriel    904
Quote:
Original post by Grahf750
I hope this is what you uys are talking about.

if (x>9){
.....some code
}

compared to

if (x>9)
{
.....some code
}

Personally I like the second way better you can see where the brackets start and end much easier because they line up it is especially good if you have lots of nesting going on.


The 2nd edition of Code Complete has a whole section about this. The second example above (although I've used it often in the past) isn't favored by the author. This one is also OK (in addition to Java style) according to the author:


if (blah)
{
weeee = 2;
}


Between this style and the standard Java style, a study was done that found no statistical differences in understandability between the two.

Myself I use different styles--the Sun style for Java coding, and whatever is more appropriate for C++ coding (I aim for consistency with whatever source I'm working on). I don't find it harder or easier to read either style. For the Java style brackets, to help readability, just add an extra blank line and you get basically the same visual effect. There's no use in going against standards and practices that are well established if the practical differences between the two are trivial.

Read the book if you want to know why the below is not ideal..(although personally I've used it often and I like it.) :P


if (blah)
{
weeee = 2;
}


Not terrible either, though. There's worse styles out there. Like this last one...don't do this!!!


if (blah)
{
weeee = 2;
}

Share this post


Link to post
Share on other sites
bgilb    232
Well I have noticed something is wrong in the repaint or somewhere, because when my player moves around, the tiles skip and have trouble keeping up.

Heres a picture:http://photobucket.com/albums/y10/bgilb/vanerror.png

The map is 4 layers ( 2 below the character and 2 above )

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Please post your code, that yould help? Do you override the paint method?

Share this post


Link to post
Share on other sites
Strife    374
Quote:
Original post by Tebriel
Read the book if you want to know why the below is not ideal..(although personally I've used it often and I like it.) :P


if (blah)
{
weeee = 2;
}



I hate it when people try to tell you that your coding style is no good. I've got news for all of those people: As long as anyone looking at it knows what's going on in terms of the organization, it doesn't matter.

Sure, there are some styles that are worse than others (in that it takes a while to figure it out), but this one above is what nearly EVERYBODY uses. So screw Code Complete. Only morons think that there's only one ideal way of doing things.

Share this post


Link to post
Share on other sites
polly    532
Its generally not good coding style to access variables directly; thats what accessor/mutator methods are for.

Unless you have a good reason to, make all fields private and only provide accessor methods if you think the class should provide access to the data.

One exeption to this could be subclasses accessing super class fields - when you want a peice of data to be accessed directly by subclasses and not by any other class. However, to start with, even in the case of inheritance (subclasses accessing superclass data) I would keep most data private and provide accessors with the appropriate access modifier (private, package private, protected or public).

For example, say I'm working on a project with a few friends. I assume that in the future any subclasses of my new class will use protected accessor methods to get at its private data. Lets also say my class uses lazy-loading to load data from a file or data store and thus that data only gets set when the accessor method for that data first gets called.

Later on, one of my team comes along and edits part of the class, thinking to himself "Hell, we can just make this variable protected and avoid a whole load of method calls" he edits some of the private data and so bypasses my lazy loading accessor method, assuming that the accessor method does nothing other than return the value.

In this example, my friend has just introduced a bug into the project by making the private data protected. Without a decent test suite this bug could go undetected for months, and could well be hard to trace by the time it starts causing problems.

To cut a long story short; try not to break encapsulation, even for subclasses. And don't avoid calling methods because you think it'll slow your app down.

I also recommend reading: Effective Java, one of the few Java programming books you should bother reading.

Jon

Share this post


Link to post
Share on other sites
tebriel    904
Quote:
Original post by Strife
Quote:
Original post by Tebriel
Read the book if you want to know why the below is not ideal..(although personally I've used it often and I like it.) :P


if (blah)
{
weeee = 2;
}



I hate it when people try to tell you that your coding style is no good. I've got news for all of those people: As long as anyone looking at it knows what's going on in terms of the organization, it doesn't matter.

Sure, there are some styles that are worse than others (in that it takes a while to figure it out), but this one above is what nearly EVERYBODY uses. So screw Code Complete. Only morons think that there's only one ideal way of doing things.


I don't really disagree with you, I like that style myself too, but Steve McConnell didn't just say "this isn't the best way" and proclaim it so... Like I said, you'd have to read the book to understand his reasoning. (Too much to bother even trying to explain here.) But even he says that most likely readers aren't going to agree with EVERY thing he says, so at least he's not saying his best practice advice is bible.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this