Archiv der Kategorie ‘Programming‘

C# ?? Operator

Freitag, den 2. Mai 2008

Einige von euch können sich sicher an meinen Artikel über den C# Operator ?? erinnern. Hier noch eine kleine Ergänzung. Mit dem ?? Operator kann man sich gerade bei den lästigen Abfragen ob ein Objekt null ist viel Schreibarbeit sparen. So kann man zum Beispiel folgendes Codestatement

if(name == null) {
   Console.WriteLine("Unspecified");
} else {
   Console.WriteLine(name);
}

mit dem ?? Operator folgendermassen schreiben

Console.WriteLine(name ?? "Unspecified");

Irgendwie recht sexy oder nicht? Sogar bei Objekten die mit Lazy evaluation erzeugt werden, kann der Code sehr sexy gehalten werden (siehe unten)

public User TheUser
{
  get { return theUser ?? (theUser = new User()); }
}

Laut der C# Spezifikation ist der ?? Operator sogar threadsafe. Hier eine sehr schöne Erklärung von Ian Griffiths

The C# 2.0 specification says that the left hand side is evaluated, and if that’s non-null, that becomes the result.

It’s worded such that it says the left hand side is evaluated once, and the right hand side is either not evaluated at all, or it’s evaluated once.

The race condition would only arise if the left hand side were evaluated more than once. Since it’s only evaluated once, and the resulting value is only used if it’s non-null, you’ll only ever get a non-null value from the left hand side.

http://www.interact-sw.co.uk/iangblog/

Constraint Modifiers

Sonntag, den 27. April 2008

Heute möchte ich mich ein bisschen mit der Frage beschäftigen, was Constraint Modifiers sind. Constraint Modifiers sind eigentlich nichts mehr als syntaktische Zückerchen in der Programmiersprache um die Lesbarkeit des Codes zu verbessern. So wurde zum Beispiel im aktuellen Release von NUnit die Constraint Modifier Syntax eingeführt. Dies ermöglicht dem Programmierer anstatt

Assert.AreEqual(expectedValue, actualValue);

folgendes zu schreiben:

Assert.That(actualValue, Is.EqualTo(expectedValue));

Diese Syntax ist nicht nur besser lesbar sondern auch sehr flexibel. Bei NUnit wurden für die Constrant Modifiers sogenannte Syntaxhelperklassen eingeführt die eigentlich nichts weiteres als Factories sind, die Klassen des Types IConstraint erzeugen. Im obigen Beispiel ist die Klasse Is der Syntaxhelper und die Methode EqualTo die Factorymethode die ein Objekt des Types EqualConstraint (implementiert das Interface IConstraint) erzeugt.

Kombiniert man die Constraint Modifier mit Methodchaining so ergeben sich wirklich sehr "sexy" Ausdrücke wie:

Assert.That(actual, Is.Not.EqualTo(expected))

Assert.That(10.0/3.0, Is.EqualTo(3.33).Within(0.01f));

Assert.That(actual, Has.Length(expected));

Mehr zu Constraint Modifiers findet ihr unter folgendem Link:

http://www.nunit.org/index.php?p=constraintModel&r=2.4.7

Java unter Vista: Microsoft arbeitet mit Eclipse Foundation zusammen

Dienstag, den 25. März 2008

Da soll noch einer sagen, Microsoft mache nichts für die OpenSource Community ;)

Wie Sam Ramji, Director der Open Source Software Labs bei Microsoft in einem Blogeitrag auf Port25 bestätigt, wird Microsoft künftig die Eclipse Foundation darin unterstützen, Entwicklern mit dem Eclipse-Framework die Möglichkeit in die Hand zu geben, Java-Anwendungen mit nativen Vista-Look-&-Feel zu programmieren.

Im Detail will Microsoft hierzu aktiv Support durch seine Engineering Teams und die Open Source Software Labs bereitstellen, um die Entwicklung am Standard Widget Toolkit (SWT) weiter voranzutreiben. Hierzu soll der von Steve Northover entwickelte Prototyp weiter ausgebaut werden, um noch besser mit der von der Windows Presentation Foundation (WPF) bereitgestellten API kommunizieren zu können.
Aus Sicht von Sam Ramji sei diese Kollaboration nur ein weiterer logischer Schritt auf dem Weg, Java unter Windows zu ermöglichen, basierend auf den positiven Erfahrungen, die man aus der vor zwei Jahren begonnenen Zusammenarbeit mit JBoss schöpfen konnte.

