Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

A new colleague has mooted the idea of using Resharper annotations within our code base (we already are great fans and users of Resharper).

My new colleague cites things like explicitly stating whether a parameter can be null or not null at coding time is a good thing so that consumers of that class can see warnings at coding time.

My reservation is it adds noise to the code, is not runtime executed hence I favour Guard clauses. I am also concerned that like comments that they can go stale. I am also concerned about code readability and the overhead of writing them in the first place. Ultimately I am trying to keep development lean so don't want to add overhead for relatively little gain.

Finally it feels wrong decorating code for one vendor's tooling support.

What are your thoughts? Good/bad experiences?

share|improve this question

closed as too broad by gnat, MichaelT, durron597, Snowman, GlenH7 Aug 13 at 1:16

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

I'm voting to close this question as too broad because it is a polling question. See: What is the problem with “Pros and Cons”? –  durron597 Aug 12 at 14:44

6 Answers 6

Why use a 3rd party version when you could just use CodeContracts and not requrire others use Resharper to reap the benefits?

Personally, I vote for guard clauses in any case. It is at least easier to run down the exception when someone ignores the warnings . . .

share|improve this answer
Code contracts can create guard clauses automatically, which is great. –  configurator Aug 15 '11 at 22:59
Code Contracts are 3rd party. Just "Microsoft Endorsed" [and then silently swept under the rug]. It doesn't matter if you pay $150 for ReSharper or $ for a suitable version of Visual Studio. In both cases it's an Add-on. Code Contracts, while much more powerful, is also much slower and adds a lot more code-pollution in cases when only simple static analysis of null-violations is desired. –  user2864740 Feb 25 at 22:20

Resharper annotations are not a replacement for guard clauses or code contracts, if they are used they should be used in conjunction with not instead of. Whilst code contracts and guard clauses provide runtime checking of contracts, Resharper annotations work with the Resharper engine to assist developers at design time - ensuring objects that could be null are checked before use, or suggesting the removal of unnecessary checks where they cannot. There are a number of other attributes beyond the nullness checks which can be useful beyond the basic nullness checks to assist in the correctness of the code.

For the nullness check attributes Resharper generally provides alt+enter shortcuts for adding the notnull and canbenull attributes and for parameters it can add both the attribute and a guard clause at the same time.

If you do use the annotations it is probably best to copy the annotation source rather than link to the annotations assembly, that way the code isn't tied specifically to Resharper - there are simply some attributes defined in your own source.

share|improve this answer

I think you'll find that ReSharper annotations fall into the YMMV area. For example, if you have a library with lots of String.Format-like extension methods, and your library is being published to many developers (internal or external), you can give them the benefit of additional checks when they use the API. Same goes for things like null checks - if your API liberally assumes that null parameters and returns are OK, you can add one layer of safety over and above what your XML comments specify. On the other hand, if you use option types or Maybe monads, this functionality will be correspondingly less useful.

share|improve this answer

While the C# designers are considering language support for nullability, until that's available Resharpers NotNull / CanBeNull attributes have proven to be quite useful to me.

Although they do clutter up the codebase somewhat, they have vastly reduced the number of NullReferenceExceptions in my applications, with little extra effort. That makes them valuable for me.

Regarding Guard vs nullability attributes: I've settled on using guard checks at publicly accessible class members. For private methods, I use the attributes only. Besides that, I usually apply naming schemes like TryGetXXX() and GetXXXOrNull() to indicate that nulls can be returned.

On the risk of becoming stale, it's always easy to get rid of them: just search/replace [NotNull] / [CanBeNull] with "" in your source tree and they are gone. That is, assuming you have nice Resharper formatting rules in place to property reformat your sources afterwards.

I somewhat share your feeling wrong about vendor linking. I would say it depends on the context of your work. If your sources are privately maintained by a closed team that all have Resharper installed, I see no objection. Even if you are publishing your assemblies to other parties, the "JETBRAINS_ANNOTATIONS" conditional compilation attribute prevents the annotations from showing up in binaries, if that's what you want.

Lastly, to ensure your sources are consequently annotated, you may want to use the open source Visual Studio Extension that I created for this purpose. More info at:

share|improve this answer

I dislike the concept of in-code annotations for the benefit of one tool. Extra code added for the use of a tool seems like a code smell. As with many coding situations, there is (probably) a better way to do it.

share|improve this answer

I agree with all those that mentioned Code Contracts as a better alternative. Besides being now part of the .NET platform it has great tooling support (static checker and VS2010 add-in).

I would expect R# to deprecate their custom annotations support in favor of code contracts.

share|improve this answer
I agree with all those that mentioned Code Contracts as a better alternative. ... Don't answer just to say you agree with earlier answers, upvote them instead. (but it's ok to write stuff like that, when you are actually adding something new with your answer) I would expect R# to deprecate their custom annotations support in favor of code contracts. That's your actual answer, and you have to expand it a bit, to stand as an answer. Why do you expect that R# to deprecate their custom annotations? Please back that claim with references, or at least some reasoning. –  Yannis Jan 11 '12 at 8:30
Well, I didn't expect an encounter with the downvote police, but I would add in my defense that I did add to the original answer by stating that Code Contracts are now part of the .NET BCL and that it has great tooling support in the form of the status checker and the VS plugin. I guess that in the future I should limit myself to just read what others say to avoid offending any sensibilities to the minimum amount of prose that is required for an answer to be considered kosher. –  Eddie Velasquez Jan 16 '12 at 17:37
Hmmm, the site has a voting system. Every time you submit a post there are chances you get up or down voted, and there isn't much you or anyone can do about that. If the above comment is representative of your attitude towards getting down voted, perhaps you should limit yourself in reading what others say. If not, then perhaps you could improve your answer, your comment is actually bigger than your answer. I feel my down vote is justified, and I would gladly retract it if your improve your answer. –  Yannis Jan 16 '12 at 18:07
I don't know if you have noticed that no answer besides mine has pointed out the Code Contracts are now part of the .NET platform AND it has tooling support. Granted it was terse answer but it contains no falacies and adds to what others had said before me. I know that the site has a voting system and I do not mind being up or down voted, as I just answer trying to be somewhat helpful to the person that asked the question. I just think that your reply was more of a "downvote policeman" answer instead of expanding or pointing out mistakes with my answer. –  Eddie Velasquez Jan 23 '12 at 18:22
2015 and ReSharper 9 doesn't even pretend to support Code Contracts. IMOHO, the biggest failing with Code Contract and ReSharper integration [or integration with anything for that matter] is CC does not have attributes for the common Null/Not-Null case which is what 99% of what code checks for! This is a big integration failing that has not been - and does not look like it will be - fixed. (Again, IMOHO, attributes for these common cases should have added to CC from the start as an alternative. And CC should also have allowed Ensure<T> without rewrites, but I digress..) –  user2864740 Feb 25 at 22:25

protected by MichaelT Aug 11 at 14:05

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.