Die Frage ist ein wenig zu umfangreich um Sie mal eben kurz zu beantworten.
Es gibt verschiedene Ansätze für die Planung eines neuen Programms.
Wichtig ist in jedem Fall, dass man sich anfangs darüber klar ist, was man genau entwickeln möchte und am besten auf dem Papier anfängt. Es gibt verschiedene herangehensweisen wie man Programme dann "entwirft". Dies wird zum Teil im Bereich Projektmanagement behandelt und hängt auch vom Programm ab (Siehe de.wikipedia.org/wiki/Entwurfsmuster). Im Normalfall entwickelt man zuerst eine Art Programmflow ala Flussdiagramm und dann ein Datenmodell welches zum Zweck des Programms passt.

Richtiger Aufbau eines Programm Codes
Es gibt keinen "richtigen" Aufbau. Jeder macht es wohl ein wenig anders. Wichtig ist nur, dass man versucht einerseits so "simple" wie möglich vorzugehen aber zeitgleich auch mögliche Erweiterbarkeit mit in Betracht zieht. Soll jemand später etwas hinzufügen oder ändern, sollte er nicht an 10 Stellen im Code etwas ändern müssen bzw diese Stellen auch noch suchen. Es gilt also ein gutes Daten bzw. Klassen Modell zu enwickeln.

Wie hält man seinen Code Sauber und Übersichtlich.

Das ist auch wieder Geschmackssache. Einrückungung, Absätze bzw. gute #Region Blöcke und Kommentare sind je nach Geschmack anders. Man sollte halt immer bedenken, wie finde ich selber etwas am schnellsten wieder. Die Gliederung sollte daher logisch sein, wie in einem Aufsatz oder deiner Ordnerstruktur am PC. Man sollte alles so strukturieren das man auch nach 3 Monaten etwas leicht wiederfindet.
Sauber heißt aber auch, dass man Option Strict On aktiviert, Fehlerbehandlung nicht einfach drauf klatscht und nicht mit Kanonen auf Spatzen schießt. Auch hier gibt es soviele Aspekte. Allein die Funktions und Namensbezeichnung (Notation) ist ein Bereich für sich.

Wie kann man Fehler vermeiden

Das ist eigentlich unmöglich. Man kann Sie nicht vermeiden und im Normalfall lernt man gerade aus selbigen.

Mono schrieb:

Allein die Funktions und Namensbezeichnung (Notation) ist ein Bereich für sich

Dazu ein paar Links:
msdn.microsoft.com/en-us/library/ms229042(v=vs.110).aspx
msdn.microsoft.com/en-us/library/h63fsef3.aspx
msdn.microsoft.com/en-us/library/0b283bse.aspx

Sonaca schrieb:

1. Wie wird ein Neues Programm geplant
   
2. Richtiger aufbau eines Programm Codes
3. Wie hält man seinen Code Sauber und Übersichtlich
   
4. Wie kann man Fehler vermeiden
   

1. Kommt ganz drauf an. In einer Firma mag es ein Kunde anstossen, der Chef, ein Mitarbeiter, was weiß denn ich. Und in einer Firma wird sicherlich anders geplant als in einem OpenSource-Team als bei einem Hobby-Bastler. Das Spektrum sinnvoller Planung geht wohl von Generalstabsmäßig bis hin zu einfach mal drauf los (auch letzteres kann in bestimmten Fällen tatsächlich die beste Form der Planung sein)
   Grad manche Hobby-Bastler wollen unbedingt sonstwie professionell sein, alles von anfang an richtig machen (was garnet geht), und führen Tagelange Threads mit Bitten um Vorschlägen, Einwänden, Alternativen, Bedenken, hinzugezogenen Artikeln aussm Internet, und, und, und... - und schreiben nicht eine Zeile Code . (Kategorie "Brainfuck" - ich komme noch dazu )
   
2. Kommt ganz drauf an. Da gibts zig Strategien für, viele mit Vor- und Nachteilen.
   Viele dieser Strategien kann man garnet verstehen, solange man nicht selbst Erfahrung gemacht hat, mit den Problemen, die sie lösen. Und oft werden sie mit Gewalt auf Probleme angewendet, für die sie garnet erdacht sind. Mit dem Erfolg, dass die Lösung ziemlich untoll ist, der Autor aber denkt, er sei toll der Software-Designer, und wisse nun, wie's geht (was ja bekanntlich noch falscher ist, als wenn man weiß, dass man nichts weiß).
   Ich bevorzuge, immer so simpel wie möglich anzufangen, und Komplexität immer erst dann zu integrieren, wenn sich zeigt, dass sie erforderlich ist.
   Manchmal zeigt sich das sehr früh, manchmal erst sehr spät. Und manchmal zeigen sich auch Irrtümer, dann wird Komplexität halt wieder rausgeworfen.
   Aber das ist nur eine allgemeine Meta-Strategie, und bringt nur so viel, wie man halt Erfahrungen sammelt. Also mit dieser Meta-Strategie kommt man dazu, die o.g. Strategien kennenzulernen, wenn man sie braucht. Und nochmal braucht man Erfahrung, um ühaupt einschätzen zu können "Also das hier geht doch eher in Richtung Kuddelmuddel - das muss doch eiglich einfacher möglich sein...". "Kuddelmuddel" ist eine Richtung von Fehlentwicklungen, "BrainFuck" nenne ich die andere, zB wenn der Versuch, Ordnung zu schaffen, so viel Neues hinzufügt, dasses am Ende dann doch nicht übersichtlicher geworden ist.
   
