aspose file tools*
The moose likes Beginning Java and the fly likes Source Code Layout & Best Practice Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Source Code Layout & Best Practice" Watch "Source Code Layout & Best Practice" New topic
Forums: Swing / AWT / SWT Beginning Java
Author

Source Code Layout & Best Practice

Bd Howard
Greenhorn
Ranch Hand

Joined: Mar 30, 2012
Posts: 80
Hello,

I have been building a small portfolio of Java programs that I am using in my search for a job/internship. The code works to my satisfaction, but I am unsure if my source code itself follows best practice.

For instance, the code required to make a GUI work seems quite large to me, and I don't know if I've organized it in a wise and maintainable fashion.

So my question is this: could someone point me to a resource that would give me an example of how a professional organizes GUI code? Often in web based examples, the code is the bare minimum to get the point across, so I am hoping to find a "complete" GUI example with more than one type of listener, JPanels, buttons, checkboxes, etc.

Thank you for the help.

BD


I've got just enough Java knowledge to royally screw everything up. :-)
Bd Howard
Greenhorn
Ranch Hand

Joined: Mar 30, 2012
Posts: 80
Update:

Is the website JavaPractices considered a good source?
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39885
    
  28
I have never seen that website before; there are hundreds of websites of varying quality. I only looked up one link there: “don’t bury dialogs”, which was quite good about not passing null. It is a load of hints about advanced problems; I dodn’t see anything there about code layout. We have our own suggestions, which may be out of date, and I know many people disagree with some points.
Bd Howard
Greenhorn
Ranch Hand

Joined: Mar 30, 2012
Posts: 80
I appreciate the link you posted Campbell, I will take a look.

Your point about "varying quality" is what drove me to make this post. I can Google all day but I don't have the experience to separate the crap from the...uh.....non-crap.

I did some digging on JavaPractices last night and it seems like a good source to me, and your assessment is most helpful.

I did not find anything about code layout there, but they have good examples in terms of the initial GUI setup, which is what I was really focused on in terms of my code. My GUI init method was so long, and I know that is not a good thing. I saw some "tricks" they used to break it up into a more readable format, so I am in the process of changing my code now.

Thanks

BD

Ps. >30k posts? Wow. :-D
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39885
    
  28
A GUI init method (which most people call something like initGUI or setUpGUI) is about the one method which does come out being very long. What do they suggest to divide it up?
You can see similar code in a GUI frame constructor instead of initGUI.
Bd Howard
Greenhorn
Ranch Hand

Joined: Mar 30, 2012
Posts: 80
I don't think I should call this a suggestion on their part, merely an example I gleaned from code they posted.

In a nutshell, each individual JPanel is handled in its own method, and that method returns the JPanel (filled with all of its stuff) which is then added to the outermost JPanel/JFrame. This way appears to force the careful selection of which variables become fields and which stay local which is something I've struggled with. Makes me question the wisdom of using a procedural language to introduce new students to programming. ;-)

Thanks for the help.

BD
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39885
    
  28
You’re welcome
That sounds a good and simple way to break up that method. Are the component methods private?
A procedural language is good for procedural programming. I get the impression that people who have programmed procedurally take a very long time to learn object‑orientation.
Bd Howard
Greenhorn
Ranch Hand

Joined: Mar 30, 2012
Posts: 80
Yes, the methods are private. It appears to me that they are used merely to clean up the code and make it easier to add/remove stuff from the GUI.

The move from procedural to OO has been a challenge, but I am getting there. I learned to code using Fortran & Pascal back in the early 90s then decided to take a different career path. So my personal coding odyssey to OO is only influenced by procedural instead of dominated by it since I had forgotten much by the time I returned to school.

