The sources affected by this commit have drifted in style since earlier
polishing commits such as f34d1f4 and a155518. The shared IDEA style
configuration file can help avoid this drift in the future. Simply run
Code->Reformat Code at the project level prior to committing. Note that
this code style configuration is not perfect, and not every change it
makes should be checked in. The ideal is to simply always write code that
conforms to the style conventions, but the automated settings are there
as a helping hand when necessary.
The churn caused by drifting style and the commits that fix it damage the
utility of git over time. Reviewing changes, analyzing history, surgically
reverting commits, and many other use cases with git simply do not work as
well when styles get mixed and fixed. Let's work toward a common style.
The affected sources have drifted from import organization conventions
since the shared IDEA configuration was added in commit a155518. There
are several ways to avoid this in the future:
1. Run Code->Optimize Imports manually prior to making any commit (or
use the shortcut key).
2. Select 'Optimize Imports on the Fly' from
Preferences->Editor->General->Auto Import.
If IDEA is not being used, simply follow convention.
Trailing whitespace has crept into the sources affected by this commit
since the original stripping in commit e5fcf5b. Editors and IDEs should
be configured to strip trailing whitespace on save, or in any case
trailing whitespace should be manually stripped prior to commit/push.
Fix syntax for @author and @since tags, for the same reasons detailed in
commits 7d2cf7f and c38907b, respectively.
Recommendations:
- Disable automatic Javadoc templates completely within IDEA.
- Add Javadoc by hand when new classes are created.
- Follow the proper conventions for `@author` and `@since` tags.
- Do not add @since tags in src/test classes. Javadoc for these types
will never be generated or published, and developers can query
creation date metadata (more accurately) from git for these classes.
Note that in the future--particularly once ethereumj has its own
independent versioning--it will be desirable to use `@since` tags with
version values (for semantic versioning clarity, backward compatibility
analysis and communication, etc). Until then, the `@since DD.MM.YY`
approach will suffice.
Roman Mandeleil
ligi
Faiz Khan
Chris Beams
gubatron
Bitcoinzie