"Remove braces from if-statement" intention

How to get rid of this intention? In contrast with other intentions (e.g.
create method), it is instantly available and sometimes I click it, because
the create method intention is not yet available. All my code blocks are
wrapped in curly braces and I never would use that intention.

Tom

47 comments

+100

BTW is there anyone who find this pair of intentions useful?

-


Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0

Maxim Shafirov (JetBrains) wrote:
> BTW is there anyone who find this pair of intentions useful?

I sometimes use the "add braces" intention. I would like to instead reformat the code completely, but since 5.0 we refrain from doing that because formatting still 'uglifies' a lot
of code.

0

The Add and Remove braces intentions are quite annoying indeed. I'm
ashamed to have implemented them:-)

Possible solutions Poll:

1. Make triggering them more restrictive (only on the keyword, like
other control statement intentions).

2. Remove them completely (to add braces there would still be the
"Control Statement without Braces" inspection).

3. Only remove the "Remove Braces" intention.

Cast your votes please.

Bas

0

2. Remove them completely (to add braces there would still be the
"Control Statement without Braces" inspection).


+1, isn't there a layout code option to add the braces?

Tom

0

+100

BTW is there anyone who find this pair of intentions
useful?


I do. Funny, I've never triggered them accidentally. More often then not, I have trouble using it, since it's only triggered on a very specific location (the first non-blank character of the first line inside the if statement).

0

Bas Leijdekkers wrote:

1. Make triggering them more restrictive (only on the keyword, like
other control statement intentions).


Remove Braces, if not removed completely, yes.
Add Braces should stay as it is - I use it quite often but definitely not when
the caret is located on the keyword.

2. Remove them completely (to add braces there would still be the
"Control Statement without Braces" inspection).


An inspection is IMHO too heavy, at least as long there aren't new highlighting
categories except error and warning (style issue, etc.) available.

3. Only remove the "Remove Braces" intention.


This one is IMHO indeed useless.

Sascha

0

>> 3. Only remove the "Remove Braces" intention.


This one is IMHO indeed useless.


Do you mean the intention or the option to remove the intention?

Tom

0

Tom wrote:
>>> 3. Only remove the "Remove Braces" intention.
>>
>> This one is IMHO indeed useless.


Do you mean the intention or the option to remove the intention?


The intention of course ;) At least I never use it.

Sascha

0

Bas Leijdekkers wrote:

The Add and Remove braces intentions are quite annoying indeed. I'm
ashamed to have implemented them:-)

Possible solutions Poll:

1. Make triggering them more restrictive (only on the keyword, like
other control statement intentions).

2. Remove them completely (to add braces there would still be the
"Control Statement without Braces" inspection).

3. Only remove the "Remove Braces" intention.

Cast your votes please.

Bas

Does anybody besides Bas and Dave know all the intentions?
I must have worked my way through the list of all inspections at least four times in the last year or so.
Still I somehow missed (or no longer remembered?) the "Control Statement without Braces" inspection.

The inspection is enough for me.
I do not need additional intentions.

0

Bas Leijdekkers wrote:

The Add and Remove braces intentions are quite annoying indeed. I'm
ashamed to have implemented them:-)


I would never use the remove braces intention either.

I think that the add braces intention should remain because I often use it when I am working
on someone else's code if they did not follow the same code style as I do.

Perhaps the add should be made available depending on the user's selection in the applicable
code style configuration for the current statement.

For example: If under "Force Braces" I select "Always" for "if()", but "Do not force" for
"while ()" then I should not get the remove intention for an if statement but I should for
a while statement. If I select "When multiline" for "for ()" then I should get the remove
intention if there is only a single line inside the braces of a for loop.

0

Does anybody besides Bas and Dave know all the intentions?

Part of the purpose of the intentions is to surprise and delight with their unexpected and hidden power. You may only need "Convert If to Switch" once a year, but when you do, if you think to click on the "if", there it is.

I'm in favor of doing both 1) and 3).

--Dave Griffith

0

But this does not necessarily mean, that it is useful. ;)

Tom

0

....although the M5 feature list looks amazing, especially since Java centric
features continuesly get improved.

Tom

0

Eh. Except for the refactoring scripts and the "Introduce Indirection" refactoring, I don't see anything IDEA hasn't had for at least a year.

--Dave Griffith

0

Yes, but the Eclipse people are trying to improve their Java stuff to catch
up with IDEA.

Tom

0

Do you mean we don't improve Java-centric features in IDEA? You must be joking:)

0

I get impression that IDEA is not aimed at being "coder's IDE" anymore. If you look at major 5.0 features at http://www.jetbrains.com/idea/upgrade/top_reasons.html the focus is obviously not on improving actual experience of writing code. There are new inspections and intentions, and 3 new refactorings. Meanwhile there are dozens of refactorings, editor improvements, refactoring improvements, etc. which have sat in tracker/jira for years. Demetra's plan shows some cool "coder"-style features, like improved Extract Method, but it's mostly focused on bigger features like team support and UI designer.

