• Post Reply Bookmark Topic Watch Topic
  • New Topic

Is the way I set up this class considered good programming?  RSS feed

 
Yosuf Ibrahim
Ranch Hand
Posts: 128
4
Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I set up this class just for the JMenuBar at the top of my applications, I had all this in one method at the beginning setUpMenuBar, however I decided for some reason I have no idea what to split them all up into tiny methods and wish to know the way I did this is it considered good programming or not?? Is this more efficient or having it all in one method?? And if you guys can tell me more about good programming I am all ears and eyes Cheers

Staff note (Liutauras Vilda):

Cow for good code indentation, formatting.

 
Junilu Lacar
Sheriff
Posts: 11476
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Splitting up into smaller pieces is a Good Thing™ so, yes, in that respect, it's a good practice. Keep doing that and make it a habit.
 
Junilu Lacar
Sheriff
Posts: 11476
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Having said that, there are a number of things you can do to improve your code even more.

1. Follow standard naming conventions. Java method names do not normally contain underscores.  The sole exception to this in my own code is when I write unit tests. My unit test methods have underscores because they tend to be longer than normal method names and I found underscores makes them more readable. Otherwise, method names are written in camel case, starting with a lowercase letter.

2. Don't be redundant with your names. The "_MenuSetUp" and "_MenuItemSetUp" parts of the names are redundant with the declared return types. See the alternative below. Doesn't that look cleaner? When you read the code, is there any doubt that help() is a JMenu and that about() and credits() are JMenuItem objects?

 
Junilu Lacar
Sheriff
Posts: 11476
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This may be more a matter of style but I prefer plain white space rather than this kind of comment:

To me, the above just creates more visual clutter. YMMV.
 
Junilu Lacar
Sheriff
Posts: 11476
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Finally, hardcoded values like "/media/icons/heart.png" makes your code more rigid and brittle. In more long-lived programs, you will usually need to be more flexible so rather than hardcoding values like this into the program, you either inject these values instead or you use symbolic names that are used as keys to find the actual values from an external store.
 
Junilu Lacar
Sheriff
Posts: 11476
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I forgot one other thing.  In this case, I don't know if it's really that big of a deal but normally, when I see all static methods in a class, it's a red flag.  Classes that don't have any instance methods usually turn out to be glorified scripts, i.e. procedural code that is disguised in object clothing. Just keep that in mind for future reference.
 
Junilu Lacar
Sheriff
Posts: 11476
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yosuf Ibrahim wrote:however I decided for some reason I have no idea what to split them all up into tiny methods and wish to know the way I did this

Good programming instincts?

Seriously though, breaking up big chunks of code into smaller chunks is a good way to manage complexity. Complexity is bad. Simplicity is good. Smaller tends to be simpler. Also, you can separate high-level abstractions from low-level details. This is in line with the Single Level of Abstraction Principle (SLAP) which is also a good thing. Simpler code also tends to be easier to understand, maintain, and debug. So you see, there are many benefits to doing this kind of thing. Keep it up.
 
Yosuf Ibrahim
Ranch Hand
Posts: 128
4
Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wow man you are one busy rancher. Cheers.

I do agree the way you named is cleaner and better than mine. Like way cleaner will definitely be more careful in future names and will fix those ones.

In my java course last semester I used dashes less frequently when white space alone didn't work. Now this is my personal project I am working on to up my game in java and not forget what I already know I am doing it way worse since I don't have a plan of where I am going with this. Which is now the reason i will take a pen and paper and start planning exactly where I am going with this app and how.

Regarding the path names, Roger I will create a a class called settings in which I will put these default path names and which should allow me to easily change them in future.

I had no other ideas for when creating GUI items that will not change throughout. Classes with fully static methods was the best idea I had, and for some reason I was not comfortable with those but had no better idea.

Thanks for the advice and hope to get more.

Cheers
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!