*
The moose likes Java in General and the fly likes which of following is Best way to Code? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "which of following is Best way to Code?" Watch "which of following is Best way to Code?" New topic
Author

which of following is Best way to Code?

Azrael Noor
Ranch Hand

Joined: Jul 29, 2010
Posts: 382
Could you please tell which of following is best way of code and why?

Instantiation declaration at one place:


or should we declare the objects first and use them?




In addition to this, also please suggest while making inner class where should we keep Inner Class for readability standards? On base of whole code or somewhere in between code or on top of class code?


Regards
Azrael Noor
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4376
    
    8

I'd definitely use the first approach, unless you needed to refer to any of those variables outside the try block (in which case you've got no choice). As a general principle it's a good idea to limit the scope of variables to as small as possible.
Azrael Noor
Ranch Hand

Joined: Jul 29, 2010
Posts: 382
Matthew Brown wrote:I'd definitely use the first approach, unless you needed to refer to any of those variables outside the try block (in which case you've got no choice). As a general principle it's a good idea to limit the scope of variables to as small as possible.


The General approach

> Variable Deceleration on Top
> Initialize or Apply behavior on states

isn't it good idea for readability? please correct

Return Null at end, i think this looks cool in this particular situation only

Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14117
    
  16

Another remark: Your catch-block should never be empty, because then you won't know what happened if an exception occurs. Also, catching Exception is a bad practice. Only catch the exceptions that you need to handle.

In fact, the code you posted won't compile, because a return statement is missing. What does the method return when an exception occurs?


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Azrael Noor
Ranch Hand

Joined: Jul 29, 2010
Posts: 382
Jesper de Jong wrote:Another remark: Your catch-block should never be empty, because then you won't know what happened if an exception occurs. Also, catching Exception is a bad practice. Only catch the exceptions that you need to handle.

In fact, the code you posted won't compile, because a return statement is missing. What does the method return when an exception occurs?


Ok Sir, you mean use multiple catches whether 5 8 or 10
but not to catch exception in exception object ?


Code corrected in second post added return null :p
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7718
    
  20

Azrael Noor wrote:Could you please tell which of following is best way of code and why?

I think most people would say that the first is better, providing you don't need any of those variables in the catch part of the code; but to be honest, it doesn't make that much difference.
I have a slight preference for declaring my class variables at the top, because it seems less cluttered to me. All other things being equal, I also prefer to instantiate them in the constructor. But there are arguments for other approaches.

Far more important is to declare method variables in the scope where they belong: eg:is preferable to:
In addition to this, also please suggest while making inner class where should we keep Inner Class for readability standards? On base of whole code or somewhere in between code or on top of class code?

Well, first off, I rarely use inner classes. A static nested class is usually all you need. I tend to declare mine at the top of the enclosing class; but I can quite understand why someone might prefer to do it somewhere else (eg, at the bottom).

With a lot of these questions, there is no "right" or "wrong" answer; it's simply what you find more readable. What I would say though is: be consistent.

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Azrael Noor
Ranch Hand

Joined: Jul 29, 2010
Posts: 382
Thank you all,

Winston Gutkowski :

In Inner Class i am creating a Thread make code somewhat like



Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7718
    
  20

Azrael Noor wrote:In Inner Class i am creating a Thread make code somewhat like

Erm...OK. However, from what you've written, I can't see any reason why ThreadImplementation couldn't just be a static nested class.

Winston
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4458
    
    6

Azrael Noor wrote:
Return Null at end, i think this looks cool in this particular situation only

It's not about looking cool, it's about what's correct and least surprising. When some kind of a list is expected to be returned by a method, my rule is to NEVER return null. When you declare a return type to be a list, always return a list, even if it's just an empty list. This way, the calling code never has to check for null and it results in cleaner code.

If the getFooList() method were to return null, the calling code would get a NullPointerException and I would consider this a bug.
Azrael Noor
Ranch Hand

Joined: Jul 29, 2010
Posts: 382
Junilu Lacar wrote:
Azrael Noor wrote:
Return Null at end, i think this looks cool in this particular situation only

It's not about looking cool, it's about what's correct and least surprising. When some kind of a list is expected to be returned by a method, my rule is to NEVER return null. When you declare a return type to be a list, always return a list, even if it's just an empty list. This way, the calling code never has to check for null and it results in cleaner code.

If the getFooList() method were to return null, the calling code would get a NullPointerException and I would consider this a bug.


Mr Lacar, When exception is thrown in between then List have Null inside it,

lets take case of NodeList example. If some exception thrown the reference with NULL will be returned so i need to check if object is null or not.

The reason i have returned NULL directly.




Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4458
    
    6

My This advice is sound and it has worked well for me and my teams for many years. Over time, you may find yourself agreeing with me. In the meantime, good luck with your approach.

Edit: in the spirit of full disclosure, this is not even my idea. I read it somewhere (maybe Joshua Bloch?) and decided it was very good advice. I have followed it since and it has only been beneficial to the code I and the teams I work with have written.
Azrael Noor
Ranch Hand

Joined: Jul 29, 2010
Posts: 382
Mr. Lacar, i have done code like this now. I find it bit more understandable

Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4458
    
    6

One more shot at trying to help you improve your code ...

From the looks of it, you are really interested in getting a list of "Service Parameters", hence the method name "getParameters". XMLNodeList is just a way to get to these. The fact that your service parameters are stored as XML is an implementation detail.

Advice #1: Always try to hide the implementation details from client code (abstraction). Determine what the client is really interested in and return that instead.

The code is too busy with implementation details. Aside from the method name, I can't readily understand the logic. My benchmark is that I should be able to read a method and understand, at a high-level, what it is doing in less than 10 seconds. Any longer than that, I require that a Compose Method refactoring be done to reveal the intent of the code.

Advice #2: Break this method down into smaller pieces using the Compose Method refactoring to reveal its intent.

From the looks of it, there are three things happening in here: 1) Getting the file path/resource bundle 2) Building the XML Document, and 3) Parsing the document into a list. What's missing is what I was alluding to in #1 above: what is the client code really interested in? Seems to me, you should go through the list of nodes extracted from the XML, extracting the "parameters" from the XML and putting that into the final List that you should be returning. So, really, this method could be just 4 lines, each line calling a smaller, more concise method that does one and only one thing.

Advice #3: Listen to the other advice you have been given about exception handling and limiting scope of variables. Doing that will lead you to a better understanding of why you shouldn't return null.
Azrael Noor
Ranch Hand

Joined: Jul 29, 2010
Posts: 382
Very Nice Suggestion,

> I will break getParameters() into more parts
> I actually do not have to handle that exception so i havent do that, but i keep that in mind

Actually the code just going to initialize a thread where Nodelist is passed and that thread calls other class:

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: which of following is Best way to Code?