Nach Analysten von IDC sei dies auch ein weiterer Schritt in Richtung Open Source – wenn auch ein sehr kleiner. Die Zusammenarbeit mir der Eclipse Foundation könnte sich dabei zu einem Meilenstein entwickeln, wenn es Microsoft damit gelänge, auch in den Köpfen seiner Community und seiner Investoren das Bewusstsein für Open Source zu schärfen.

Quelle: http://it-republik.de/dotnet/news/

Resharper

Dienstag, den 11. März 2008

Ich bekam heute gerade eine fachgerechte Einführung in das von JetBrains entwickelte Add-in für Visual Studio mit dem Namen Resharper. Resharper erleichter das Entwickeln mit Visual Studio 2005 oder höher mit einigen wirklich nützlichen Tools und Kniffen.

Was kann überhaupt Resharper?

Die Verbesserungen die Resharper mitbringt können in folgende Kategorien unterteilt werden:

  • Codeanalyse für C#
  • Code Templates
  • Xaml Support
  • Navigation und Suche
  • Coding Assistenten
  • Code Refactoring
  • Code Generierung
  • Code Formatierung
  • Cross-Language Funktionalität
  • XML Support
  • ASP.NET Support
  • Unit Testing
  • NAnt and MS Build Scripts Editierung
  • Offene API

Codeanalyse für C#

Resharper macht konkrete Vorschläge bereits während der Eingabe und zeigt diese dem Entwickler an. So schlägt Resharper im untenstehenden Screenshot z.B. vor die Basisklasse IEnumerable<string> als Typ für den Methodenparameter zu nutzen.

suggestion_1

Resharper bietet ebenfalls sogenannte Quickfixes an. Diese Quickfixes sind konkrete Vorschläge wie ein bestehendes Problem oder eine Unschönheit gelöst werden könnten.

Error_R2

Resharper überprüft bereits während der Eingabe auf mögliche Wertefehler und Nullreference-Exceptions. So können Fehler die vielleicht in der Hitze des Gefechts übersehen würden schon gar nicht entstehen.

valueAnalysis

Code Templates

Resharper bietet vorgefertigte Templates die während der Eingabe viel Schreibaufwand ersparen können. Neben den in Visual Studio üblichen Templates wie zum Beispiel für den foreach Loop gibt es noch zahlreiche weitere nützliche Templates.

Code Formatierung

Resharper bietet erweitertes Syntaxhighlighting für den Code an wie zum Beispiel das Highlighten von Feldern, lokalen Variablen, Typen etc. Nebenbei bietet Resharper Shortcuts für das Formatierung des Quellcodes oder das Reorganisieren der Imports an. Resharper ermöglicht das automatische Layouting von Membervariablen und Typen nach vordefinierten Layouts.

Coding Assistenten

Resharper kann sogenannte Smart-Code Completion, d.h. wenn eine Methode aufgerufen wird, zeigt die Code Completion nur noch Elemente in der entsprechenden Klasse an, die überhaupt in Frage kämen um der Methode zu übergeben werden. Somit sind die Auswahllisten viel übersichtlicher.

code_completion_smart_C

Resharper unterstützt die Smartactions. So erkennt zum Beispiel Resharper im untenstehenden Code, dass es besser wäre die Stringformatschreibweise zu verwenden und schlägt dies vor. Falls man es annimmt, sieht dann der Code folgendermassen aus (siehe Screenshot 2).

context_action_C_1

context_action_C_2

Resharper unterstützt sogenannte Parameterinfo. Dies sind zusätzliche und übersichtlich aufbereitete Informationen über die Parameter einer Methode oder eines Konstruktors.

ParameterInfo_R2

Weitere Infos

Resharper bietet noch viele weitere Möglichkeiten. Jene die mehr darüber erfahren möchten, können die weiteren Informationen auf folgender Webseite beziehen:

http://www.jetbrains.com/resharper/features/index.html

Und was kostet der Spass?

image

