Code writing rules

Java

You should already know project structure and used libraries !! If not, please read Project structure.

• Each module usually have some specific code/functions structure. Refer to Perun modules page (TODO).
• OOP in Java (czech at kore.fi.muni.cz)
• every new method must contain JavaDoc
• JavaDoc for every class must contain @author property
• And we do code as people...

JavaDoc

You can generate it with maven by mvn javadoc:javadoc. Header of all .java files must look like this:

/**
 * JavaDoc commentary
 *
 * @author Your Name <your email>
 * @version $Id: $
 */

Interfaces must have all their methods documented. For interface implementation you can use {@inheritDoc}, which will reuse JavaDoc from interface. If no additional comment is necessary, you don't have to write it, it's reused from interface automatically.

/**
 * More text...
 * {@inheritDoc}
 * More text...
*/

Logging

Logging in methods changing data should at the end log via log.info(), e.g. Java log.info("Member {} created", member);. At least in perun-core messages for such stuff can't be random. Please read Audit messages part on Technical reference page.

• toString() output should be between []
• toString() on PerunBeans looks like: Name:[parameter='property', parameter='property']

Tests

Unit tests are suppose to be written by code author, before or right after actual coding. You can used jUnit, Mockito and PowerMock in your tests. For integration tests, we use SpringTestContext. All tests must clean up after finish (do not commit DB transactions).

PERL

Just because you CAN do something a particular way doesn’t mean that you SHOULD do it that way.

• Use own global variables with caution (key word our).
• Small scripts, OK
• Bigger scripts, only when it doesn't hurt code readability.
• For defined global variables (e.g. formatting ones $, $",...) always use local.
• Brackets for function calls are not necessary, if it doesn't hurt code readability.
• Always use use strict, use warning
• If necessary, you can disable it for part! of code via no warnings or no strict - better with modificator for problematic area, e.g. no strict "vars".
• Code commenting - the more, the better.
• For each function we comment input, output a how does it modify global variables (if used)
• For complicated parts of code - do not leave out ->
• man perlstyle ;-)