Generic Code Formatting with EditorConfig example

Posted on June 23, 2016 by Willem Cheizoo

I love code. I take care of my code and I like my code to be formatted nicely. No matter if I’m on Eclipse, Netbeans or IntelliJ, I want my code to be formatted the same.

Nowadays we have EditorConfig. In the source code we can place a file .editorconfig with formatting instructions. These instructions can be read by many Tools like Eclipse, Netbeans, IntelliJ and VisualStudio. If we create an .editorconfig file with formatting instructions, these rules are automatically applied.

Example

An example of an .editorconfig file looks like:

# http://editorconfig.org
root = true

[*]
indent_style = space
indent_size = 2
continuation_indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.{gradle,groovy,java}]
indent_size = 4
continuation_indent_size = 4

# http://editorconfig.org

root = true

[*]

indent_style = space

indent_size = 2

continuation_indent_size = 2

end_of_line = lf

charset = utf-8

trim_trailing_whitespace = true

insert_final_newline = true

[*.{gradle,groovy,java}]

indent_size = 4

continuation_indent_size = 4

As you see you can define specific formatting rules for different file types.

Happy coding and formatting!

Gradle Goodness: Source Sets As IntelliJ IDEA Modules

Posted on March 21, 2016 by mrhaki

IntelliJ IDEA 2016.1 introduced better support for Gradle source sets. Each source set in our project becomes a module in the IntelliJ IDEA project. And each module has it’s own dependencies, also between source sets. For example if we simply apply the java plugin in our project we already get two source sets: main and test. For compiling the test sources there is a dependency to the main source set. IntelliJ now knows how to handle this.

Continue reading →

Groovy Goodness: Turn Method Parameters Into Named Map Arguments With IntelliJ IDEA

Posted on October 2, 2015 by mrhaki

A very useful feature in Groovy is the use of named arguments. Instead of a list of arguments for a method or constructor we can use a Map argument. If the argument is the first in the list of arguments then Groovy allows use to use named arguments when we invoke the method or constructor. This means all key/value arguments are gathered together and assigned to the Map argument. Inside our method or constructor we can then access the Map argument and get the values for the keys. This leads to better readable code and that is very useful. IntelliJ IDEA has a Groovy intention to turn method parameters into a Map parameter for named arguments with a few mouse clicks.

Continue reading →

Groovy Goodness: Turn Map Into Class With IntelliJ IDEA

Posted on October 1, 2015 by mrhaki

IntelliJ IDEA has very good Groovy support. It also provides some intentions especially for the Groovy language. For example we can turn a map definition into a Groovy class definition with a few simple clicks.

Continue reading →

Groovy Goodness: IntelliJ IDEA Intentions For String Values

Posted on September 22, 2015 by mrhaki

The best IDE to use when developing Groovy code is IntelliJ IDEA. The Groovy plugin has some nice intentions for us that we can use to optimise and refactor our code. We will look at some of the intentions that deal with String values in this blog post. The intentions shown here work in the free Community Edition as well in the paid Ultimate Edition. To see the possible intentions in IDEA we must select the Show Intentions Action. We need to check our shortcut keys to see the assigned shortcut. On my Mac it is for example Alt+Enter. Alternatively we can press the Shift key twice and type in Show intentions. IDEA will show the action with the shortcut key for us.

Continue reading →

Grails Goodness: Debugging App in Forked Mode

Posted on December 17, 2013 by mrhaki

Since Grails 2.2 by default the run-app command will launch the Grails application in a separate Java Virtual Machine. This is called forked Tomcat execution in Grails. This way the class path of the Grails build system and the application will not intervene and also both processes will have their own memory settings. We can see the settings in grails-app/conf/BuildConfig.groovy where we find the configuration property grails.project.fork.run. When we want to debug our application in an IDE like IntelliJ IDEA we cannot use the Debug command, because this will only allow us to debug the Grails build system. We will not reach breakpoints in our source code. But Grails 2.3 introduces an extra argument for the run-app command: --debug-fork. If we use this extra argument the JVM running the Grails application will stop and listen for a debug session to be attached and then continue. We can configure a Debug configuration in IntelliJ IDEA (or another IDE) to attach to the waiting Grails application and use breakpoints and other debugging tools like we are used to.

Continue reading →