Java Convention

[Eyal Golan]

Hi all,
I'm not sure if this is the right forum, but the question is relevant to any java (or other language) programmer.

There is the old debate on how many exit point should a method have?
I think that a method should exit the minute it know it can.
Others think that it should exit only in one location.

I don't want to open this discussion.

I have a different situation, I've recently inherited a project that is in a very early stage.
The guy you developed it before, had a convention of one exit point.

Now, should I continue with his convention, or whenever I write new functionality (method), I can use mine?

What do you think?

[Campbell Ritchie]

If you already have a convention in that project, it will cause no end of confusion if you change it. People maintaining that code in future who find part of it written with only one exit will get confused if there are a few methods with multiple exits.

That's just my opinion, and you may find people who disagree.

[Rob Spoor]

I generally disagree with using only one exit point. However, I also agree in adapting to the project style. If that style is one exit point I would force myself to adapt.

[Gian Franco]

Hi Eyal,

As Robert C.Martin would say clean code reads like well-written prose.

If this means that you have to deviate from single exit points then why
not?

[Avishkar Nikale]

Can we say that a method objective should dictate the same?

1) Lets say a factory class depending on various conditions creates a object
& assigns it to the return reference.
The return statement usually is at the end of the method.
2) If it is a execution of a business process it might make more sense to return if the
process cannot continue further.

? ? ?

[Eyal Golan]

Rob Prime wrote:I generally disagree with using only one exit point. However, I also agree in adapting to the project style. If that style is one exit point I would force myself to adapt.

Rob Prime wrote:As Robert C.Martin would say clean code reads like well-written prose.

Yes I agree with you all..
I thought that maybe someone will encourage me to do it differently

[Eyal Golan]

Avishkar Nikale wrote:Can we say that a method objective should dictate the same?

1) Lets say a factory class depending on various conditions creates a object
& assigns it to the return reference.
The return statement usually is at the end of the method.
2) If it is a execution of a business process it might make more sense to return if the
process cannot continue further.

? ? ?

True,
but in my situation EVERYTHING has one exit point, even situation like your second remark.
(but hey, you're encouraging me to do it the way I prefer...)

[Avishkar Nikale]

Eyal Golan wrote:
True,
but in my situation EVERYTHING has one exit point, even situation like your second remark.
(but hey, you're encouraging me to do it the way I prefer...)

If its a strict guideline formulated for your project, then I advise you to follow the same.

If not you can involve all the stake holders and come to a conclusion on the same.
(You can do it even for the first case if you have the authority)

Thanks for the post.

[David Newton]

If it's your project, and you're making the decisions, do it however you want.

[Ninad Kuchekar]

Hi Eyal,

Best way is to continue with what you are comfortable with, its not like you are doing it the wrong way; I which case you definitely should change.
The important thing to remember is to have a well documented code.As long as you are doing that and people know your intentions crystal clear, you are good to go.

This is my opinion, again, feel free to disagree...