3. Beachte: "Sauber" und "Übersichtlich" sind 2 verschiedene Kategorien, genaugenommen ist Übersichtlich eine Unterkategorie von Sauber, weil unnötig unübersichtlicher Code ist nicht sauber (aber es gibt noch viele weitere Möglichkeiten dreckig zu coden).
   Also Unsauber ist jeder Code, den man verbessern kann ohne dass man die Verbesserung durch anders artige Nachteile erkaufen muss.
   Das ist ja ein generelles Problem, dass beim proggen viele Interessen zu vereinen sind: Schnelligkeit, Lesbarkeit, Sicherheit, natürlich Funktions-Umfang ... und oft kann man das eine verbessern um den Preis, dass anderes dafür sich verschlechtert.
   Wie gesagt: Unsauber ist Code, wenn man ihn eindeutig und nachteil-frei verbessern kann.
   Übersichtlichkeit: Generell gilt: Wenig Code ist übersichtlicher als viel Code. Kann man übertreiben, und auch super-komprimiert coden, dass dann auch keiner mehr durchblickt, aber zu 90% trifft zu: Wenn weniger dasselbe leistet, ists besser.
   Damit komme ich wieder zu meiner Meta-Strategie: Einfach mit einem kleinen Klumpen Code anfangen, und wenn der Bildschirm voll ist, dann anfangen zu überlegen, wie man Zuständigkeiten isolieren und auslagern, kann, wiederholungen in Schleifen packen, ganz allgemeines in eine Infrastruktur verlagern und und und - gugge CodeAufteilung
   Und immer bedenken: Alles, was hereingeholt wird - jede Zeile Code - verschlechtert Übersichtlichkeit. Also das Zufügen eines Ordnungssystems ist zunächstmal eine Verschlechterung, und muss seinen Gewinn erst noch erwirtschaften. Code is our enemy
   
4. halt Programmieren lernen, was sonst? Und das VisualStudio kennen. Und das Framework kennen. Und nochmal VisualStudio - wie man nämlich im Framework was findet, was man braucht. Und natürlich debuggen lernen. Und nochmal VisualStudio - nämlich wie das einen beim Debuggen unterstützt. VisualStudio richtig nutzen Und nochmal Programmieren lernen - nämlich Fehlermeldungen verstehen
   Also die Sprache, das VisualStudio, das Framework - das sind 3 total eng verflochtene Komponenten - keine ist brauchbar ohne die anderen beiden. Und man entwickelt sich in alle 3 Richtungen gleichzeitig, und da kommen wir wieder bei raus, dasses eine Sache von Erfahrung ist - Theorie und Rezepte sind zwar nützlich und notwendig (also haben schon ihren Stellenwert), sind aber alleine und ohne Erfahrung unrettbar unzulänglich.
   

Sonaca schrieb:

Wie wird ein Neues Programm geplant

In welchem Kontext planst Du dies?
Wenn Du in einer Firma Software entwickeln willst, solltest Du diese Fragen nicht mehr stellen müssen.
Wenn Du für Dich in Deinem Kämmerlein werkelst, fang klein an und starte ein Projekt ruhig mehrere Male.
Wichtig ist immer, einen klaren Plan zu haben.
Gut ist es, diesen aufzuschreiben.
Was soll mein Projekt tun, was soll es nicht tun? Dies ist sehr wichtig, denn wenn Du alles zulässt, manches aber nicht ausschließt, zumindest für die aktuelle Version, bist Du niemals fertig.
Üblicherweise fällt einem immer noch was ein, was in eine Version reingehören könnte, hier ist es wichtig, STOP sagen zu können und das TODO der nächsten Version zuzuordnen.
Mach Sicherungskopien Deiner Quellen, damit bei einem Crash noch alles da ist.
Und
Sammle Snippets. Leg die wohlsortiert ab, damit Du nicht lange suchen musst.
Wenn Du ein kleines Problem hast und Du hast eine wohlsortierte Snippetsammlung, hast Du die Lösung da oder Deine Sammlung wird um ein Snippet bereichert.
Zerlege Dein Problem in disjunkte Teilprobleme.
Löse jedes dieser Teilprobleme in je einem separaten Projekt (=> Snipetsammlung), und wenn alles einzeln funktioniert, füge die Snippets in einem neuen Projekt zusammen.

