[java] java programming habit

Started by
16 comments, last by tebriel 18 years, 9 months ago
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-
"Education is when you read the fine print; experience is what you get when you don't." -Pete Seegerwww.lucid-edge.net
Advertisement
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-

"Education is when you read the fine print; experience is what you get when you don't." -Pete Seegerwww.lucid-edge.net
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;  }
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 )
Please post your code, that yould help? Do you override the paint method?
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.
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
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.

This topic is closed to new replies.

Advertisement