We Keep Coding

Any way of making the C# compiler check more at compile time?

I would like to make the C# compiler check more at compile time. For example:
public class Foo
{
public bool condition;
public void CheckCondition()
{
if(condition) {
#warning SomeCompilerWarning
}
}
}
static void Main()
{
var foo = new Foo();
foo.condition = true;
foo.CheckCondition();
}
This trivial sequence should be able to be detected compile time. I realize #warning is a pre-processor directive. I would like the above to somehow generate a warning. Are there any ways to slightly extend the compile time checks for trivial sequences or are custom extensions the only way?
Clarifications:
I'm asking for an alternative to the above that does not use the pre-processor. The above is an example in concept what I would like to achieve.
I want the compiler to emit a warning similar to the example. The example doesn't work. It is just used as an illustration.
Rephrase: Are there any alternative to writing a custom analyzer to achieve the behavior in the example, without using any preprocessor directive? The #warning is just an illustration as to what I would like to happen.

No, and I doubt it would be desirable even if it was technically possible. The number of cases when it would be feasible and correct is miniscule; the number of cases when it would give false warnings, or fail to give a warning when it should, would dwarf any such utility, and as such: it would be more harmful than useful. In the general case: object state is not very predictable even between successive lines of the same method, since in general there are unrelated side-effects, concurrency, reflection, unsafe access, and a wide range of other things to contend with - including the "halting problem".
This situation can only be usefully and reliably detected at runtime, so: do that.

There is no alternative to writing a custom analyzer.

Define own keywords and meanings

Is it possible to define your keywords in C#?
I mean something like
public important Form newform;
where important would be the new keyword. It would mean something like, for example, that if the type is null when compiling an error occurrs. So the example would produce an error. An example with no error would be
public important Form newform = form1;

