I can not imagine a case where a comment beneath the fact is useful.

It's obvious that comments on the same line can only be made if the text is too short.

When you learn to comment, you realize that commenting on production code is rarely useful if you put it on the same line. You do not have the space to explain why that is.

So putting it up above is usually more appropriate. This is enforced in C # by the Microsoft convention guide , posted on stderr comment. Not even they always follow this. Good programmers always understand context and know when to use a convention and when to avoid it.

Note that you need to look at other conventions as well. There are those who determine a maximum size for the rows. Others do not enforce this limit and let the line break resolve this.

When you comment on the line itself, you know that it is referring to that line. When it is said above it is not certain how far the comment is worth. As the comments need to explain something broader, it is common to be more interesting to be ahead of what will be explained.

Of course you can have your own convention. The important thing is to be consistent.

But we are talking about fixed comments. It's not the same as a quick comment, the so-called comment out , which is done to try something without a part of the code (something that should really be something very temporary). Temporary feedback depends a lot on the need. It is common to use /* ... */ more. But a // to eliminate the end of the line, possibly putting another part in place may be the simplest to do. The fact that if it will not survive, and it can not, it does not matter much, it's a very personal thing.

Do not comment

But the ideal in this case is not to comment. The example is not good. In another context it might be that some special reason would better define the choice.

The commented code is obvious. At least in the general context of development.

Comment must always say why it was done and not what was done. And you should just say why you have a good reason. If you say what you've done, fix the code to be readable on it.

Comments are out of step with the code. It is common for the programmer to change the code and forget to change the comment. In a way it violates DRY . And they encourage people to write less readable codes.

Of course in educational codes, a comment saying what you are doing even makes some sense, but it would have to be very explanatory. Not by simply repeating the code. In this case it may be that the% cos_de% comment is more appropriate.

I will not go into details, there are already questions about this:

• Code comments when working in groups
• How to know the right measure of comments?
• Wikipedia

Specifying the language C# does not define a coding pattern. However, the guidelines are used by Microsoft to develop samples and documentation.

Coding conventions serve the following purposes:

• Create a consistent look for the code, so readers can focus on content rather than layout.

• Allow readers to understand code faster, making assumptions based on previous experience.

• Make it easy to copy, change, and maintain the code.

• Demonstrate best practices for C #.

Feedback :

• Place the comment on a separate line, not at the end of a line of code.

• Start the text of the comment with a capital letter.

• End the comment text with a period.

• Enter a space between the comment delimiter (//) and the comment text.

• Do not create blocks of formatted asterisks around comments.

Example:

// The following declaration creates a query. It does not run
// the query.

Reference: C # Encoding Conventions