Der ObjectBrowser ist keine Bibliothek. Unter Bibliothek versteht man in .net was anneres.
Der ObjectBrowser ist die eine Referenz-Dokumentation (von zweien), die man verfügbar hat - die andere Doku ist MSDN. "Referenz" bedeutet: Was da drin steht, das ist verlässlich, und was da nicht drin steht, das gibts auch nicht.
Aber nochmal zu "Bibliothek" - das ist wichtig, und am Ende wichtiger als eine Snippet-Sammlung. (Also aufpassen - aber die Snippets deswegen nicht vergessen! )
Also Bibliotheken nennt man meist "Library" oder auch "Assembly".
Und eine Solution bindet mehrere Libraries zusammen, sowohl vorkompilierte, als auch das (oder die) Projekt(e), an dem (denen) man grad codet. Das woran man codet ist das HauptProjekt, die Libs helfen.
Und zu 2) - richtiger Aufbau des Programm-Codes gehört auch, dass man wiederverwendbaren Code so in einer (oder sogar mehreren) Helper-Dll organisiert, dasser auch in anderen Projekten verfügbar ist.
Also was du mit Snippets erreichst - dass derselbe Code mehrmals vorkommt, das erreichst du mit einer Helper-Bibliothek besser, nämlich den Code gibts dann nur einmal, und er wird mehrmals benutzt.

Aber das (sowohl Snippets als auch Helper-Dlls) geht jetzt ziemlich ins Stadium von mittel- bis fortgeschrittenen Programmier-Kenntnissen, bei Anfängern ist man froh, wenn sie die Visual Studio - Empfohlene Einstellungen umsetzen.

Also wenn du einen Marschplan haben willst, was alles lernen, und auch ungefähr welche Reihenfolge, gugge Datenverarbeitungs-Vorraussetzungen
Das empfehle ich sehr oft, und das hat den Schwerpunkt darauf, dass man vor allem lernt, sich zurechtzufinden, also gewissermassen, dass man lernt zu lernen.

Ich plane meine Programme generell in digitaler Form, da Papier mMn nicht dafür geeignet ist um die Ideen strukturiert darzustellen. Zum Beispiel wenn man anfängt seine Ideen aufzuschreiben, dann fallen einem gelegentlich Dinge ein, die an andere Stelle gehören und da ist dann meistens kein Platz mehr, vielleicht bin ich für Papier einfach nur zu blöd Ich nutze dann immer gerne Mindmaps, da ich die mit entsprechenden Apps auch unterwegs erweitern und bearbeiten kann. Irgendwann hab ich dann den Punkt erreicht und ich bin mir im klaren wie alles funktionieren muss, dann beginne ich zu schreiben.
Was mMn sehr wichtig ist, ist seine IDE so anzupassen, dass man effektiv und intuitiv damit arbeiten kann also dass man bspw immer beim Programmieren auf die Todo-Liste sehen kann.
Um den Überblick nicht zu verlieren was ich schon alles gemacht habe nutze ich gerne Klassendiagramme und ToDo-Listen.
Tja und zur Sauberkeit des Codes würde ich sagen, dass das einfach Übungs- und Konzentrationssache ist. Aber es kann schon deutlich helfen wenn man Regions nutzt oder Methoden und Variablen/Properties klar trennt bspw indem man Variablen/Properties oben hinschreibt und die Methoden unten.
Generell ist es auch zu empfehlen für jede Klasse eine eigene Datei zu nutzen, wenn man 20 Klassen in einer Datei hat wars das erstmal mit der Übersicht.
Zum Thema Fehlervermeidung: Man kann Fehler nicht immer verhindern, aber genau da liegt auch ein positiver Aspekt, du lernst wie du Fehler findest, behebst und somit vorbeugst.
Zum Lernen kann es auch helfen wenn du dir einfach wichtige Sachen, wie in der Schule, einfach herausschreibst und irgendwo abheftest, so schreibst du dir dein eigenes kleines Programmierhandbuch und das beste dran ist, dass es für dich verständlich ist.

Aber du musst denke ich selber herausfinden wie du am Besten lernst, ich bspw lerne am Liebsten abends vorm Schlafen gehen(zwar Schulstoff, aber ist ja nur ein Beispiel )

Sonaca schrieb:

sowie vielleicht auch noch weitere Tutorials oder Lernprojekte in form von "Finde den Fehler"
was es "Lehrlingen" wie mir Einfacher gestaltet könnte einen Einstieg in die Große VB.NET Welt zu Finden