I don't think Eclipse is better in this regard, but I think you shouldn't be surprised if people have such opinions.

0

OK, I see your points. Most of the hype nowadays in IDEA community is indeed made by other features. But still when getting things into perspective, I don't think we innovate in coding features less than we used to. It is just that not all of the features implemented are seen from the first launch of IDEA. And yes, I think it is inevitable for such a mature product as IDEA is. Also let me assure you that the developer force doing coding features has not gone, and we are constantly seeking for new features worth to be included into core IDEA. As for the ones we don't implement, there are always plugins that are ready to correct us in case we are lazy in doing things:)

0

I don't think Eclipse is better in this regard, but I think you shouldn't be surprised if people have such opinions.

"better" is certainly an unsupportable description. At present rate, Eclipse would have about eighteen months worth of work to do to even meet IDEA in refactoring. OTOH, today does mark the first day that a refactoring ("Introduce Indirection") is available in another product and not available in IDEA. Can't be a great day in Prague...

--Dave Griffith

0

Yes, I imagine there is smaller market for editor improvements, especially when even JB marketing team admits (in Maximizing Stability whitepaper) that it's hard to describe why IDEA is cooler than other IDE's, due to so many small enhancements and lack of big features (JSF, hibernate gui, etc).

I agree that plugins could implement lots of these things. However, most improvements I'd like to make to idea involve improving existing functionality in ways not accessible to openapi or even closed api. For example I tried to make nullable/notnull plugin as undergraduate research project, and lack of global inspections API / localinspectiontool context information, combined with bugs in degenerator, crippled the project. I think until IDEA opens source code (under ANY license, I don't care if it's OSI-certified), plugins will not be able to make many of these improvements.

0

I didn't mean better java features, I meant better rate of change with regard to java features.

Although introduce indirection could be easily implemented as SSR, although I'm not sure if it could be done perfectly (I don't think SSR supports specifying full method signature). I think more surprising is lack of refactoring log/replay in IDEA. I didn't expect Eclipse to have this first. I think that if implemented right, and integrated into VCS right, it would be huge. I'm surprised it's not listed for demetra as part of team collaborative support.

0

... there are dozens of refactorings, editor improvements, refactoring
improvements, etc. which have sat in tracker/jira for years.


Yes, this also is my feeling since at least 5.0. There is so much room
to still improve refactorings and other already existing features, but it
looks like Jetbrains rather prefer to keep existing features mostly as they
are and add new stuff, which only is needed by a smaller part of their
users, but looks better on a feature list. Maybe it is harder to sell
improved existing features than new ones?

I don't think Eclipse is better in this regard


Agree, Eclipse still is not that good as IDEA regarding Java centric stuff.
But they are working hard to catch up and if they keep their speed, there
will come a point, where Eclipse will be better than IDEA.

Tom

0

I want to emphasize: I'd rather prefer to use IDEA - esp. because having
another competitor in the IDEA market is better than only having Eclipse
(sorry, Netbeans is too far a way).

If Jetbrains is focussing too much on features I don't need and does not
add/improve features which I need, maybe there will become a time, when
using Eclipse might be a better choice.

Tom

0

I think until IDEA opens source
code (under ANY license, I don't care if it's
OSI-certified), plugins will not be able to make many
of these improvements.


That's one bold statement, Keith. I'm a big fan of open source, and while I do believe that there is possible for a business to thrive on it, I wouldn't go as far as saying this is the only way for JetBrains.

I'm quite happy with the way things are progressing, actually. We have OpenAPI, which has limitations and problems, which are implemented/fixed once we bring them to JetBrains attention. Granted, an open source model would allow more people to work on these limitations, eventually leading to a faster rate of development, but how much would it hurt JetBrain's revenue?

Larger companies have no reason NOT to pay JetBrains, even if the product source was freely available, but the picture is somewhat different for indidivual freelancers, like me.

0

them to JetBrains attention. Granted, an open source
model would allow more people to work on these
limitations, eventually leading to a faster rate of
development, but how much would it hurt JetBrain's
revenue?


I don't see how it would do anything but help JB revenue. I'm not asking JB to change their pricing model. I'm asking for the source, as a paying customer.

0

First as a paying customer you pay for the binary version of the product named IntelliJ IDEA. Second, following your reasoning I don't see why Eclipse with sources open is not still times better than IDEA?

0

First as a paying customer you pay for the binary
version of the product named IntelliJ IDEA.


I don't know what you're saying. What you said is true.

Second,
following your reasoning I don't see why Eclipse with
sources open is not still times better than IDEA?


I think it's because IBM developers have worse vision and talent than JB, and because they are building entire platform, not IDE, so IDE gets shafted.

0

Keith Lea wrote:

I think until IDEA opens source code (under ANY license, I don't care
if it's OSI-certified), plugins will not be able to make many of
these improvements.


I should warn you, saying something like that in this forum is opening a
huge can of worms.

I fully agree with you though.
IDEA would be so much better if the customers could edit the source,
contribute patches, and so on.

Kreiger



Attachment(s):
signature.asc
0

Please sign in to leave a comment.