Coding Conventions

This small JCrypTool coding conventions guide is a must read for any JCrypTool developer (Core and Crypto). We do not have many rules and conventions, making our documented ones even more important to follow. Any JCrypTool plug-in will be incomplete as long as there are violations against our coding conventions.

Code Quality

We have three required plug-ins that ensure code quality: Checkstyle, FindBugs and Eclipse ResourceBundle Editor. You are required to use these plug-ins and configure Checkstyle to use the JCrypTool Checkstyle configuration. Plug-in information including setup instructions are available here.

Take these warnings seriously! We are thankful for every donated plug-in, but no developer wants to take over support for a crypto plug-in containing classes with thousands of lines all located in the constructor or one method. Clean Code is what we are looking for (read http://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 by Robert C. Martin in case you have never heard about that).

And format your code with the JCrypTool code formatter before pushing it.

Deprecation Warnings

Don't use any deprecated classes or methods. There are always replacements for these classes, and generally these replacements are highlighted in Javadoc. Using

@SuppressWarnings("deprecation")

in your code is just wrong.

Language

We are an international project, all code (classes, methods, variables and so on) and all Javadoc have to be written in English.

Check your Build Configuration

Other than classes new files like images or HTML help files are not automatically included in the plug-in build. In other words: These files will not be available at runtime as long as you don't configure to add them. Open the plug-in's build.properties file and select all files required during runtime.