You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's badly needed. Since years, I have a strict NotNull policy in all of my code, so I simply annotate the whole package. Everyone knows this policy is intact, it's just about telling the IDE as well. If I annotate my NotNull code with NotNull, whenever NotNull is appropriate, my NotNull code basically consists of only NotNull with some occasional actual NotNull code between all the NotNull annotations from time to time. :)
Currently, I fix this by mixing with Eclipse's NonNullByDefault (unfortunately, Eclipse's NonNull and Nullable aren't applicable to methods, fields and parameters (Target({ElementType.TYPE_USE})), so I have to use JetBrains annotations for this).
The new annotation should be applicable to packages and classes, maybe also methods. I personally don't care about using it in types, but other people's mileage may vary. Specifying to what elements exactly it applies (methods, fields and/or parameters, maybe also type use) isn't strictly necessary for me, but probably makes sense. I'd suggest to default to all of them or no default at all.
It's badly needed. Since years, I have a strict NotNull policy in all of my code, so I simply annotate the whole package. Everyone knows this policy is intact, it's just about telling the IDE as well. If I annotate my
NotNull
code withNotNull
, wheneverNotNull
is appropriate, myNotNull
code basically consists of onlyNotNull
with some occasional actualNotNull
code between all theNotNull
annotations from time to time. :)Currently, I fix this by mixing with Eclipse's
NonNullByDefault
(unfortunately, Eclipse'sNonNull
andNullable
aren't applicable to methods, fields and parameters (Target({ElementType.TYPE_USE})
), so I have to use JetBrains annotations for this).The new annotation should be applicable to packages and classes, maybe also methods. I personally don't care about using it in types, but other people's mileage may vary. Specifying to what elements exactly it applies (methods, fields and/or parameters, maybe also type use) isn't strictly necessary for me, but probably makes sense. I'd suggest to default to all of them or no default at all.
This would also cover #18.
The text was updated successfully, but these errors were encountered: