Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>While I was working on some of older code in C#, I encountered a code which irked me.</p> </blockquote> <p>There are numerous irksome problems here. Let's list them all.</p> <pre><code>private string foo(string _text) { /* some manipulation on _text */ return _text = Server.HtmlDecode(_text); } </code></pre> <blockquote> <p>It's the last line which irks me</p> </blockquote> <p>The comment is also irksome. Local variables are <em>cheap</em>. There is no need to erase the original value of <code>_text</code>. Instead, make a new local variable and manipulate that. That way, when you are debugging <em>at any point in the method you can know what the original argument was</em>. (Remember, the original argument might be eligible for garbage collection the moment the variable is overwritten, and therefore could be lost forever.)</p> <p>Do not write over a formal parameter without a very good reason. It makes it harder to debug.</p> <blockquote> <p>the value of an assignment operator is the left operand, so I can see it.</p> </blockquote> <p>That is correct in this case but subtly wrong in general; the value of an assignment operator in C# is the value of the <em>right</em> operand <em>after being converted to the type associated with the left hand side</em>. Remember, the left hand side might not have a value; it could be a write-only property. </p> <blockquote> <p>Is it a ordinate practice in C# that I need to get accustomed to?</p> </blockquote> <p>There is a standard practice here, yes. What is bizarre about this usage is (1) that the variable chosen is a formal, and (2) that the assignment is combined with the <code>return</code>. </p> <p>It would be a standard practice in C# to say:</p> <pre><code>string decoded = Server.HtmlDecode(_text); return decoded; </code></pre> <p>Now you might wonder what the compelling benefit of this is over what you suggest:</p> <pre><code>return Server.HtmlDecode(_text); </code></pre> <p>The answer is: before Visual Studio 2013, there was no facility in the debugger to examine the returned value of a method call! Therefore if you wanted to see what the value returned by <code>HtmlDecode</code> was while debugging you had the following choices:</p> <ul> <li>Debug at the assembly level and look at the contents of EAX</li> <li>Step into <code>HtmlDecode</code> and examine its state</li> <li>Step out of the current method and examine whatever the return value was assigned to</li> <li><strong>Assign the result to an otherwise useless local variable</strong> and then examine the local in the debugger</li> </ul> <p>Since the first three are horrid and the last one is easy, that's what many C# programmers got in the habit of doing.</p> <p>If you do this and then do <em>not</em> use the resulting local, the C# compiler knows that this is a common practice and deliberately suppresses the "you wrote to a local you then never read from" warning. It only gives that warning if the local had a constant written to it, in which case you already knew what it was at compile time and don't typically need to examine it in the debugger.</p> <p>Hopefully now that VS2013 finally supports this frequently-requested feature, this sort of pattern will gradually disappear.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload