Coding Style Guide for Grails Application Development

Here are the guidelines and coding style recommendations for your Grails application:

  • Method Modifiers:

    • Use protected, private and final modifiers for methods in a controller that are not actions.

  • Coding Style:

    • Prioritize concise code, while maintaining clarity.

    • Employ the @GrailsCompileStatic or @CompileStatic annotations throughout the codebase.

  • Stateless Actions:

    • Always design actions to be stateless and avoid using sessions.

  • Controller Traits:

    • Refrain from using services to implement Controller traits.

  • @Transactional Annotation:

    • Reserve the @Transactional annotation solely for controller actions.

  • General Rules:

    • Use the final modifier when appropriate.

    • Adhere to the DRY (Don’t Repeat Yourself) principle.

    • Keep the scope of symbols short to enhance code readability.

    • Opt for concise and meaningful local variable names.

    • Clearly specify public method parameters and member names.

By following these guidelines, you can maintain a clean, organized, and expressive codebase for your Grails application.


  • Do not centralize i18n, use gradle app module i18n folders

class Book {
    String title
  • class name localisation "book.label = Libro"

  • class field name localisation "book.title.label = Título del libro"

  • To be efficient

    • do not translate too early

    • when you have a global overview, start translating

    • keep the most important label short, use the default namespace for them, specialized label can be long

  • Use convention for your i18n:

    • prefix with "default." everything that will be reused

    • do not prefix class name translated

    • for labels, prefix with "label."

    • for actions, prefix with "action."

We separate within an app module domains i18n, from actions and other i18n.

Common i18n should be localized into Crew app module.


  • Use enum, in code, for configuration

    • Static is king

    • Groovy Enums are readable (more than XML, Json, Yaml …​ whatever)


  • Security-related code should be located near the point of influence

    • We do want to avoid centralization for all concerns

      • Create a new domain per needs, avoid cluttering User class

      • Abstract concepts should be minimized for security purposes; static checks are crucial

  • Avoid complex rules that can’t be verified statically during compilation

  • Administrative rules must not rely on permission strings, a boolean value in an object is more explicit when testing in code.

You are efficient when:

  • Modifications if a functionality is localised in the source code

  • Incorporating new features is straightforward

  • Different concerns remain isolated or orthogonal, minimizing mutual influence.