Sometimes I find myself in situations when the part of code that I am writing is (or seems to be) so self-evident that its name would be basically repeated as a comment:class Example{    /// <summary>    /// The location of the update.    /// </summary>    public Uri UpdateLocation { get; set; };}(C# example, but please refer to the question as language-agnostic).A comment like that is useless; what am I doing wrong? Is it the choice of the name that is wrong? How could I comment parts like this better? Should I just skip the comment for things like this?
How to deal with tautology in comments?
programming practices;documentation;language agnostic
In most projects I work on, there isn't a significant amount of time to write detailed comments on every single class member.That doesn't mean there isn't time for comments; on the contrary, there's plenty of time for tautological comments that puke back a rephrased version of whatever's being commented. They work great as a starting point.Especially given Visual Studio's usage of comments accompanying IntelliSense, it's a good idea to start with a short bit of information about the field:class Example{    /// <summary>    /// The location of the update.    /// </summary>    public Uri UpdateLocation { get; set; };}And then as you continue to code, when you can't remember whether UpdateLocation was the location that the update took place, or the location that the update is being sent to, you'll have to revisit the code. It is at this point that you should add that additional information:class Example{    /// <summary>    /// The Uri location where the update took place.    /// </summary>    public Uri UpdateLocation { get; set; };}If ever another programmer asks you about details on a field, update the comments with that information:What sort of update should Example.UpdateLocation be used to store?class Example{    /// <summary>    /// The Uri location where the Foo update took place.    /// </summary>    public Uri UpdateLocation { get; set; };}Just like a program has bugs, good comments have bugs that need to be iteratively worked out. The purpose of comments is to assist in understanding code when you revisit it six months later and can't remember anything about how the program works.And just like programming, your comments have to start somewhere. Tautological comments are the Hello World! of comments, as you practice writing and updating documentation, your starting documentation will become more and more resilient.