Is it nice to use separate sections of code inside the same method with curly braces?

Question

I am dropping a few lines of code that fill a specific task with blocks with a small comment above, for example:

public void doSomething(){ // common variables needed by all blocks { // comment for block 1 ... ... about 5 to 30 lines of code ... } { // comment for block 2 ... ... about 5 to 30 lines of code ... } } 

I do this because, in my opinion, it is easy to read, the variables necessary for one block cannot harm another block and because I do not want to create separate methods for the block that will not be needed elsewhere .

Could you say that this is bad practice? Many people I have coded disagree with this coding style. I know that in C # there are areas, but they do not isolate variables.

edit: because everyone offers me to make methods from blocks: Sometimes I do, but I don’t want the class to already have 20+ methods, blocks are not needed by any other method, and the method with all blocks is still small enough.

Answer 1

I don’t think this is bad practice, and I do it too, but I would advise you to break the method into smaller ones. Do you really need a method> 50 lines?

Answer 2

If you can break the code like that, why not just break it down into separate methods? Then change your doSomething() method to just use these smaller methods?

Thus:

• It’s clear that every element of the work is intended to
• Considering the top-level method, it is easy to see the general plan and move on to one specific part.
• You can potentially unit test isolate each small method (although you may need to make it non-private for testing only, no matter how good or not a personal preference, like everything else)

Answer 3

If your methods are so great that you feel you need to organize them, the likelihood that you should break them down into smaller methods. (I speak from experience: I have a terrible habit of writing overly long methods that are quite difficult to maintain. I have to deal with it every day.)

As for bad practice, I would say that this is not in itself, except that it is so unusual that it will tend to throw people into serving your code. They will look for a thing at the beginning of the block - if or while , etc. - and wonder when he is not there. So, in this sense, this is probably not a good practice, since disabling people who support the code is usually not a great idea.

Answer 4

It depends on what the blocks do. If they are used to limit the scope of local variables to something sane, I think this is a good idea. People tend to give variables too broadly, and a clear end to the scope of the variable helps when debugging or viewing code.

Having said that if the code in the sections is long and the number of variables that it shares with other sections is small, then perhaps this is a good idea for refactoring.

Answer 5

It's good. You should be free to do this, since isolating variables are good practice. You can read these locked blocks as idiosyncratic anonymous functions in place, which is sometimes useful to keep the code visually grouped together, although, of course, every time you do this, you should ask yourself: "Should I really to make this a separate function? "as suggested by other posts here.

Another useful thing that can be achieved, especially if you are using a code editor that automatically formats blocks, is indentation of important and special sections of the code that would not otherwise indent. eg:.

 glBegin(GL_TRIANGLES); { glVertex3f( 0.0f, 1.0f, 0.0f); glVertex3f(-1.0f,-1.0f, 0.0f); glVertex3f( 1.0f,-1.0f, 0.0f); }; glEnd(); 

Answer 6

Your coding style is rather unusual, and I'm not sure that everyone will find it very easy to read. The composition of the brackets makes the code less readable, so you should omit them whenever possible. For instance. instead

 if(n == 1) { i++; } 

just write:

 if(n == 1) i++; 

Areas introduced only to separate different functional blocks within the same function also do not sound right - it would be much more natural to extract them into separate functions. One of the biggest advantages would be that you could test them a lot easier and test them separately. This would make doSomething() shorter, which again follows good coding practice while keeping functions short .

Your comments written for areas within a function cannot appear in automatically generated documents. If you use individual functions and apply these comments to them (provided that they follow the syntax of this automatic document creation tool such as Doxygen), they will appear in the documentation.