Style Guide for Obfuscation?
-
A colleague told me about a great bugfixing experience: a local variable had the same name as a member variable. "But the compiler will show you a warning." - "No, it does not." Hard to believe, hence I tried it with a very simple class. My colleague was right: there is no compiler warning when a local variable overwrites a member variable. But there are some tools which could help us here, like StyleCop. I installed StyleCop, and eventually got it accepting my code:
// <copyright file="DontDoThat.cs" company="blah">blah</copyright>
namespace Nonsense
{
/// <summary>
/// Blah blah
/// </summary>
public class DontDoThat
{
/// <summary>
/// Blah blah
/// </summary>
private int someValue = 0;/// <summary> /// Blah blah /// </summary> public void DoSomething() { if (this.someValue == 0) { this.DoSomethingElse(); } } /// <summary> /// Blah blah /// </summary> private void DoSomethingElse() { int someValue = 42; int somethingElse = someValue \* someValue; } }}
Well, that's clean code, isn't it? StyleCop suggested great things. Still a local variable can overwrite a member variable, but now you see the difference more clearly: a member variable has a "this." prefix. Hungarian notation is so great. X|
-
A colleague told me about a great bugfixing experience: a local variable had the same name as a member variable. "But the compiler will show you a warning." - "No, it does not." Hard to believe, hence I tried it with a very simple class. My colleague was right: there is no compiler warning when a local variable overwrites a member variable. But there are some tools which could help us here, like StyleCop. I installed StyleCop, and eventually got it accepting my code:
// <copyright file="DontDoThat.cs" company="blah">blah</copyright>
namespace Nonsense
{
/// <summary>
/// Blah blah
/// </summary>
public class DontDoThat
{
/// <summary>
/// Blah blah
/// </summary>
private int someValue = 0;/// <summary> /// Blah blah /// </summary> public void DoSomething() { if (this.someValue == 0) { this.DoSomethingElse(); } } /// <summary> /// Blah blah /// </summary> private void DoSomethingElse() { int someValue = 42; int somethingElse = someValue \* someValue; } }}
Well, that's clean code, isn't it? StyleCop suggested great things. Still a local variable can overwrite a member variable, but now you see the difference more clearly: a member variable has a "this." prefix. Hungarian notation is so great. X|
If Visual Studio did everything for you, there'd be no reason to buy a tool like ReSharper! :rolleyes:
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
If Visual Studio did everything for you, there'd be no reason to buy a tool like ReSharper! :rolleyes:
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Good point. But are sure that ReSharper does find that? Really, did you check it?
-
Good point. But are sure that ReSharper does find that? Really, did you check it?
Yes: Local variable hides member - ReSharper - Confluence[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
A colleague told me about a great bugfixing experience: a local variable had the same name as a member variable. "But the compiler will show you a warning." - "No, it does not." Hard to believe, hence I tried it with a very simple class. My colleague was right: there is no compiler warning when a local variable overwrites a member variable. But there are some tools which could help us here, like StyleCop. I installed StyleCop, and eventually got it accepting my code:
// <copyright file="DontDoThat.cs" company="blah">blah</copyright>
namespace Nonsense
{
/// <summary>
/// Blah blah
/// </summary>
public class DontDoThat
{
/// <summary>
/// Blah blah
/// </summary>
private int someValue = 0;/// <summary> /// Blah blah /// </summary> public void DoSomething() { if (this.someValue == 0) { this.DoSomethingElse(); } } /// <summary> /// Blah blah /// </summary> private void DoSomethingElse() { int someValue = 42; int somethingElse = someValue \* someValue; } }}
Well, that's clean code, isn't it? StyleCop suggested great things. Still a local variable can overwrite a member variable, but now you see the difference more clearly: a member variable has a "this." prefix. Hungarian notation is so great. X|
It doesn't give you a warning because it's perfectly valid code. If you want to use the class var, you can qualify it with
this.varname. Don't make the mistake of using the IDE as a crutch.".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
A colleague told me about a great bugfixing experience: a local variable had the same name as a member variable. "But the compiler will show you a warning." - "No, it does not." Hard to believe, hence I tried it with a very simple class. My colleague was right: there is no compiler warning when a local variable overwrites a member variable. But there are some tools which could help us here, like StyleCop. I installed StyleCop, and eventually got it accepting my code:
// <copyright file="DontDoThat.cs" company="blah">blah</copyright>
namespace Nonsense
{
/// <summary>
/// Blah blah
/// </summary>
public class DontDoThat
{
/// <summary>
/// Blah blah
/// </summary>
private int someValue = 0;/// <summary> /// Blah blah /// </summary> public void DoSomething() { if (this.someValue == 0) { this.DoSomethingElse(); } } /// <summary> /// Blah blah /// </summary> private void DoSomethingElse() { int someValue = 42; int somethingElse = someValue \* someValue; } }}
Well, that's clean code, isn't it? StyleCop suggested great things. Still a local variable can overwrite a member variable, but now you see the difference more clearly: a member variable has a "this." prefix. Hungarian notation is so great. X|
Why would the compiler complain, name scope is part of the language
-
A colleague told me about a great bugfixing experience: a local variable had the same name as a member variable. "But the compiler will show you a warning." - "No, it does not." Hard to believe, hence I tried it with a very simple class. My colleague was right: there is no compiler warning when a local variable overwrites a member variable. But there are some tools which could help us here, like StyleCop. I installed StyleCop, and eventually got it accepting my code:
// <copyright file="DontDoThat.cs" company="blah">blah</copyright>
namespace Nonsense
{
/// <summary>
/// Blah blah
/// </summary>
public class DontDoThat
{
/// <summary>
/// Blah blah
/// </summary>
private int someValue = 0;/// <summary> /// Blah blah /// </summary> public void DoSomething() { if (this.someValue == 0) { this.DoSomethingElse(); } } /// <summary> /// Blah blah /// </summary> private void DoSomethingElse() { int someValue = 42; int somethingElse = someValue \* someValue; } }}
Well, that's clean code, isn't it? StyleCop suggested great things. Still a local variable can overwrite a member variable, but now you see the difference more clearly: a member variable has a "this." prefix. Hungarian notation is so great. X|
Strictly speaking, there is no need for a compiler warning here really. It's well defined C# language behavior. Also, nothing's overwriting anything here. You declare a local and use the local. It has the same name as a member, but that's not the compiler's problem. That said, code analysis would catch this. See CA1500: Variable names should not match field names[^]
Regards, Nish
Website: www.voidnish.com Blog: voidnish.wordpress.com
