Fast jeder, der die Überschrift liest, wird jetzt denken “Der Verfasser spinnt”.
Viele Linux (Suse)-Nutzer kennen bestimmt das Problem, dass Festplatten, vorallem auf NTFS formatierte, von Linux (Suse) nicht erkannt werden. Es erscheint eine lange und komplizierte Meldung, die die Überschrift “Cannot mount Volume” trägt.

Falls Ihr auch schonmal den Fall hattet, dass eure Exe einfach zu groß ist und Ihr diese verkleinern möchtet, damit sie z.B. auf eine Diskette passt, dann habe ich hier ein paar Tipps für euch:

1.) Mit Icarus kann man bei Delphi-Projekten nach ungenutzen Units suchen und diese anschließend entfernen, um dadurch die Exe zu verkleinern:

http://www.peganza.com/products_icarus.htm

2.) Eine weitere Möglichkeit ist die Relocation-Tabelle aus einer Exe zu löschen, die in den meisten Projekten nicht benötigen wird. Delphi packt diese immer in die Exe rein.
Hierfür kann man z.B. StripReloc benutzen:

http://www.innosetup.com/striprlc.php

3.) Natürlich kann man auch die BPL-Dateien auslagern.
Diese werden dann beim Start des Projekts geladen und sind nicht in der Exe-Datei mit reingepackt.
Vor allem, wenn man mit vielen verschiedenen Komponentensammlungen arbeitet, ist dies eine gute Möglichkeit die Exe-Datei kleiner zu bekommen.

4.) Image-Dateien extern auslagern und erst in den Speicher laden, sobald sie angezeigt werden sollen.

Eine von uns bisher eingesetzte Methode, die ich allerdings inzwischen nicht mehr empfehle, wäre Exe-Packer wie ASPack oder UPX zu verwenden.
Dies ist zwar sehr effektiv um die Exe-Datei kleiner zu bekommen, bringt aber auch Nachteile ( gefunden bei dem Link von StripReloc ):

• Upon startup of a compressed EXE/DLL, all of the code is decompressed from the disk image into memory in one pass, which can cause disk thrashing if the system is low on memory and is forced to access the swap file.
  In contrast, with uncompressed EXE/DLLs, the OS allocates memory for code pages on demand (i.e. when they are executed).

• Multiple instances of a compressed EXE/DLL create multiple instances of the code in memory.
  If you have a compressed EXE that contains 1 MB of code (before compression) and the user starts 5 instances of it, approximately 4 MB of memory is wasted.
  Likewise, if you have a DLL that is 1 MB and it is used by 5 running applications, approximately 4 MB of memory is wasted.
  With uncompressed EXE/DLLs, code is only stored in memory once and is shared between instances.

Dies sind die C# Coding Standards der Equitania Software GmbH.

Allgemeine Form:

hier wird beschrieben wie sie Ihrem Code eine 90-60-90 Figur verpassen.

- Bei Möglichkeit vermeiden mehr als eine Klasse
pro Namespace zu verwenden

namespace Geldverleih
{
    class Class1
    {
 
    }
 
    class SomeClass1
    {
 
    }
 
}

- Nicht zu viele Zeilen (am besten weniger als 500)
– Keine zu langen Methoden (weniger als 25 Zeilen)
– Nicht zu viele Parameter in einer Methode (weniger als 5)
– Keine überflüssigen Kommentare (Code sollte selbsterklärend sein)

- Zeilen übersichtlich gestalten (vor jeder { } einen Zeilenumbruch)

 private void button1_Click(object sender, EventArgs e)
        {
            if (intMyInt >= 10)
            {
                intMyInt -= (5);
 
            }
        }

Schreibweisen

In diesem Beitrag beschreibe ich, wie Code, formatiert in Camel- und PascalCase, auszusehen hat.

- CamelCase:

Als “CamelCase” bezeichnet man eine Art von Konvention.
Beispiele für CamelCase sind “iPod, MacBook, CloneCd, GameCube”.
Wie man unschwer erkennen kann, ist die Benutzung eines Großbuchstabens inmitten des Wortes gemeint.
(MacBook)
CamelCase wird bei lokalen variablen und Methodenparametern benutzt.

int number;
void MyMethod(int someNumber)
{}

- PascalCase:

PascalCase ist ähnlich wie CamelCase.
Während meistens von “lowerCamelCase” die Rede ist, bei der der erste Buchstabe klein geschrieben wird (iPod),
ist PascalCase lediglich eine andere Bezeichnung für “UpperCamelCase”, in welcher der erste Buchstabe groß geschrieben wird (MacBook)
PascalCase wird bei Typen und Methodennamen sowie bei konstanten Variablen verwendet.

public class SomeClass
 
{
 
const int DefaultSize = 100;
 
public SomeMethod()
 
{}
 
}

Benennung und Strukturierung:

Übersichtlichkeit steht ganz oben!
Nach diesem Motto gestalten wir unser Formular, damit es auch für andere Entwickler leicht zu verstehen ist.

Ungarische Notation:

Die ungarische Notation bedeutet die Verwendung von aussagekräftigen Bezeichnern
(z.B. int intZutatenMenge statt int intZM).
Es trägt dazu bei den Quellcode intuitiver zu gestalten, damit fällt es anderen Prorammierern leichter ihn zu lesen.

public int nMyInt;
public int nSomeInt;

-using Zeilen sinnvoll strukturieren, damit ein
übersichtliches Bild entsteht.

using System;
using System.Collections.Generic;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

Präfix

Dieser Beitrag erklärt, wie es Vorsilben schaffen, anderen Programmieren das Lesen und Verstehen Ihres Codes leichter zu gestalten.

Sie dienen z.B. dazu, Variablen zu erkennen, ohne den ganzen Code nach der deklarierung absuchen zu müssen, um herauszufinden, um welchen Typ es sich dreht.

 int someNumber;

Ich will euch eben die zwei (für mich) wohl wichtigsten Erweiterungen der neuen Version zeigen die mit dem Update hinzukamen, sowie auch ein Bug mit dem sich sehr viele Wordpress-Blogbesitzer derzeit rumschlagen.

Tiburon soll die neuste Entwicklungsumgebung aus dem Hause Codegear lauten.
In einer ersten Preview werden die ersten Neuerungen, in diesem Fall neue Komponenten, vorgestellt.

Hier gelangt Ihr zum Sneak Peek Video mit David I:

http://dn.codegear.com/article/38383

Was hat Microsoft mit ASP.NET 4.0 vor ? Das findet man hier:

http://www.heise.de/ix/Plaene-fuer-ASP-NET-4-0–/blog/artikel/113195