C#2008 Sprachfeatures Teil 3: Extension Methods

Montag, den 18. Februar 2008

Wie ihr sicherlich alle wisst, ist es nur sehr mühsam möglich kompilierte Klassen mit zusätzlicher Funktionalität zu bestücken oder etwa Funktionalität wieder wegzunehmen. Extension Methods erlauben in C#2008 an bestehenden Klassen oder sogar vorkompilierten Typen zusätzliche Funktionalität zu “injezieren” ohne den Code selber zu besitzen.

Einschränkungen

  • Extension Methods verändern nicht die kompilierte Codebasis sondern fügen nur Member einem Typ hinzu, der im Kontext der Applikation läuft.
  • Extension Methods müssen in einer statischen Klasse definiert werden. Die Methode selber muss auch mit dem Keyword static deklariert werden.
  • Extension Methoden müssen im ersten Parameter der Methode immer mit dem Keyword this und der Klasse (z.B. this Object)auf den die Extensionmethode angewendet werden soll, implementiert werden.
  • Jede Extensionmethode kann entweder über eine korrekte Instanz im Memory oder statisch über die definierende Klasse angesprochen werden!

Machen wir direkt ein Beispiel. Wir wollen, dass jede Klasse die von System.Object ableitet in Zukunft eine Methode DoPublicRelationForTracelight() besitzt, die auf der Konsole eine Meldung der Form “Tracelight.ch rockz!!!” ausgibt. Dazu definieren wir folgendes

    static class TracelightPublicRelationExtensionMethods {
        public static DoPublicRelationForTracelight(this Object obj) {
            Console.WriteLine("Tracelight.ch rockz!");
        }

        // More methods related to tracelight.ch public relations...
    }

Falls wir nun die Extensionmethoden über den zugehörigen Namespace in unser Programm einbinden, kann jede Klasse die von System.Object ableitet die Methode DoPublicRelationForTracelight() ausführen, als ob die Methode direkt auf dem System.Object definiert wurde.

Somit ist also folgendes möglich:

   Object myObject = new Object();
   myObject.DoPublicRelationForTracelight();

   int myInt = 42;
   myInt.DoPublicRelationForTracelight();

   // and many more

Auch kann die statische Methode direkt über die Klasse aufgerufen werden. Also zum Beispiel so:

   int myInt = 42;
   TracelightPublicRelationExtensionMethods.DoPublicRelationForTracelight(myInt);

Im Hintergrund macht eigentlich der Kompiler auch nichts anderes als die statische Methode aufzurufen und eine Referenz des aufrufenden Objektes zu übergeben. Dies passiert einfach im Hintegrund.

Skope
Extensionmethoden haben keinen direkten Zugriff auf die Felder des Typs der von der Methode erweitert wird. Folgender Code ist also nicht möglich:

   public class TracelightTvSpot {
      public string TvSpotMessage ;

      public string MakeAggressivPublicRelationForTracelight() {
         return TvSpotMessage;
      }
   }

   public static class TracelightPublicRelationExtensionMethods  {
       public static string MakeMoreAggressivSpot(this TracelightTvSpot spot) {
           return TvSpotMessage + "! For real!!!";
       }
   }

Die obige Extensionmethode kann aber folgendermassen umgeschrieben werden:

   public static class TracelightPublicRelationExtensionMethods  {
       public static string MakeMoreAggressivSpot(this TracelightTvSpot spot) {
           return spot.TvSpotMessage + "! For real!!!";
       }
   }

Spezielles
Die Extensionmethoden werden bei der Verwendung durch Intellisense mit einem speziellen Symbol gekennzeichnet, damit sie von den Klassen- und statischen Methoden unterschieden werden können. Das Symbol sieht folgendermassen aus:

Extensionmethode

Die Extensionmethode müssen explizit über die Library die die Extensionmethoden definiert über das using Statement eingebunden werden. Sonst können sie nicht benutzt werden.

Viel Spass beim ausprobieren…

Kompilieren von Javacode in einem Javaprogramm

Donnerstag, den 14. Februar 2008

Ein sehr interessanter Artikel:

With the new Compiler API introduced in the JDK SE 6 it is possbile to compile Java code in a Java program.

You start by making an instances of Java Compiler and Java File Manager…[more]

