Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »

Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 1 rates

General Style

Order of methods

We aim for best readability - that's we (from now on) put methods is a specific order:

  • technical/config methods first (e.g. getters, setters, add-methods for collections, ...) - business methods last
  • methods that logically belong together should be grouped (e.g. if there's 2 constructors they should be placed next to each other)

Imports

  • We use the following order
    • static imports
    • all "other" (e.g. info.*) 
    • java, javax, org, com
  • .* Imports are only allowed for static ones (checked by our checkstyle setting)
    • configure your IDE to use 2 as Number of static imports needed for .* (e.g. in Eclipse Preferences -> Java -> Codestyle -> Organize Imports)

Indentation

  • Tab policy: spaces only (warning)
  • Indentation: 4 spaces for Java-Files, 2 spaces for XML
  • No maximum line width, no automated line wrap

Naming

  • We preferably don't use abbreviations in classnames (only exception to that rule is MgnlSomething)

If-statements

  • Single-line if-statements: we always use curly braces
  • Unnecessary else-branch: if the else is not necessary (e.g. because if-branch always returns or throws an exception) we omit it

Overrides

  • for optimal refactoring support we use the @Override for all methods that override methods declared in superclasses/implemented interfaces
    • Hint: you might want to adapt compiler settings of your IDE to show Errors on missing @Override's (Eclipse and Idea provide that option)

serialVersionUID's

We don't explicitly set serialVersionUID's as we don't want to decide ourselves when these id's should be updated. We rely on the JVM doing that for us (being aware that this id's could potentially differ from JVM to JVM). If for any (valid) reason, such an id would be needed for a given class, the reason needs to be documented in the code. Failing that, there's a good chance the field will be removed by a fellow zealous developer.

$NON-NLS-1$

  • if you come across a //$NON-NLS-1$ please just delete it - that's legacy stuff created by Eclipse - we don't want to keep that!

TODOs & FIXMEs

  • these are used for minor issues or hints. As it might be handy to ask the author for details and we don't want to spend too much time on querying the SCM, it's now mandatory to add the author's name:
    • e.g. TODO dlipp - tell the world we'll now always add authors to the TODOs and FIXMEs

Eclipse users

An epf (Eclipse Preferences File) has been created and is available both as an attachment to this page and on our fileserver at /Product Development/Eclipse/Magnolia.epf (access restricted to Magnolia International devs only). This file needs to be imported into your Eclipse IDE and will automatically set the formatting options as specified above.

Go to File -> Import -> General -> Preferences

Make sure you Import all not only the Java Code Style Preferences.

The settings provided will only overwrite the following and should not interfere with other default or custom settings

  • Java -> Code Style -> Formatter ("Magnolia" profile based on Eclipse-provided Java code conventions profile)
  • XML -> XML Files -> Editor
  • Java -> Editor -> Save Actions
  • Java -> Code Style -> Organize imports

Alternatively, if you have access to our fileserver a zipped Eclipse Indigo bundle with the Magnolia.epf already set can be downloaded from /Product Development/Eclipse/ folder. 

By default, this profile will automatically apply code formatting and imports re-ordering upon saving. You can also apply formatting and imports ordering manually by selecting a file or group of files, then  right-click -> Source -> Clean up...

Make sure the active profile is Magnolia and NOT Eclipse [built-in]

 


  • No labels