Community
Participate
Working Groups
For code like: if (a < b.getValue()) value = a; else value = -1; The clean-up action is a great way to ensure that consistent formatting is used across a development team. Unfortunately, the setting also results in: if (a < b) if (a==0) result = a + b else for (int i=0;i<b;i++) result += array[i]; It should be possible to configure the preference to ignore these more complex statements, and leave the use of blocks as-is. This function should only edit your code when it is really sure what you want. The current heuristics don't provide this. There is a setting called: "No blocks for single return and throws". Maybe this could be broadened slightly to include method calls or assignments. But then, what does that setting mean? Does it mean everything else gets blocks added? Or everything else gets left as-is?
Sorry, I'm not entirely sure what you want. Do you want this: if (a < b) { if (a==0) { foo(); } else { for (int i=0;i<b;i++) { result += array[i]; } } } become that: if (a < b) { if (a==0) foo(); else { for (int i=0;i<b;i++) result += array[i]; } } 'No blocks for single assignments or method calls' > Does it mean everything else gets blocks added? Or > everything else gets left as-is? Depends on the context, if everything else has blocks then everything else is left as-is, otherwise blocks are added to everything else. Think about it like this: Clean Up takes your code, whatever it looks like, and change it such that every control statement body has a block except single return or throw statements. IMHO the Preview and also the checkbox 'Use blocks in if/while/for/do statements' make this clear.
> Sorry, I'm not entirely sure what you want. Do you want this: ... > become that: > > if (a < b) { > if (a==0) > foo(); > else { > for (int i=0;i<b;i++) > result += array[i]; > } > } Correct. Blocks around "simple statements" were removed, while blocks around the other statements were neither added nor removed. If the else statement weren't a block, it would have been left that way. Probably I never want blocks added anywhere, and I would like finer control over when blocks are removed. The current options are: return/throws := YES|NO a statement := YES|NO I'm asking for: return/throws := YES|IGNORE|NO simple statement := YES|IGNORE|NO compound statement := YES|IGNORE|NO
Something like (with the options enabled to generate the result you want): Either: [X] Use blocks in if/while/for/do statements ( ) Add blocks around [ ] Single 'return' or 'throw' statements [ ] Single assignments or method calls [ ] Other single statements (.) Remove blocks around [ ] Single 'return' or 'throw' statements [X] Single assignments or method calls [ ] Other single statements Or (more power full): [X] Use blocks in if/while/for/do statements [ ] Single 'return' or 'throw' statements (.) Add blocks ( ) Remove blocks [X] Single assignments or method calls ( ) Add blocks (.) Remove blocks [ ] Other single statements (.) Add blocks ( ) Remove blocks Would that work for you?
I don't like the two suggestions. Having 'Add' and 'Remove' under 'Use' is strange. So is now 'use' block or not?
(In reply to comment #4) > I don't like the two suggestions. > Having 'Add' and 'Remove' under 'Use' is strange. So is now 'use' block or not? > I like the second one:-) It gives us the ability to grow, and it is IMHO easier to understand as what we have now. But 'Use' is not good, I agree. What about: [ ] Add/Remove blocks in if/while/for/do statements [ ] Blocks in if/while/for/do statements [ ] Change blocks in if/while/for/do statements ...
I think removing blocks is the primary use case, since multi-statement blocks require the use of blocks by definition. So: [X] Apply Rules for Blocks in if/else/for/while/do statements [X] 'return' or 'throw' statements (.) Not Allowed ( ) Required ( ) [X] Assignments or method calls (.) Not Allowed ( ) Required [ ] All others (includes nested if/for/while/try/etc.) (/) Not Allowed (/) Required It would be strange if the top-most checkbox were checked, but none of the 3 nested rulers were enabled.
(In reply to comment #4) > I don't like the two suggestions. > Having 'Add' and 'Remove' under 'Use' is strange. So is now 'use' block or not? Agreed, calling this setting "Use blocks" when it actually determined when *not* to use blocks was misleading. See wording in the proposal above.
> [X] Apply Rules for Blocks in if/else/for/while/do statements better yet.. [X] Apply Block Rules for single statements in ...
*** Bug 203699 has been marked as a duplicate of this bug. ***
We need to be careful that we do not add too many options. We can not make everyone happy, if we try we end up with something like the code formatter options.
All that's being proposed here is to not make the use of braces black and white, and to add a new class of statement to handle the scenario in the original description. BTW, SWT recently added support for tri-state checkboxes, so this will be much less complex from a UI point-of-view.