C#2008 Sprachfeatures Teil 2: Automatische Properties

Freitag, den 25. Januar 2008

Ihr kennt sicherlich das mühsame Erstellen und Tippen von Properties für reine Datenhaltungsklassen. Will man unter C#2005 ein Property in einer Klasse modellieren, so muss man eine private Membervariable und ein zugehöriges Property mit Getter und Setter implementieren. Dies sieht dann in etwas so aus:

   private string _myProperty;

   public string MyProperty {
      get { return this._myProperty; }
      set { this._myProperty = value; }
   }

Man kann sich vorstellen, dass dieser Prozess bei Klassen mit mehreren Properties sehr umständlich ist! In C#2008 gibt es jetzt aber automatische Properties. Das obige Codesegment kann in C#2008 folgendermassen ausgedrückt werden:

   public string MyProperty { get; set; }

Wie man dem obigen Codeausschnitt entnehmen kann, muss man nur den Accesmodifier, den darunterliegenden Datentyp, den Propertynamen und einen leeren Get und Set Teil erstellen. Zur Kompilierzeit wird dem Property ein privates Feld und eine dazugehörige Implementation hinzugefügt (dies alles unter der Haube).

Einschränkungen
Es ist nicht möglich read-only oder write-only Properties zu definieren. Also folgende Codesegmente sind nicht erlaubt:

   public string MyProperty { get; }

oder

   public string MyProperty { set; }

Ebenfalls ist es nicht möglich in einer Klasse die ein automatisches Property deklariert auf die darunterliegende private Membervariable zu zugreifen, da das Feld ja erst zur Kompilierzeit quasi “induziert” wird. Die Klasse selber muss also immer die Propertysyntax brauchen. Z.B.

class MyExampleClass{
   public string MyProperty { get; }

   public override string ToString() {
      return string.Format("Tracelight.ch rocks! {0}", MyProperty);
   }
}

Eine weitere Einschränkung liegt darin, dass die automatischen Properties immer den Defaultwert des darunterliegenden Datentypes haben und nicht auf einen anderen Defaultwert initialisiert werden können. D.h. Referenzen sind immer null während z.B. Integer den Wert 0 haben usw. Will man den Properties beim Erstellen der Klasse einen Wert zuweisen, so muss dies über den Konstruktor der Klasse geschehen. Folgendes Beispiel demonstriert dies:

class MyClass {
   public string MyProperty { set; get; }

   public MyClass(string mypropValue) {
      MyProperty = mypropValue;
   }
}

Zugriff einschränken
Es ist möglich auch bei automatischen Properties dem Getter und Setter unterschiedliche Accessmodifier zu geben. Folgendes Codesegment sei gegeben:

   private string _myprop;

   public string MyProperty {
      get { return _myprop; }
      protected set { _myprop = value; }
   }

Dies kann unter C#2008 folgendermassen dargestellt werden:

   public string MyProperty { get; protected set; }

Somit ist es also nur aus ableitenden Klassen das Property MyProperty zu setzen.

Viel Spass

C#2008 Sprachfeatures Teil 1: Typisierte lokale Variablen

Montag, den 21. Januar 2008

Heute möchte ich euch die neuen typisierten lokalen Variablen von C#2008 etwas näher bringen. Typisierte lokale Variablen können in der neuen C# Spezifikation nun implizit angegeben werden durch das Keyword var.

In der C#2005 oder C#2.0 Spezifikation musste man noch lokale Variablen gemäss dem untenstehenden Codeausschnitt deklarieren:

   private void MyMethod() {
         int myLocalInt = 0;
         int myLocalBool = false;
   }

Neu ist es möglich durch das Keyword var eine lokale Variable zu deklarieren und der Kompiler wird automatisch den darunterliegenden Datentyp auf Basis des Initialwertes benützen. D.h. der Kompiler erkennt im untenstehenden Codesegment z.B. false als Boolean und wird myLocalBool automatisch als Boolean definieren.

   private void MyMethod() {
         var myLocalInt = 0;
         var myLocalBool = false;
   }

