is following Programming(Blocks) style correct in Java?

is following Programming style correct in Java?

Making blocks for a type of situation within a function where we use only global things?

does this give any sort of problem ?

func is not a valid return type. Hopefully you got it from other programming languages?

It will give a compilation error - but I am not sure what you are relating to with the { } blocks. May be some other rancher can help.

One reason for doing this would be to limit the scope of variabes declared inside the block. For example:

It is however not usual to do this and in my opinion this indicates that your method might be too long or complicated. Probably you should put the block in a completely separate method. I would certainly not call this good style.

Jesper de Jong wrote:One reason for doing this would be to limit the scope of variabes declared inside the block.
It is however not usual to do this and in my opinion this indicates that your method might be too long or complicated. Probably you should put the block in a completely separate method. I would certainly not call this good style.

I have seen code before that was full of these scoped blocks. It was ugly and difficult to read. I would definitely avoid using this style if possible.

Koen Aerts wrote:

Jesper de Jong wrote:One reason for doing this would be to limit the scope of variabes declared inside the block.
It is however not usual to do this and in my opinion this indicates that your method might be too long or complicated. Probably you should put the block in a completely separate method. I would certainly not call this good style.

I have seen code before that was full of these scoped blocks. It was ugly and difficult to read. I would definitely avoid using this style if possible.

Seconded. I want to be able to grasp the code structure quickly, without having to think a whole lot about it. A profusion of braces is an obstacle to this.

Thank you for replies

But question basically was any overheads for compiler? Technically

Does it need to work more for executing blocks ?

It is looking good for reader who involved in same project
as he need to know what's going on in lines of code
and if i group some he could easily predict that, in this block, "this is happening" and in other bloack that is happening and all in one function.
I mean flow of program would be clear.

but as you said that for layman to that code it would be but confusing. i think it is correct but i am bit confused

and ya i just gave piece of example, one of our friend comment, it will give compilation error

Dennis Deems wrote:

Koen Aerts wrote:

Jesper de Jong wrote:One reason for doing this would be to limit the scope of variabes declared inside the block.
It is however not usual to do this and in my opinion this indicates that your method might be too long or complicated. Probably you should put the block in a completely separate method. I would certainly not call this good style.

I have seen code before that was full of these scoped blocks. It was ugly and difficult to read. I would definitely avoid using this style if possible.

Seconded. I want to be able to grasp the code structure quickly, without having to think a whole lot about it. A profusion of braces is an obstacle to this.

Ok in my case i have to parse XML in which two entities are for future work and important through out application, other entities are not that much important

i am not going to make extra functions for parsing that piece of code

lets take example

On Other Side

same i have to use in many piece of application ..... to avoid confusion......

now please suggest more!!!

If you just want more clarity in your code, use comments and blank lines.

That looks more like JavaScript than Java™. I doubt greatly that it would compile.

Koen Aerts wrote:If you just want more clarity in your code, use comments and blank lines.

_________________

Ok, now come to Compiling Overheads, what would occur if code remains like this will it take more time to execute and it is not javascript

Koen Aerts wrote:If you just want more clarity in your code, use comments and blank lines.

I didn't mean in addition to the scoped blocks... I meant INSTEAD of the scoped blocks.

Azrael Noor wrote:Ok, now come to Compiling Overheads, what would occur if code remains like this will it take more time to execute and it is not javascript

I don't think it makes much difference in compilation time. Execution wise, perhaps I can see an extra millisecond or so if you use new variables in the scoped block which will require extra space on the stack, but I can't imagine that really making any noticable difference. It's still no excuse for using the scoped blocks though.

Using language constructs needlessly in place of something simple like comments impedes code clarity, and just makes the code look sloppy.

Azrael Noor wrote:Ok, now come to Compiling Overheads, what would occur if code remains like this will it take more time to execute

That should be the last of your worries. It's very unlikely that any difference will be remotely relevant in a real application. Whereas readability is always important.

Blocks hinder readability?

well ya it adds few more curlies to the code, Does it effect readability in true sense?

In my opinion, yes. They're not customary, so it makes people stop and wonder, "why are they there? What's their purpose? Am I missing something important?"

This impedes clarity.

You should strive for clarity in your code; not cleverness.

Bear Bibeault wrote:They're not customary, so it makes people stop and wonder, "why are they there? What's their purpose? Am I missing something important?"

That is exactly the kind of stuff I was thinking the first time I noticed such things in a source code. It confused the other developers on the same project, too. It didn't make anything clearer to read. On the contrary.

I'm hoping that by now it has become obvious to you that you should avoid using these blocks.

AVOIDED

If you really think a function is big enough to be broken out, you should break them out into sub functions rather than deliating them using curly braces.

The functions should be broken up so that they are as self-contained as possible.

That is not according to some standards which i am following, also use block or not is not part of standards. Better to comment it,
but commenting everywhere is also not part of standards.

so i was avoiding comments. it feels i am writing some guide book in code of 10 thousand lines

.

Now

No BLOCK
No COMMENT
No METHODS

USING WHITE SPACES

Let the next coders understand themselves, what to do.

As a developer, it's your job to make sure the code is readable. Every little rule doesn't have to explicitly mentioned in some standard document for you to follow it. Here's a general rule of thumb:- If you have problems following your own code, you need to refactor/document it

Just to muddy the waters a little (i.e. to put more burden back on the OP to form his own opinions), I'll mention that I occasionally use those blocks, partly to make the code more readable (separating sections of processing), partly to limit the scope of variables so I can copy/paste stuff, reuse the same final variable name, etc., and partly as a sign that, "yeah, this should be refactored one of these days."

In an ideal world, methods would be short enough and repetition rare enough that these situations would never arise, but, well, you know the rest.

> Comments between them also looks lousy or may be IDE problem using Eclipse Indigo
> Using Much Curlies, inside two curlies(method), are also indistinguishable it is correct impedes clarity.

Leaving much WHITESPACES are looking better

If you have problems following your own code, you need to refactor/document it

i do have problem thats why post count goes to 21

In an ideal world, methods would be short enough and repetition rare enough that these situations would never arise, but, well, you know the rest.

The content in method is not repeated and operations are different for every event. For one event i have one set of operation and for other i have other.

Azrael Noor wrote:

Jeff Verdegan wrote:In an ideal world, methods would be short enough and repetition rare enough that these situations would never arise, but, well, you know the rest.

The content in method is not repeated and operations are different for every event. For one event i have one set of operation and for other i have other.

In the code you showed with the blocks, it would be better to break each block out into its own method, as somebody did. However, if those blocks were in a more complicated method and there were some common ground across blocks and dependencies among them, to where it could be refactored but would take a lot of time, and you didn't have that time available, then, IMHO, delineating the pieces with those blocks would be a reasonable middle ground.

Azrael Noor . . . Leaving much WHITESPACES are looking better[/b wrote: . . .

Disagree. Leave blank lines before methods, or where there is a logical break in the program. But don’t double-space all your lines.

It is not really

easy to read code

if it is split up by

too much

whitespace.

See here is snippet

Azrael Noor . . . Leaving much WHITESPACES are looking better[/b wrote: . . .

Disagree. Leave blank lines before methods, or where there is a logical break in the program. But don’t double-space all your lines.

It is not really

easy to read code

if it is split up by

too much

whitespace.