This long-awaited feature gives you a possibility to define your own code-folding regions with special line comments.
Let me give a simple example. I start with the following code and select a code region I would like to fold:
enter image description here
I press Ctrl+Alt+T now to get “surround with” action options:
As you can see there are two custom folding items: “<editor-fold..>” for NetBeans-like style and “region..endregion” for VisualStudio style. If you don’t have any custom folding regions yet, you can choose either style. For example, NetBeans-like “<editor-fold..>”:
Now I can collapse the region just like any other code folding region:
The whole code gets hidden behind “My description”, the text I have specified as a value of “desc” attribute.”defaultstate” attribute is supported too but not added automatically.
For VisualStudio-like range comments IntelliJ IDEA adds “//” comment instead of “#” although “#range” is recognized too. In general the IDE uses typical language line comments for any kind of style.
Note that you can not mix up two styles in one file. The IDE will recognize only the first it can find and assume this is a style you have chosen for your code. I guess it’s needless to say that mixing custom region styles in one project is a bad practice. I would like also to stress that using custom folding regions is not a panacea from a badly structured code. Keep your code clean and readable even without any extra folding regions.
Related
Hy, it's not a big issue, but anyway :
All my other coworker code is auto-formated like that :
output = output.update(
par1,
par2
);
mine is autoformated like that:
output = output.update(
par1,
par2
);
more specificaly : the tabulation for their parameters method have 2x 4 space, mine have 1x4 spaces
any idea which how to change this codestyle rules? We use a common formater file, but somehow, I don't have the same things than everyone else.
Edit : It's java code,
I need the name of the rules who manage that
This is almost certainly down to the settings in Intellij's Editor preferences.
Open the settings panel and search for code format or open the Editor > Code Style > Java options.
Code Formatting page
In here you'll options to change pretty much every part of your code layout.
You can also import and export schemes, which can keep things consistent across your company. More information on how to do that can be found on the jetbrains site.
As already indicated, Intellij-IDEA (and all its variants) have a Code Style per language (and even per-project).
The preview on the right side is live-updated, so if you change settings on the left, they will be reflected on the right.
Please note that not all options are available for all languages and it's often a matter of playing a bit with it.
An alternative is that your coworkers can EXPORT the settings they are using and you can import them.
They would export it by tapping the "gear" (?) next to the Scheme:
You can then Import them by using the "import Scheme" option ;)
As I am looking for ways to speed development and usage with IDEA, I am using Intentions (I.e: Alt+Enter by default Keymapping) to auto-insert things like decelerations, constructors, and all that jazz, trying to keep myself well clear of using the mouse when I can.
One thing that does irritate me is with creating constants, fields, and parameters. After generating them, the IDE jumps to the position they are declared, and prompts for name and type. Usually this results in a double-hit of the enter key, however, leaves the cursor at there. Is there a way to jump back to the usage after declaring it through this feature?
Cheers.
Assuming you want a field foo, you can type foo and then immediately use the quick fix intention to create a field foo. Now you can type Alt +F7 ("Find Usages"). This will take you to the usage you just typed (since it is the only one). This assumes you have the "Skip results tab with one usage" option set in "Find Usages Settings (Edit > Find > Find Usages Settings or Ctrl+Alt+Shift+F7). If you do not have that setting configured, the result will open in the Find tool window with the usage highlighted. You can then type F4 (jump to source).
Is it normal that the default behavior for code completion when editing Java is the following?
If I import a package, after typing the first ., any key I press results in the first item in the list being selected
Sometimes while typing keywords like public and protected, NetBeans will make some wild leaps and insert private after just a p or pu are typed!
In general, it tends to make some big guesses in terms of autocompletion, guesses that are not supported by my previous input at all.
I feel like this cannot be the desired behavior for every user. Is there a way to make the code completion not autocomplete anything, or at least make it way less eager?
Edit: To be clear, I do not want to have to disable the sometimes-useful "Autopopup Window." I want the window to eagerly appear with tips and suggestions for methods, syntax, whatnot - I just don't want NetBeans to try to guess what I want, because it is wrong 90 - 100% of the time.
Which version of Netbeans are you using because that doesn't seem to be the behaviour I am seeing in 7.1.
AutoCompletion popups don't appear until I hit Ctrl+Space.
If I type "p" and then hit Ctrl + Space, the popup shows "private", "protected" and "public". I can either keep typing (and the list gets smaller as possible matches are removed) or use the cursors to select the word I want and hit Enter.
If there is only one logical option e.g. I start typing "pu" and then hit Ctrl+Space, then Netbeans inserts "public" automatically (though this can be turned off).
Code templates are a different story, I have them set to be activated using Shift+Space. As far as I know, templates don't show any popups. Anyone who likes pain can consider changing the activation key to just Space :P
I definitely share your complaints, especially re: 1. A quick google search reveals ways to turn off autocomplete:
AutoComplete drives me crazy. I’ve always hated it – I feel like it
slows my computer down and sometimes it even seems to derail me in the
middle of typing something because the window comes up and somehow
snags focus. I turn it off under Options, Editor, General (uncheck
Auto Popup Completion Window).
Item 2) sounds more like the "code template" feature rather than the auto-completion.
If that gets in your way, you have two options:
change the key that "triggers" the code-template expansion (e.g. from "Space" to "Tab"
remove all two-stroke templates (or any other abbreviation that you would rather not have)
Both can be done under "Tools -> Options -> Editor -> Code Templates"
We have 5-10 developers working on Eclipse with Java here in our shop, and we often are debugging classes that don't have debug-friendly toString().
Along comes Detail Formatters to save the day. Hurray! But only my day. If I want to share the joy with my fellow devs, I THINK I have to do some copying and pasting, as do they.
That sucks. We've got N different version control systems that work in Eclipse... it seems like this would be something that folks would Like To Pass Around.
Nothing in the file->export... dialog. Nothing via searching the online help. Nothing.
I managed to track at least some of the settings to /workspace/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.dbug.ui.prefs, but Have Reason To Believe there's more to it than that. Plus, the thought of putting something burried deep in a hidden folder into source control puts my teeth on edge.
Is there a better way to share detail formatters? Ideally this would be something we could just check into our code repo and disseminate that way.
EDIT: I'm using Helios, Service Release 1, build id 20100917-0705.
In addition to the javaLogicalStructures extension point (for adding logical structure to given classes), there's also one called detailPaneFactories. But this is for creating the pane the text (or whatever, thanks to this extension point) the detail formatter renders to. Neither allows extenders to list existing detail formatters (or logical structures for that matter).
The bottom of the detailPaneFactories extension does have Something Interesting To Say:
Supplied Implementation:
The debug platform contributes a detail pane factory providing a default
text source viewer detail pane. The default detail pane displays textual
details of a selected element based on the corresponding debug model
presentation's implementation of computeDetail(IValue value,
IValueDetailListener listener).
computeDetail sounds promising. I'll keep ya posted (unless someone else beats me to it... hurray bounties).
Hmm... org.eclipse.jdt.debug.ui.JavaDebugUtils.getPreferenceStore() sounds promising, but I'd still rather not write a plugin for this myself.
Ah... well. Here's the code org.eclipse.jdt.internal.debug.ui.JavaDetailFormattersManager uses to load them:
/**
* Populate the detail formatters map with data from preferences.
*/
private void populateDetailFormattersMap() {
String[] detailFormattersList= JavaDebugOptionsManager.parseList(JDIDebugUIPlugin.getDefault().getPreferenceStore().getString(IJDIPreferencesConstants.PREF_DETAIL_FORMATTERS_LIST));
fDetailFormattersMap= new HashMap(detailFormattersList.length / 3);
for (int i= 0, length= detailFormattersList.length; i < length;) {
String typeName= detailFormattersList[i++];
String snippet= detailFormattersList[i++].replace('\u0000', ',');
boolean enabled= ! JavaDetailFormattersPreferencePage.DETAIL_FORMATTER_IS_DISABLED.equals(detailFormattersList[i++]);
fDetailFormattersMap.put(typeName, new DetailFormatter(typeName, snippet, enabled));
}
}
So the string in the preference store is just a bunch of CSVs with type-name,snippet,enabled,type-name... replace \u0000 with , in the snippets, and you're good to go.
That handles the export (hell, you could just dump the preference string whole hog).
Import wouldn't be much harder, though it'd be nice to not overwrite existing types, or given the user the option to do so, perhaps even with a diff of the two snippets in question.
OTOH, I'd really rather not rely on the inner workings of a class in *.internal.*.
From the Eclipse 3.8 and 4.2 M5 - New and Noteworthy:
Detail formatters can now be exported as separate preferences.
Previously the only way to share detail formatters was to export all of your workspace settings.
This closes the bug 224815 mentioned by Brian De Alwis in his answer:
"Make Detail formatters exportable" (with that patch)
Although there is nothing explicit in the preferences export wizard, exporting everything will also write the detail formatters. Just search in the output file for /instance/org.eclipse.jdt.debug.ui/org.eclipse.jdt.debug.ui.detail_formatters and share only those lines.
Update: There seems to be a bug in the importer, you have to remove the /instance/ prefix from each line before importing the file.
Alternatively, as they are stored in a properties file in the workspace metadata, you can share that (although you'll probably overwrite other debug settings if you just copy the file):
${workspace}\.metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.jdt.debug.ui.prefs
Using a "macro" might do the trick here.
You will have to
Install a plugin that lets you
record Macros
Start recording Macro and configure Detail formatters using Eclipse Menus
Save and keep that
macro on some shared directory
Install that plugin and run macro on
PCs used by other developers
One such plugin is : http://sourceforge.net/projects/practicalmacro/reviews/
This issue was filed in the Eclipse Bugzilla as bug 224815. The problem is that the detail formatters were overlooked when configuring the import/export preference transfers. The fix, providing it's accepted, should be in the 3.8/4.2 M6 due out at the end of January.
I'm working in a java project where a big part of the code was written with a formatting style that I don't like (and is also non standard), namely all method parameters are in uppercase (and also all local variables).
On IntellJ I am able to use "Analyze -> Inspect Code" and actually find all occurrences of uppercase method parameters (over 1000).
To fix one occurrence I can do "refactor > rename parameter" and it works fine (let's assume there is no overlapping).
Is there a way to automagically doing this refactor (e.g: rename method parameter starting with uppercase to same name starting with lowercase)?
Use a Source Parser
I think what you need to do is use a source code parser like javaparser to do this.
For every java source file, parse it to a CompilationUnit, create a Visitor, probably using ModifierVisitorAdapter as base class, and override (at least) visit(MethodDeclaration, arg). Then write the changed CompilationUnit to a new File and do a diff afterwards.
I would advise against changing the original source file, but creating a shadow file tree may me a good idea (e.g. old file: src/main/java/com/mycompany/MyClass.java, new file src/main/refactored/com/mycompany/MyClass.java, that way you can diff the entire directories).
I'd advise that you think about a few things before you do anything:
If this is a team effort, inform your team.
If this is for an employer, inform your boss.
If this is checked into a version control system, realize that you'll have diffs coming out the wazoo.
If it's not checked into a version control system, check it in.
Take a backup before you make any changes.
See if you have some tests to check before & after behavior hasn't changed.
This is a dangerous refactoring. Be careful.
I am not aware of any direct support for such refactoring out of the box in IDEs. As most IDEs would support name refactoring (which is regularly used). You may need to write some IDE plugin that could browse through source code (AST) and invoke rename refactoring behind the scene for such parameter names matching such format.
I have done a lot of such refactorings on a rather large scale of files, using TextPad or WildPad, and a bunch of reg-ex replace-all. Always worked for me!
I'm confident that if the code is first formatted using an IDE like Eclipse (if it is not properly formatted), and then a reg-ex involving the methods' signature (scope, return-type, name, bracket, arg list, bracket) can be devised, your job will be done in seconds with these tools. You might need more than one replace-all sets of reg-ex.
The only time-taking activity would be to come up with such a set of reg-ex.
Hope this helps!