Ugrás a fő tartalomra

Documenting overloaded methods with the same XML comments

Say I have this constructor:
/// <summary>
/// Example comment.
/// </summary>
public SftpConnection(string host, string username, 
    string password, int port) {...}
which has these overloads:
public SftpConnection(string host, string username, string password) 
    : this(host, username, password, 22) { }

public SftpConnection(string host, string username, int port) 
    : this(host, username, "", port) { }

public SftpConnection(string host, string username) 
    : this(host, username, "", 22) { }
and in reality, the XML comment is pretty large, with param, example and exception elements and so on.
Is there some way to add a special XML comment one-liner to the overloads, such that they use the exact same comments so that I don't need to copy-paste the whole, enormous original comments?
I'm thinking something like: <use cref="SftpConnection(string,string,string,int)" /> which doesn't work of course.
I am aware of the include element, but I get the impression it reads the comments from an XML file instead, which I don't want - I want the comment to still be visible in the code, but only once.
Thanks :-)
  • 1
    This question is quite old - for newcommers googling "inheritdoc" should hopefully set you down a path where you'll find the answer you seek. (It depends on your options and requiements.) – AnorZaken Jun 18 '17 at 16:05
  • @AnorZaken You should post your comment as an answer, it's actually very useful. – konrad.kruczynski Jul 12 '17 at 13:12

3 Answers

up vote18down voteaccepted
You can’t really do this. I find it annoying too.
However, you can alleviate the problem by using default parameter values instead of lots of overloads. Instead of:
public SftpConnection(string host, string username, string password, int port)
public SftpConnection(string host, string username, string password)
public SftpConnection(string host, string username, int port)
public SftpConnection(string host, string username)
You can have just a single one:
public SftpConnection(string host, string username, string password = "",
                      int port = 22)
This has multiple advantages:
  • Need only one XML comment. The whole point of my answer. ☺
  • Users of Visual Studio can instantly see that the default value for port is 22. With the overloads, this is not obvious; you have to specifically mention it in the documentation.
  • You indirectly encourage client code to become more readable by encouraging the use of named parameters (e.g. port: 2222 instead of just 2222, which is less clear).
And the greatest part about this is that using default values does not remove the ability to still have several overloads if you need them. Typical examples where you want overloads with default values might be something like...
ReadFrom(string filename, ReaderOptions options = null)
ReadFrom(Stream stream, ReaderOptions options = null)
ReadFrom(byte[] rawData, ReaderOptions options = null)
In these cases, I would argue the XML comments should actually be different.
  • You're right about that. I have changed my code as you suggested. Nevertheless, this is going to bug me now in the future! And there must be other situations where this functionality is needed. – Nobody Sep 8 '10 at 13:11
  • Definitely. Like I said, I find it annoying too. Default values only alleviate the problem, not solve it... – TimwiSep 8 '10 at 13:14
  • Of course this requires that you use the C# 4.0 compiler... – Tergiver Sep 8 '10 at 15:18
  • @Tergiver: Of course. I don’t normally consider it necessary to say because it’s not that common that people have to use something obsolete. – Timwi Sep 8 '10 at 15:34
  • 2
    @JoshuaGruber: I think the only relevant guideline in the article is the last one, where they're warning you the technique above is not CLS-compliant. So I would say it's fine if you stick to VB.NET / C#, but less so if you need to expose your functions to other languages. – rkagerer Jan 12 '13 at 18:03 
A half-solution is the <overloads></overloads> tag. While it doesn't solve the issue with <summary/>, it does provide documentation that shows up anywhere all the overloads are listed as a group, including both IntelliSense and SandCastle.
Is this what you want?
/// <seealso cref="SftpConnection(string,string,string,int)"</seealso>
  • That does not work, but I will look into the seealso element, TY. – Nobody Sep 8 '10 at 12:46
  • OK, I can't seem to get seealso to do anything. Long shot but is it perhaps something to do with the version of c# or .net? – Nobody Sep 8 '10 at 12:53
  • I think its meant for creating rich HTML documentations using doxygen and other documentation tools... ill look into what it does, though...what version of VS are you using (or are you using Mono)? – Richard J. Ross IIISep 8 '10 at 13:09
  • VS 2010 - I think you have to use the fully-qualified names though so your example might not work. – Nobody Sep 8 '10 at 13:14
  • 1
    After looking at visual studio's documentation and trying several workarounds, I have decided that the <seealso></seealso> is fo

Megjegyzések

Népszerű bejegyzések ezen a blogon

SW Documentation: Requirements

Requirements Nonfunctional Requirements Q&A FEBRUARY 17, 2010  ~  ANDREW STELLMAN ~  3 COMMENTS Non-functional requirements Q&A: We answer questions from readers about using  nonfunctional requirements  on a real software project, and how to use them on a real software project. Non-functional requirements: Planning out how well your software will work A couple of months ago I wrote a post called  Using nonfunctional requirements to build better software . It’s basically a step-by-step guide for creating an easy, practical technique to use nonfunctional requirements on a real software project, treating them in a way that’s similar to how a lot of Agile teams treat user stories, scenarios and other functional requirements: by sticking them on index cards and using them to do some lightweight planning. Since then, I’ve gotten a lot of questions about nonfunctional requirements (or, as some people call them, non functional requirements...

Privacy Notice for Visitors to Our Users’ Sites

Privacy Notice for Visitors to Our Users’ Sites Sections Who’s Who and What This Privacy Notice Covers Information We Collect About Visitors to Our Users’ Sites Information a Visitor Provides to a Site Information We Automatically Collect from the Site Other Information Provided by Our Users How We Use Visitor Information How We Share Visitor Information Other Tools Other Resources Hi there! This Privacy Notice explains how we, at Automattic, process information about the visitors of our users’ websites in connection with the services we provide through WordPress.com, Jetpack (including WooCommerce Services), IntenseDebate, Polldaddy.com, and Akismet. Read on! Who’s Who and What This Privacy Notice Covers Let’s talk first about who we are at Automattic, what we do, and what this Privacy Notice covers. We are the folks behind a variety of products and services designed to allow anyone–from bloggers, to small business owners, and enterprises–to create, publ...

THE RIGHT WAY TO WRITE A SINGLETON

THE RIGHT WAY TO WRITE A SINGLETON July 17, 2015 by   Hector Matos Even though I've written about the woes of managing state in my previous post, sometimes there's just no way we can avoid it. One example of managing state is something we're all quite acquainted with - The Singleton. The problem we find in Swift is that there are SEVERAL ways of implementing them. But which way is the right way? In this post I'm going to show you the history of the singleton and then show you the right way to implement the singleton in Swift. If you want to see the right way to implement the singleton pattern in Swift along with proof of it's "right-ness", you can scroll to the bottom of the post and see it there. :) A TRIP DOWN MEMORY LANE Swift is a natural evolution of Objective-C. In Objective-C, this is how we implemented the singleton: @interface Kraken : NSObject @end @implementation Kraken + ( instancetype ) sharedInstance { ...