I'm a proponent of properly documented code, and I'm well aware of the possible downsides of it. That is outside of the scope of this question.I like to follow the rule of adding XML comments for every public member, considering how much I like IntelliSense in Visual Studio.There is one form of redundancy however, which even an excessive commenter like me is bothered by. As an example take List.Exists()./// <summary>///     Determines whether the List<T> contains elements///     that match the conditions defined by the specified predicate./// </summary>/// <returns>///     true if the List<T> contains one or more elements that match the///     conditions defined by the specified predicate; otherwise, false./// </returns>public bool Exists( Predicate<T> match ){    ...}Summary and returns are basically saying the same thing. I often end up writing the summary more from a returns perspective, dropping the returns documentation altogether.Returns true when the List contains elements that match the  conditions defined by the specified predicate, false otherwise.Additionally, the returns documentation doesn't show up in IntelliSense, so I rather write any immediately relevant information in summary.Why would you ever need to document returns separately from summary?Any information on why Microsoft adopted this standard?
Should a method comment include both a summary and return description when they're often so similar?
documentation;comments;intellisense
You can infer one from another, but those two sections remain separate, because it helps to focus on the one which interests the person when reviewing/using the code.Taking your example, I would rather write:/// <summary>/// Determines whether the List<T> contains elements that match the conditions/// defined by the specified predicate./// </summary>/// <returns>/// A value indicating whether at least one element matched the predicate./// </returns>public bool Exists(Predicate<T> match){    ...}If I'm reviewing this code and I want to know what the method does, I read the summary, and that's all what I care about.Now, let's imagine I'm using your method and the return value I receive is strange, given the input. Now, I don't really want to know what the method does, but I do want to know something more about the return value. Here, <returns/> section helps, and I don't need to read the summary.Again, in this example, you can infer the summary from <returns/>, and infer the expected return value from the summary. But taking the same argument to the extreme, there is no need to document your method at all in this case: the name of the method, put inside List<T>, with Predicate<T> match as a sole argument is quite explicit itself.Remember, the source code is written once but read plenty of times. If you can reduce excise for the further readers of your code, while spending ten seconds writing an additional sentence in the XML documentation, do it.