Other possible analysis annotations


Been noodling on the idea of analysis annotations, was looking for other people's insights. Here's some I've come up with so far.

@Generated: A class annotation to be placed on classes created by code generation. Valuable from an analysis point of view since generated code has different quality characteristics from hand-crafted code (to put it mildly). In IDEA, one could imagine on-line error checking being disabled for generated code.

@Ignorable and @NotIgnorable: These are method annotations, indicating whether it is safe to ignore the return value of a method. Methods like InputStream.read() would be marked @NotIgnorable, indicating that ignoring the return value is dangerous. Methods like List.add() would be marked @Ignorable, since 99 times out of 100 the return value is useless to the calculation. Analysis uses are obvious.

@Pure: A method annotation, similar to "const" in C++. Declares that the method should have no visible side effects. Useful both as documentation, as something to check via analysis, and for increasing the power of data flow analysis.

@Initialization: A method annotation. Declares that a method should be declared precisely once for an object, and that it should be called before any non-@Initialization methods on an object. Probably more useful for dynamic than static analysis, one could imagine instrumenting source or bytecode to add checks for this.

@Disposal: A method annotation. Declares that a method should be declared precisely once for an object, and that no non-@Disposal methods should be called after it. Probably more useful for dynamic than static analysis.

Thoughts?

--Dave Griffith

3 comments
Comment actions Permalink

For method parameters:
@input
@output
@inoutput

Currently, I use a naming convention - i_data, io_buffer, o_result - to
convey this info.
It could also be used for analysis.

Alain

0
Comment actions Permalink

@Ignorable and @NotIgnorable: These are method annotations,
indicating whether it is safe to ignore the return value of a method.
Methods like InputStream.read() would be marked @NotIgnorable,
indicating that ignoring the return value is dangerous. Methods like
List.add() would be marked @Ignorable, since 99 times out of 100 the
return value is useless to the calculation. Analysis uses are obvious.


I don't like those names. The double negative "not ignorable" is hard for
me to grasp intuitvely. I suggest using the inverse - something like @MethodReturnIsAllThatMatters
or something. I don't mean that name exactly, but something with that feel.

@Pure: A method annotation, similar to "const" in C++. Declares that
the method should have no visible side effects. Useful both as
documentation, as something to check via analysis, and for increasing
the power of data flow analysis.


Would it make sense for variables and parameters to be @Pure too, indicating
that no non-Pure calls or field assignments will be made?

@Initialization: A method annotation. Declares that a method should
@Disposal: A method annotation. Declares that a method should be


I like these, but maybe names like @Initializer and @Disposer would be better.

There are also the obvious annotations more like @NonNull like @NonNegative
etc.


0
Comment actions Permalink

Dave Griffith wrote:

@Pure: A method annotation, similar to "const" in C++. Declares that the method should have no visible side effects. Useful both as documentation, as something to check via analysis, and for increasing the power of data flow analysis.


This should not be limited to methods only, but also for fields, parameters, variables and
return values, i.e. on an @Pure value you may only call @Pure methods. Just like it is in C++
as well. This could also be called @Const or @Immutable.

@Immutable: On class level to indicate that the state of an object can only be set during
initialization, i.e. in ctors. Kinda like a shortcut to declaring each method @Pure.

Sascha

0

Please sign in to leave a comment.