C#: some corner cases


I was just reading the blog entry corner cases in C# and Java when I remember two of such corner cases I hit


Multi-line comments


I was working on a tool to count source lines. In that I printed out number of uncommented lines as well. While working on it I commented out a block of code (I hate commented lines of code in production sources [:)] ) and was surprised at the result

/*

string startDelin = “/*”

string endDelim = “*/“;

string oneLine = “//”;

*/


Its apparent from the source coloring that the */ inside the string endDelim was considered as the comment block end-delimiter. I thought it was a bug in the begining, however a look into the lexical grammer in the C# 1.2 spec Section 2.3.2 clarified that this is indeed the expected behavior…..


Pre-processor directive


This one is real corner case. I don’t remember where I first saw this, but it goes as follows. There was a block of conditional code as in

#if FOO

/*

#else

/* some comment */

class MyClass { }

#endif


The /* was lying around in a big block of code that was never used as FOO was never defined. When the same source got compiled with FOO defined,  still in the code the class MyClass could be found even though it’s inside the #else block. The reason is as follows

#define FOO

 

namespace WeirdPreProcessing

{

#if FOO

/*

#else

/* some comment */

class MyClass { }

#endif


So defining FOO made the #else commented out and hence everything inside the #else block became a part of the #if block!!!


 

Comments (3)

  1. zzz says:

    I never use /* or */ when possible. Always the IDE auto comment that makes handling the //’s much nicer.

  2. For work in progress where you are midst of developing any of the commenting style that suites you is fine. However, you should not checkin into your source control commented lines of code and if you do, then it becomes a important how you commented the code out. See http://blogs.msdn.com/abhinaba/archive/2005/11/22/495701.aspx for my thoughts on this issue. There having // to comment out code has several issues

  3. zzz says:

    Any source base will have thousands of // scattered every-where, so how the hell am I supposed to find code commented out in this fashion?

    If you only use the VS IDE "comment selection", your comments should always match the (perl style) regular expression of ^s?//s?S where ^=begin line s*=zero or more space/tab and such //=comment begin S=non-space/tab. The ?’s might not be needed, but it is generally good idea to use them by default since greedy matching can and will have surprising results in many cases.

    Of course you should then not have lines beginning with // for non-comment stuff, which might not be the case in some codebases.

    And good luck in hoping that VS’s replace would conform to the industry standard perl regular expression syntax, doubt that example piece works in VS.

    >If you are using the same editor or some other editor which has the corresponding uncomment feature then you are fine. If you are unfortunate enough to like some other editor like notepad

    Well if you say you’re not accepting any editor that can’t use custom macro and regular expression replacing – even for money, I’ll bet they’ll rather let you use another editor instead of finding a guy that wants to use notepad.