Is there's a way in NetBeans to remove unnecessary braces in one-line statements?
I would like to convert something like this:
if (something) {
doSomething();
}
to
if (something) doSomething();
I do this manually all the time, but sometimes I have to format the code for some other reasons using alt+shift+f command and netbeans adds those braces again.
If is not possible, Is there a way to tell the formatter not to add those braces when I press the alt+shift+f command? I know Eclipse do this, and I would like to know if Netbeans can.
I have read this and this answers, and apparently it can't be done, but both are php oriented; this apply to java too?
I'm using Netbeans 8.0. If you don't have the exact same version, hopefully you'll find that the following steps are similar enough to make it work for you.
Go to Tools --> Options.
Click on the top Editor button.
Go to Formatting tab.
Make sure the Language combo box has Java selected.
Modify the value of the Category combo box to Braces.
Under Braces Generation, change the value for if: to Eliminate.
After you apply these changes, formatting the code will correctly remove the braces for single line statements, and leave them for multi line statements.
You can do the same for other keywords like for or while if you want.
EDIT
Since a few heated comments were made on the question itself about the validity of such a request, I'd like to make a comment of my own on the topic of the practice of coding if-else statements without braces.
I personally always use braces, even if it means typing a little more, and wasting a little more screen space. As already mentioned, it is so much safer to do so. The clarity to the code it provides far outweighs any cosmetic benefits.
That said, I respect that it is still a matter of personal preference, especially if you are the only one maintaining the code. Also, if you have the good habit of auto-formatting your code, then that will minimize any risks associated with misinterpreting the blocks of codes without braces, because the auto-formatter will indent the code appropriately.
But if you work in a team environment, I think it would be very considerate on your part to consider leaving the braces in.
Possible workaround:
You can use the formatter on just certain sections of the code. Highlight just the function you want format.
Related
Sometimes IntelliJ will take single statement methods and put them on the same line, as seen here:
If I click either bracket it will turn back into:
This question isn't a debate for which of the two is better - I want to know how to turn this off. I combed through IntelliJ preferences and couldn't seem to find anything, and searching both here and Google didn't bring up what I wanted.
I think these options are responsible for this:
If you're talking about code reformatting putting the extra newlines into your code, then it's the "Simple methods in one line" option you want to check in Editor/Code Style/Scala/Wrapping and Braces:
When refactoring code (e.g.: Refactor -> Rename), IntelliJ IDEA 14.x also rewraps (reformats) my code to fit into the 80 column limit.
Example: here's the code before the refactoring:
Refactoring in progress:
... and the code is re-wrapped once I press Enter:
What's most annoying about that, even Java classes which aren't currently open in the editor (but are affected by the refactoring) are reformatted, increasing the chance that formatting changes get propagated into my VCS unnoticed.
What I want to achieve is:
keep the original print margin at 80 columns, but still
have IDEA preserve my original formatting when renaming variables/classes/methods.
How do I achieve this?
Since I don't use any automatic formatting and mostly wrap my long lines manually, I figured out another solution.
Under "File -> Settings -> Editor -> Code Style -> Java -> Wrapping and Braces", I've disabled automatic wrapping entirely (i.e. set everything to "Do not wrap" where appropriate, except for class, method and field annotations, which are set to "Wrap always" by default).
The downside of this approach is that now IDEA sometimes unwraps long lines during refactoring, but those are easier to spot.
If you are doing an actual "Refactoring -> Rename", for example with SHIFT + F6 you are editing every file that has a reference to that variable name whether or not they are currently open in the editor is irrelevant if you change something all the files that are affected are edited and any VCS will consider them changed.
The behavior of reformatting the entire file on refactoring is been in Idea a long time and all bugs that have been filed against that behavior have been setting in an unassigned state forever. Here is one example.
I doubt that this behavior is going to change, I for one hope it does not.
If you want ridiculously long variable names then you need to either turn off the right margin or make it ridiculously long as well. Or change whatever configuration is causing things to be formatted differently.
Personally I set all the relevant things to ALWAYS whatever so I do not have somethings formatted one way and somethings formatted a different way. Consistency is more important than anything else in a large code base.
The VCS tools in Idea are extremely powerful and unmatched in any other IDE. You can easily see what has changed and exclude them from any commits or fix them up how you want.
Idea has a format on commit checkbox for all the various version control systems it supports as well.
So this is for an assignment (which I've already completed), I just left this part out because it seemed like a pain in the ass while I was working on the pattern logic.
The assignment asks that you print this menu graphic to help the user decide which pattern to pick. Is there an easy way to do it or do I just need to get a ton of printf/println statements in there? Seems like a very awkward thing to code. Here's an example:
EDIT: This is just for the graphical menu. I know I have to use loops for the actual patterns (which I've already done). The assignment is essentially finished, just missing this menu. I wasn't sure how best to print out this graphic horizontally without awkwardly formatting it by hand.
Text UI has been implemented so many times. Instead of spending some time trying to develop yet another text-based selection/navigation components try to use available solutions:
Fully featured text UI -- Lanterna
Shell-like approach -- JLine
There is another interesting answer, which provides two other, but not so good options.
I think it depends on whether you're going to be assessed on it.
My engineering head tells me that if you're not going to be assessed on it, getting the formatting correct is going to be fiddly and I would just reduce it down to 5 or so println()s, the implementation of which is nothing more than typing.
There's nothing to be ashamed of in such circumstances by choosing what appears to be a trivial exercise. Of course if part 2 of your assessment asks you to extend this to 6 lines (or similar) then a more extensible solution would be appropriate.
I note (following your edit) that you have pattern methods to generate the above. In that case you may wish to modify their inputs/outputs appropriately to facilitate the above. e.g. perhaps they could take in an array of 'n' lines, and append the pattern to those lines, line by line. You'd also need some justification method to pad those lines for the next pattern generator.
I aggressively use Eclipse formatter and clean-up for all my code. Every time I save my source, all my code is formatted nicely, indentation fixed, braces put in correct places and removed where unnecessary, imports are organized, variables declared final where they should be, and other fine little things happen.
It's very comfortable to user, but I'm just curious – are there any drawbacks? May be bad habits that I'll acquire unknowingly?
Reformatting can play havoc with diffs in version control.
If there are multiple developers then make sure formatting is done to a common standard. Agree on a standard, export the formatting rules from Eclipse and put the formatting rules into source control somewhere. Get all devs to check out the rules and apply them.
Better still, use a version control hook to automatically format all source to the standard rules as part of the commit. This way *you will never have to use Ctrl-Shift-f again!
In general, no, the default rules work well. Are you using default values? Are you the lone developer or walking into an existing team / project?
The format and cleanup rules can be altered, tailored, and saved right alongside your source code. In essence, what my format button does may not be the same as what your format button does if either of us moved from the default rules.
The only problem I've seen is on mutil-member teams, if you do not share the same formatting rules, the formatting can result in difficulty comparing changes before check-in. So, for example, if you have a clean check-out then make a small change to ten files then use the synchronize view to compare your changes before check-in, all the spacing changes can obstruct the actual changes you have made. This can, for example, make a code review more difficult.
I want to change the type of a variable from String to int, can we use Eclipse to refactor?
There's no out of the box refactoring tool that does it as far as I know. The reason probably is that strictly speaking this isn't refactoring: refactoring is a change that doesn't affect the behaviour of the code, but this change definitely does.
Unless you're using reflection, the easiest way to make this change is to change the field first, then watch the bits that turn red, and work your way through them. (You'll get a cascade of errors, pieces that you fix will cause other pieces to go wrong, but eventually you'll get o the end of it.)
I know this isn't really the answer you wanted but if you follow this pattern (deliberately break the code first, then correct errors that arise), it doesn't take long.
If you do have reflection in your code though, then you have no other option than to go through every single file that uses reflection and check whether it would be affected by your change.