No, the compiler doesn't allow you to add keywords out of box.
That doesn't mean you can't accomplish what you want, but it's going to be non trivial. You're going to need to perform your own custom static code analysis.
Roslyn
One way to do it is via the new .NET Compiler Services (Roslyn) Code Analyzers. You can read this MSDN article to get started: https://msdn.microsoft.com/en-us/magazine/dn879356.aspx and you'll end up with something that looks like this:
This will work from within Visual Studio, and you can generate at least Warnings, I would assume Errors as well (or you'll have to turn on "Treat Warnings as Errors").
Because you want to declaritively add the check to certain variables, you'll need to make use of Attributes:
/// <summary> Indicate a variable must be given a value
/// in the same line it's declared </summary>
public class ImportantAttribute : Attribute {}
public class Program
{
[Important]
object thisShouldError;
object thisIsFine;
}
Then when you write your Analyzer you'll need to check the variable declaration node to see if it's decorated with Important.
If you want this to work on a build server (or outside of VS), you might need to do some more work: Roslyn: workspace loads in console application but not in msbuild task
StyleCop
The easiest way is probably to use Code Analysis (ie StyleCop) to run Static Analysis Rule Sets against your code base:
You'll need to write your own Rule Set and I don't know if the Rule Sets will give you fidelity to be able to declare which variable declarations you want to force a check on, ie I don't know if you'll be able to mix & match this:
public class Program
{
[Important]
object thisShouldError;
object thisIsFine;
}
Fody
Another approach is to use an IL weaving tool like Fody that lets you manipulate the IL of your application during compilation. AFAIK you can't directly generate compilation errors, but you might be able to add invalid IL that will in turn generate a compile time error.
So based on the same code as above, after a compilation pass with Fody you'd end up with code like:
public class Program
{
[Important]
object thisShouldError YouForgotToInitializeThisImportantVariable;
object thisIsFine;
}
Custom Compiler
Microsoft did open source the C# compiler: https://github.com/dotnet/roslyn. So if you're feeling really ambitious, you can absolutely add in your own keywords in your own fork of the compiler. Of course then you'll essentially have your own language and it won't be able to compile on anything other than your custom compiler.

Short: No you can't.
Long: It is possible, but it it's probably never happening, as you would require for the C# team to add it, but that would require a lot of discussion and a lot of feasible uses for it.

Maybe you can simply use tools like ReSharper... To define new keyword only for finding uninitialized public variables sounds as bad idea.

No, you cannot create a new keyword in the way you have indicated. I suggest you take a look at this.
Create new keyword for C# automatic property

Can I tag a C# function as "this function does not enumerate the IEnumerable parameter"?

Multiple enumeration of the same enumerable is something that has been a performance problem for us, so we try to stomp those warnings in the code. But there is a generic extension function that we have for throwing null parameter exceptions that generates a lot of these warnings. Its signature looks like this:
public static void VerifyArgumentIsNotNull<T>(this T value, string valueName) where T : class
All it does is check for null and throw a nicely formatted and localized (for whichever human language is in play at the time) exception.
When this function is used on an IEnumerable parameter, it makes the code analysis warn about a possible multiple iteration of the IEnumerable because the analyzer has no idea what that function does.
I would like to put some tag on this function that says, "Yes, this takes the enumerable as an input, but it does not iterate it and therefore should not be counted as a possible iteration by callers." Is there any such tag? I've searched the Internet to no avail.

Yes, what you're asking is very much possible, but requires a little work. ReSharper uses Code Annotations to add hints to its analysis engine and make more sense of the code it has to work with. I recently recorded a webinar with JetBrains called ReSharper Secrets, where I go into much greater detail about what Annotations are and how to use them. You should watch it!
There's an annotation attribute, [NoEnumeration] that does exactly what you ask - specifies that the given IEnumerable argument is not enumerated, however it's not included in the default Code Annotation Attributes, however it is defined in the JetBrains.Annotations.dll assembly.
So after this introduction, here's what you need to do:
(if you haven't already,) go to ReSharper Options, then Code Inspection → Code Annotations, and press the Copy default implementation to clipboard button
Create a file in any of your (shared) projects called Annotations.cs (or any other name)
Paste the code from the clipboard, completely replacing anything that was previously in Annotations.cs
Add the following definition at the end of the file:
Code:
/// <summary>
/// Indicates that IEnumarable, passed as parameter, is not enumerated.
/// </summary>
[AttributeUsage(AttributeTargets.Parameter)]
public sealed class NoEnumerationAttribute : Attribute
{
}
After you done this, all that's left to do is place the [NoEnumeration] attribute on the value argument, like this:
public static void VerifyArgumentIsNotNull<T>([NoEnumeration] this T value, string valueName) where T : class
{
....
}
And that's it! The warning will disappear!
Bonus:
There are 3 additional attributes you can use to decorate this method to make it even more useful: [NotNull], [ContractAnnotation] and [InvokerParameterName]. I recently describe what they do (and a short demo) in this issue for a similar API called LiteGuard.
Annotations are fun :)

Since VerifyArgumentIsNotNull is generic, but does nothing type specific, it can take an object:
public static void VerifyArgumentIsNotNull(this object #object, string argumentName) { ... }
Resharper (9.11.) assumes that the called method does not cast #object back to an IEnumerable, and thus there is no warning.
Note the lack of the class constraint means the compiler may not warn if you accidentally pass a value type to VerifyArgumentIsNotNull, but Resharper will warn that a value type can never be null.
This approach has the additional advantage of saving the JIT from creating an instance (closed generic) method for every type that VerifyArgumentIsNotNull is called with; a micro-optimization to be sure, but a rare example where a generic may not be preferable to an old-school object.
One possible drawback to the above: I have seen similar implementations where VerifyArgumentIsNotNull returns "value". In this case a return value of type T is needed to avoid an explicit cast. (IMO this syntax is ugly. So it is not a drawback for me.)
Two other editorial comments:
1. A method name I have seen: ThrowIfNull is more concise, and "Throw" is more explicit than "Verify"
2. I no longer use methods for this, because without an annotation on VerifyArgumentIsNotNull Resharper must assume the argument could still be null. I find it much simpler to let R#, insert a 1-line if + throw when I add the NotNullAttribute.
This approach does not work for the broader case where you want to ensure that a method is called with an enumerable. In this case Igal Tabachnik's additions to Annotations are great.

Assuming you are using Visual Studio 2013/2012 (I'm only aware of this feature in 2013 though) in the code analysis window you should be able to right click the message navigate to Suppress Message > In Source File or In Suppression File
Alternatively you can achieve the same effect by clicking the action drop down of the message in the Code Analysis window.

Why does the c# compiler still read compile code from unused methods?

Say I have two methods, one calls the other. The second method has code that will generate a compile time error. Since it's not called, why does the compiler still bother to process it?
void method1()
{
var i = 1;
//method2();
}
void method2()
{
int i = "2";
}

You can't be sure that someone else won't call that method at runtime using reflection. Your code MUST compile or it's not valid code - if it's never used... comment it out!
To expand on this:
Basically at compile time you are strongly typed - .NET will type check everything to ensure that what you are trying to do is legal, however, you can still throw exceptions at run time due to null references, bad casts etc etc.
Reflection is a component of the .NET framework that allows a developer to inspect the properties/fields/methods etc of an assemblies types via the assembly metadata
Reflection allows runtime type discovery and inspection of these types, it also allows invocation of methods/properties and modification of fields etc. (You can even create new generic types at runtime or completely new types altogether).
In other words, you can't guarantee that code you think won't be called, isn't called somewhere else at some point. For reflection to be possible, every bit of code needs to be valid and compilable
Whether that code will succeed at runtime is another story - but that's why we have exception handling.

And then what if somebody else uses your compiled code later on and decides to use it?
Even with private methods Reflection can complicate matters.
If you don't use it, lose it. (or at least comment it out)

Why CodeContracts Static Analyzer doesn't make warnings?

I have several user controls, that are subscribed to the event handler in another class.
I'm learning CodeContracts in C#, and I wonder, why does Static Analyzer allows writing code like this:
void MyUserControl_MouseEnter(object sender, MouseEventArgs e)
{
MyUserControl item = sender as MyUserControl;
item.DoSomething(); // I expect some warning here, because item can be null
sender.Equals(testObject); // This doesn't yield warning either
}
Here I have a potentially unsafe code, that can lead to null-reference exception.
I understand, that static analyzer probably cannot check, what will the actual type of sender be. But in case it cannot prove it, I expect some warning, like CodeContracts: Possibly calling a method on a null reference.
Or do I get some idea of contracts wrong? How can I get notified of errors like this?
UPD:
Yes, I did enable Implicit Non-Null Obligation as it was suggested in the answers, but I still don't get a warning from Static Analyzer. Also I tried to run Code Analysis with Microsoft All Rules rules set, also no warning. (But I'd prefer dealing with Code Contracts and perform some additional checks using Contract class, rather then with if-then-throw or something else)

You should enable "Implicit Non-Null obligations" in the static analyzer options (Project Options|Code Analysis).

"How can I get notified of errors like this?": Resharper will warn you in that case.
Code contracts will warn you that the object might be null if there is a "Requires" that the object be non-null. You're asking for an implicit "Requires" for an object dereference, which seems reasonable on the face of it, but which CC for whatever reason doesn't seem to provide.
The documentation at http://msdn.microsoft.com/en-us/library/dd264808.aspx says that it does enforce such an implicit contract. I'm looking into it further.
RedHat beat me to it. More detail: You should check the "Implicit Non-Null Obligations" box under "Static Checking" in the Code Contracts tab of your project properties.

I had a similar problem. I had to turn up the warning level slider on the same panel as the "Implicit Non-Null obligations" checkbox.

In properties page of your project on Code Analysis tab you can change Rules.