No coding for me today, since I have to repair my car. :-(

Cheers

BD
Stevens Miller
Ranch Hand

Joined: Jul 26, 2012
Posts: 567
    
    4

Campbell Ritchie wrote:I get the impression that people who have programmed procedurally take a very long time to learn object‑orientation.

I would have to agree, since I've been a programmer for forty years and, even though I think I'm pretty handy when it comes to algorithms and optimizations, I have had some conceptual problems with OOP. The basics are easy enough to grasp, but application design that makes good use of the OO paradigm is elusive. In defense of a lot of us PP types who have similar problems, I will say that many of the books and Web sites that purport to teach the paradigm are often just as hard to grasp as the paradigm itself (for example, if I see the phrase, "closest to the data" one more time, I may just start sobbing uncontrollably).

Now, when the OP asks about "Source Code Layout," it appears he means overall design. But, taken literally, he could also have meant formatting (what we mostly call "indentation rules," I think). FWIW, I learned good ol' Fortran by punching cards on one of these,, in the late 1970s. Around 1979, I learned Pascal and, with that, the word "prettyprint." In my first for-pay programming job, I changed the entire programming department's practices by being the first person any of them had ever seen to prettyprint his Fortran code (which, granted, hadn't always been possible with earlier Fortran compilers). That little bit of formalistic change helped move me (and maybe some of my co-workers) forward a bit, as a programmer. My point being that, with a little help and encouragement (and straight answers ), even us old dogs can learn new tricks.
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2435
    
  28

Bd Howard wrote:Hello,

I have been building a small portfolio of Java programs that I am using in my search for a job/internship. The code works to my satisfaction, but I am unsure if my source code itself follows best practice.

For instance, the code required to make a GUI work seems quite large to me, and I don't know if I've organized it in a wise and maintainable fashion.
BD


Bd Howard wrote:

Your point about "varying quality" is what drove me to make this post. I can Google all day but I don't have the experience to separate the crap from the...uh.....non-crap.


This is where a good grounding in principles of software design become helpful. Starting off with a small philosophical aside observation. You have asked a very very good question. Your basic question is "how do I make my code maintanable?" The software engineering profession as a whole has been struggling with this question for 60(? or is it 70) years now. However, we aren't at the stage yet where clean code comes right out of the box. As a profession, we are getting better at it.

Now, as to what you can do personally. I can say that you have started off in the right direction, by simply thinking about how to make your code maintanable. Sadly, there is no easy answer. This is not something that you can learn in a short period. It takes years and years to build that intuition about good design. Differrent people have differrent approaches to learning how to design. Going into another minor metaphysical aside again: "Differrent paths lead to the same goal, and you have to find your own path"... young grasshopper... umm ok enough that

The approach that has generally worked for me is this
a) Identify the pain points in the existing code base. Is it too much code? Is it inefficient code? Is it complicated code? Is it difficult to maintain?
b) Identify the root causes of the pain points. Is there too much code because there is lot of repeated code? Is it difficult to maintain because there are too many dependencies?
c) Look for other people who have solved the same problem. At this point in time, we are very very lucky that there are a lot of Open Source projects of really good quality that give you their code for free. Generally, any problem that you will face has been solved by someone else before. Study their solutions.
d) See how you can apply their solutions for yourself

And above else remember that your code is never going to be perfect. No matter how good you make it, you will always find things to improve. So, don;t be afraid to try a good-enough solution out just for the heck of trying it out. It may work, it may not. You will know after you try it. Don't wait for the "best" solution
Bd Howard
Greenhorn
Ranch Hand

Joined: Mar 30, 2012
Posts: 80
Stevens,

Thanks for the post, I appreciate every viewpoint I can get. I was referring more to design than formatting. I am trying to learn to break things up in a manner so others can follow what I am trying to code. I've made good progress, but there is always room for improvement. Oh, and I am glad old dogs can learn new tricks, since that means there is hope for me. :-)



Jayesh,

I have four programs in my portfolio, and I do a round-robin update to them. As I learn more, I just revisit each and change its code to show my new knowledge. Several times, I have come back to one of them and looked at the code and frowned. How could I write such ugly code?? haha

As far as the best solution, I believe I am far from that. Each of my four programs have always worked, but the code was difficult to follow at best, and just plain old spaghetti at worst. That is changing though.

I appreciate your input. :-)

BD
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Source Code Layout & Best Practice