Dies funktioniert sogar mit komplexeren Datentypen oder in Loops, wie das das untenstehende Codesegment zeigt:

   private void MyMethod() {
         var myLocalArray = new int[]{1,2,3,4};
         var myLocalComputers = new List();
         var myLocalMacBook = new MacBookPro();

         foreach(var comp in myLocalComputers) {
              Console.WriteLine("My treasure: {0}", comp);
         }
   }

Ebenfalls ist es möglich implizit typisierte lokale Arrays zu erstellen über folgende Syntax:

   private void MyMethod() {
         var a = new[] {1, 2, 3, 4}; // int array
         var b = new[] {1, 1.2, 1.6, 2.5}; // double array
         var c = new[] { new MacBookPro(), new MacBookPro()}; // macbook pro array
   }

Was man nicht kann

  • Mit var deklarierte lokale Variablen auf Null setzen.
     var myObj = null;
  • Variablen die mit var deklariert wurden keineWerte zuweisen.
     var myData;
  • Implizite Arraydeklaration mit Mischtypen.
     var d = new[] {1, "eins", false};
  • Implizite Nullabletypes.
    var? car = new Car():
  • Deklaration von Feldern in Klassen mit var

Oh nein sind wir jetzt im Skriptingzeitalter?
Soweit kann ich euch beruhigen: Implizit typisierte Daten sind streng typisierten Daten! Das heisst es kann nicht wie bei einschlägigen Skriptsprachen ein anderer Wert einer lokal typisierten Variable zugewiesen werden! D.h. ein Typ

   var myInt = 0;

Kann nicht im späteren Verlauf anderen Datentypen zugewiesen werden. Dies wird vom Kompiler sichergestellt.

Warum soll ich das brauchen?
Naja ich denke man sollte dieses Feature so wenig wie möglich brauchen. Denn falls man später den eigenen Code für Bugfixing wieder heranziehen muss, kann es ganz schön verwirrend sein den entsprechenden Datentyp herauszufinden. Umso schwieriger wird es wenn man den Code eines Kollegen analysieren muss.

Das Keyword var hat vor allem seine Daseinsberechtigung im Umgang mit LINQ. Denn bei LINQ abfragen, weiss man nicht genau, was für ein Datentyp aus der Abfrage herausgeht. Dann deklariert man einfach einen Datentyp mit var und hat dann eine typisierte Variable die implizit durch die LINQ Abfrage definiert ist.

Richtiges Invoke von UI Controls

Samstag, den 19. Januar 2008

Zu diesem Thema gibt es meiner Meinung nach im Netz nicht viel schlaue Links und Hinweise, da wollte ich mal ein bisschen aufräumen. Aber zuerst einmal um was es da genau geht.

Wenn man mit dem Visual Studio ein GUI erstellt und auf diesem GUI zum Beispiel eine Textbox hinzufügt , diese GUI dann kompiliert und ausführt, dann laufen alle GUI Operationen im sogenannten Main- oder auch UI-Thread. Dieser Thread ist zuständig für das richtige Updaten, Zeichen etc. der Benutzerelemente.

Programmiert man eine Funktion die viel Rechenzeit braucht und führt diese Funktionen in einem neuen Thread aus, so muss man die Crossthreadingcalls beachten, wenn man aus dem neu erstellten Thread auf die Benutzerelemente des Mainthreads zugreifen will (um zum Beispiel in der Textbox einen Text hinzuzufügen). Denn greift man ohne zusätzliche Sicherheit einfach aus dem zweiten Thread auf das Text Property der Textbox zu, so kann aus unter Umständen dazu führen, dass zwei Thread s zur gleichen Zeit auf die Textbox zugreifen und es kommt zu unvorhersagbaren Verhalten auf dem GUI. Doch wie kann man dies umgehen?

Die Lösung heisst Delegates und Control.Invoke().

Nehmen wir an wir haben eine Methode MyMethod du jedesmal wenn Sie von einem anderen Thread aufgerufen wird auf dem GUI den Text eines Labels myControl auf “Vom Thread aufgeweckt!” setzt. Damit die Methode MyMethod threadsafe aufgerufen werden kann, muss folgendes Codesegment implementiert werden:

Methode ohne Parameter und zugehöriges Delegate