Wäre sicher amüsant sowas hier einzuführen, aber das ist auch wieder ein anderes Thema Aber Tutorials gibt es eigentlich recht viele, wenn auch eher zu fortgeschrittenen Themen.

LG

Edit: So im Nachhinein ist mein Post etwas unübersichtlich geworden, aber darüber kann man hoffentlich hinweg sehen.

Sonaca schrieb:

wo ich diese denn am besten ablegen kann,

Wo immer es Dir gefällt.
Ich hab einen solche Struktur: C:\Projekte\_Snippets\THEMA\UNTER_THEMA und C:\Projekte\_SnippetsComplex\THEMA

Sonaca schrieb:

zu "übersetzen" ?

im Allgemeinen Ja, Du musst den Variablen den richtigen Typ zuweisen bzw. den Typ casten.
Bei Verwendung von OCX'en gibt es üblicherweise Wrapperklassen, die die richtigen Typen mitbringen.
Bei Office-Anwendungen gibt es alte und neue Wrapper, bei den alten kommt da meist eine LateBinding-Exception, neuere bieten die korrekten Typen, auf die gecastet werden kann.

Nach Strict On Übersetzen ist eine Super-gute Idee!

Nur mit Code-Fetzen ists meist schwierig bis unmöglich, erfolgreiche Verbesserungen vorzuschlagen

VB.NET-Quellcode

1. Dim fileInfoElement = doc.Root.Element("FileInfo")
2. Dim file = fileInfoElement.Element("File").Value
3. Dim hash = fileInfoElement.Element("Hash").Value

Hier weiß zum Beispiel niemand, welchen Datentyp doc hat - kannst du uns den noch mitteilen?
Generell ist gut - nochmal zur Eingangsfrage - kurze Methoden zu schreiben - ab 20 Zeilen ists verdächtig, ob die gut designed sind. Kann sein, dass lange Methoden i.O. sind - wenn halt viel zu tun ist, aber zB 98% meiner Methoden liegen unter 20 Zeilen.
Und wenn man dann kleine Methoden hat, kann man die auch einfach komplett posten, und eine vollständige Methode redigiert sich ungleich besser als so "verlorene Fetzen".
Am besten sind autarke Methoden, also solche, die auf keinerlei Klassenvariable zugreifen, sondern alles, was sie brauchen als Parameter übergeben bekommen, und alles, was sie bewirken, als Rückgabewert returnen.
Also ein klares Input/Output-Prinzip.
Wie gesagt - das sind die besten Methoden, ist aber oft nicht umsetzbar, jdfs nicht ohne Brainfuck (wie gut, dass du nun weisst, was ich damit meine) .
Also: sag uns den Datentyp von doc, oder gib uns die ganze Methode, wo's hopefully draus hervorgeht

Sonaca schrieb:

VB.NET-Quellcode

1. Dim serverUrl As String = cdoc.Root.Element("url").Value

Wenn ich das recht sehe, ist Value ein Object, das musst Du mit .ToString zu einem String casten.

Sonaca schrieb:

auf den 2. Knoten zu legen

Frag Frau Google nach .net xdocument select node.
Sieh mal hier rein, hab aber keine Angst vor C#.

RodFromGermany schrieb:

Wenn ich das recht sehe, ist Value ein Object, das musst Du mit .ToString zu einem String casten.

Nein, cdoc ist ein XDocument, cdoc.Root ist ein XElement, XElement(string) ist wiederum ein XElement, und XElement.Value ist ein String.

@Sonaca: Es gibt überhaupt kein Problem - was soll da nach Strict Off übersetzt werden - ist doch alles typ-konsistent?

Übrigens, wie man sofort die Datentypen von derlei Ausdrücken herausfindet: Video-Tut: Welchen Datentyp hat das Objekt?

Nochmal zum Problem: hat mit Strict On garnix zu tun

Bekomme es scheinbar nicht gebacken einen verweis auf den 2. Knoten zu legen -.-"

Naja, jetzt bin ich wieder gemein: Ich sehe keinerlei Code, der überhaupt versuchen würde, auf einen 2. Knoten zuzugreifen - du hast nun jede Menge Code gepostet, nur die Methode, die das Problem hat, scheint nicht dabei.

Das Gute daran, alles ordentlich zu typisieren ist ja, das alle Framework Klassen Beschreibungen haben und das es "Intellisense" gibt.
Schreibst du also xDoc.Root.Element("file"). schlägt dir VS ja alles mögliche vor.
Bei .Value siehst dann auch den Typ. Value ist String btw.

Dein Problem mit dem 2. Knoten löst sich u.a. so:



//EDit

@EDR Er sagt ja Zeile 23/24