C# Blooper №8: No warnings for conditions that are always true/false

Before reading any further, please read the disclaimer in the C# Bloopers post.

The Microsoft C# compiler does not issue 'condition is always true' and 'condition is always false' warnings. Perhaps these warnings are not particularly meaningful in Java, which lacks conditional compilation directives, and therefore if( true ) and if( false ) are the only means of achieving conditional compilation; but in C#, which has special conditional compilation directives, conditions which are always true or always false are invariably so by mistake; therefore, these warnings would indeed be meaningful, and useful.

Read more »

Why the Microsoft C# compiler lacks many useful warnings

As my C# Bloopers series of articles shows, the Microsoft C# compiler fails to issue many useful warnings which one would reasonably expect from a decent compiler of any language, and which are in fact readily and lavishly issued by Java compilers.

After all these years that the Microsoft C# compiler has been maturing, one cannot help but postulate that there are ulterior motives behind this continued state of misery with respect to warnings. For lo and behold, it just so happens that the "Ultimate" (most feature-packed and most outrageously expensive) edition of Microsoft Visual Studio contains a "Code Analysis" feature, which is capable of issuing hundreds of different types of warnings, ranging from the pedantic to the arcane, and including most, if not all, of the missing warnings that I am discussing here.

Read more »

C# Blooper №7: No warnings about unused private methods

Before reading any further, please read the disclaimer in the C# Bloopers post.

If you have a private method which is never used, you will not be given a warning about it by the Microsoft C# compiler. This means that your app will likely get shipped with unnecessary chunks of code in it, some of them possibly containing string literals that were never meant to make it out of the development environment, or even requiring libraries to be linked which were never meant to be required on the field.

Read more »

How to get a raise

Once upon a time I was dissatisfied with my salary at my workplace, and I let it show. The boss, fearing that he was about to lose me, placed an ad in the newspaper for my exact job description. Since I was looking for a job, I saw the ad in the newspaper. What I did was to reply to that ad, sending my boss my resume, which of course included precisely those qualifications that the job required. The boss got the message.

C# Blooper №4: Lame/annoying variable scoping rules, Part 1

Before reading any further, please read the disclaimer in the C# Bloopers post.

A variable identifier is, of course, only visible within the scope in which it is declared. This includes nested (child) scopes, but it does not include enclosing (parent) scopes. In C# however, once a variable identifier has been used in a scope, its name is "poisoned", so it cannot be used in enclosing scopes. Take this example:

Read more »

C# Blooper №6: No warnings about unused parameters

Before reading any further, please read the disclaimer in the C# Bloopers post.

One common mistake that programmers make is to forget to make use of a parameter to a method. This can lead to quite subtle bugs that are hard to track down and correct.

Now, other language compilers are kind enough to warn the programmer that a parameter is unused, and they also allow temporary suppression of the warning for the rare case when such lack of use is legitimate. But not so in Visual C#. If you forget to use a parameter in Visual C#, you will not know unless you run the "Code Analysis" tool on it.

Read more »