C# coding style: comments

Most C# style guides recommend against the /* ... */ commenting style, in favor of // or ///. Why is 开发者_Go百科the former style to be avoided?

---

I wouldn't say I have a strong view against either - but IMO the biggest issue is that /* and */ get messy if you have it nested, with the side effect that you can't copy/paste blocks around safely (quite).

You can too-easily end up with the wrong code commented/enabled, or can end up with it not compiling because you've ended up with a /* /* */ */.

If you copy a block of // around, no harm - just those lines remain commented.

---

One thing that /* */ can do that // can't is to comment an interior portion of a line. I'll sometimes use this to comment a parameter to a method where something isn't obvious:

        point = ConvertFromLatLon(lat, lon, 0.0 /* height */ ) ;

In this case the constant, 0.0, being passed as the third parameter is representing height. Of course this might be better:

        double height = 0.0;
        point = ConvertFromLatLon(lat, lon, height) ;

(I'm more likely to use the /* */ intra-line temporarily, to just try out passing a specific value.)

---

There are a few reasons to prefer // to /*.. */.

• As JaredPar mentioned, there are weird comment-nesting issues that can crop up with /* */ usage.
• If you ever write/wrote some code that processes source code files, you'll be really happy if the // method is all that you have to deal with.
• It is far easier to visually detect a large block of commented code with the "//" method, particularly if syntax coloring is unavailable. In fact, you'll often see the individual lines in a /* */ block prefixed with a *, just to be safe.
• The XML commenting style that can be used to produce code documentation requires "///" to be used.

---

One example that comes to mind is that it's possible to accidentally interrupt a /* style comment. For example

/* This is the start of a comment that documents the 
   behavior of the +-*/ operators in our program
*/ 

This code does not compile, while the // variant would. Also the /// represents a specific style of documentation to which external tools respond differently.

---

/* */ is fine for multi-line code blocks. For instance at the top of a code file, copyright info etc.

// is easier for single line.

Always use /// for at least all public members in a class as your XML documentation gets generated from that from which you can create help files.

---

I think you comment as you want since most of us are commenting via shortcuts in Visual Studio. I use ctr+K, ctrl+C all selected rows are comented and ctr+K ctrl+U to uncomment selected rows.

---

My opinion is that "//" is just easier to type in than /**/

---

I think /* */ will eventually go the way of the Dodo because in Visual Studio you can just select a block of code and hit CTRL-E,C to comment it out using the // style.

---

I always use // for actual COMMENTS, while I save the /* */ for code I temporarily do not want to run for debugging/development purposes.

By using only //, then you can be sure you can comment out a large block of lines/methods etc without nesting comments and making your compiler cry.

---

My guess is because one requires explicit syntax on EACH line and one creates comments that can comment out large sections of code if the closing */ is not used. It's just not as safe.