Private delegate void MyMethodDelegate();
Private void MyMethod() {
	if(myControl.InvokeRequired) {
		myControl.Invoke(new MyMethodDelegate(MyMethod));
		return;
	}
	// Add rest of the code here
        myControl.Text = "Vom Thread aufgeweckt!";
}

Der Ablauf des obigen Codesegments ist folgendermassen. Man definiert ein Delegate (quasi typensicherer Methodenpointer), das später auf die Methode MyMethod “zeigt”. Danach prüft man in der eigentlichen Methode über myControl.InvokeRequired ob das Control aus einem anderen Thread angesprochen wurde. Ist dies der Fall, so führt man ein Invoke auf myControl über myControl.Invoke mit dem Delegate MyMethodDelegate durch und übergibt dem Delegate die aufgerufene Methode (hier MyMethod) als Parameter. Nach dem Invoke verlässt man die Methode direkt wieder über die Anweisung return;. Der eigentliche Zugriff auf das Control myControl erfolgt dann im Codeblock // Add rest of the code here.

Die Logik dahinter ist, dass durch den Aufruf von Inkvoke auf das Control, wird über das Delegate die Methode nach einmal aufgerufen und der zugreifende Thread meldet sich quasi beim UI-Thread an und wartet, bis dieser den Zugriff auf das Control frei gibt. Sobald dies der Fall ist, kann der Thread in die Methode und dieses Mal ist das Flag InvokeRequired auf false gesetzt und es wird nur der eigentliche Codeblock bei // Add rest of the code here ausgeführt.

Doch wie funktioniert das Ganze, wenn die Methode MyMethod ein oder mehrere Parameter entgegen nimmt? Hier ist der Codeauszug:

Methode mit Parameter und zugehöriges Delegate

Private delegate void MyMethodWithParameterDelegate(string message);
Private void MyMethodWithParameter(string myParameter) {
	if(myControl.InvokeRequired) {
		myControl.Invoke(new
MyMethodWithParameterDelegate(MyMethodWithParameter), new object[]{ myParameter });
		return;
	}
	// Add rest of the code here
        myControl.Text = myParameter;
}

Der Ablauf ist wieder genau gleich, einfach wird in diesem Fall ein Delegate mit Parameter spezifiziert und beim Invoke wieder ein Delegate erstellt und die Parameter für die Methode als Objektarray übergeben. That’s it!

Viel Spass beim Ausprobieren…

DataSet Connection String auslagern

Mittwoch, den 16. Januar 2008

Falls ihr schon einmal mit Visual Studio 2005 ein DataSet erstellt und genützt habt, kennt ihr sicherlich bereits die Vorzüge aber auch Nachteile dieser ADO.NET Klasse. Ein Nachteil ist zum Beispiel, dass der integrierte Wizard im VS2005 den ConnectionString für die Datenbankverbindung in ein Property in den Ressourcen ablegt und beim Erstellten des typisierten DataSets im generierten Code auf dieses Property verweist. Wie kann man aber vorgehen, um den ConnectionString einfach in eine Konfigurationsdatei auszulagern?

Dazu erzeugt man ein App.config Datei und fügt folgendes Codesegment in die Sektion ein:

App.config

<connectionStrings>
<add name="MyConnectionString"]." connectionString="Data
Source=localhost;Initial Catalog=database;Integrated Security=True"
providerName="System.Data.SqlClient" />
</connectionStrings>

Beim Attribute connectionString fügt man den Wert des ConnectionString Properties aus der Ressourcendatei ein. Ebenfalls muss ein sinnvoller Name für den ConnectionString-Eintrag unter name eingetragen werden. Danach merkt man sich den Namen des ConnectionString-Properties in der Ressourcendatei und fügt einen gleichnamigen Eintrag in die Datei Settings.Designer.cs als Public-Property gemäss untenstehendem Code ein:

Settings.Designer.cs

public string MyConnectionString
{
get
{
return (System.Configuration.ConfigurationManager.
ConnectionStrings["MyConnectionString"].
ConnectionString);
}
}

Damit auf den Namespace System.Configuration zugegriffen werden kann, muss nur noch das entsprechende Assembly über den Referencedialog zum aktuellen Projekt hinzugefügt werden. Danach kann man den ConnectionString-Eintrag in den Ressourcen löschen, das Projekt kompilieren und fertig.