Trµman meint mit Codelänge übrigens sicherlich nicht die Größe der exe; die ist in der Tat vollkommen egal. Aber es gilt beim Programmieren das KISS-Motto: Keep it simple and stupid. Soll heißen: Je kürzer das Programm, desto unwahrscheinlicher sind Fehler, bzw. desto schneller ist es auf Fehler zu überprüfen. Und dieses Prinzip hat hier voll zugeschlagen.
Noch ein kleiner Tipp, seht euch mal das Thema Unit-Test an, wenn Interesse besteht, wie man professionell Fehler findet und vermeidet. In dem Fall würde man wohl die Hauptfunktion kapseln, sei es in eine Funktion oder eine Klasse. Dann, bevor man was programmiert, exakt spezifizieren, welches Verhalten bei welchen Eingaben erwünscht ist, sprich, wie soll die Ausgabe (Zielordner nach dem Vorgang) bei einer bestimmten Eingabe (Datenquelle, Parameter) aussehen. Dann konstruiert man eine Menge Testfälle (verschiedene Parameter, verschiedene Quellordner, ...) und die gewünschten Ausgaben dazu. Dabei legt man speziell Wert darauf, auch Testfälle mit ungültigen Eingaben zu erstellen. Es ist nämlich sehr einfach und wenig aufwändig, zu prüfen, ob ein Programm mit den Eingaben klar kommt, mit denen der Entwickler gerechnet hat. Viel interessanter ist aber, was das Programm mit Eingaben macht, an die der Entwickler nicht gedacht hat.
Mit einem eigenes geschriebenen Programm, oder auch manuell, wird dann jeder dieser Fälle geprüft.
Wenn die Funktion dann wirklich genau das tut, was sie soll, kann man sich deren Verwendung widmen. Entweder ein GUI, eine Konsolenanwendung, oder auch die Verwendung der Funktion als Teil in einem anderen Projekt.
Das Konzept kann man natürlich auch ausweiten; indem auch ein Unit-Test für die Oberfläche geschrieben wird. Also eine Dummy-Kopierfunktion, die nicht wirklich kopiert, sondern auf Testeingaben mit den passenden Ausgaben reagiert, um zu sehen, was das GUI daraus macht.
Speziell von Nutzen ist dieses Konzept, wenn mehrere Leute an einem Projekt arbeiten. Dann werden vor dem Programmieren schon die einzelnen Module anhand ihres Verhaltens exakt spezifiziert, ebenso wie die Schnittstellen natürlich. Oft arbeiten auch verschiedene Leute (mitunter gleichzeitig) an den Unit-Tests und der eigentlichen Entwicklung. Das hat den großen Vorteil, dass dem Test-Entwickler viell. andere Dinge einfallen, als die, die der Programmierer selbst testen würde.
Noch zum GUI: Man sollte nie zu viel Logik ins GUI einbauen. Als Beispiel sollte nicht nur das GUI z.B. Buttons disablen, wenn Eingaben nicht passen oder nicht vorhanden sind. Auch die aufgerufene Funktion selbst sollte nochmal alles auf Korrektheit prüfen. Man weiß nämlich nie, ob man die Funktion nicht mal nach einer Änderung von einem anderen Punkt im Programm aus aufruft, in einem anderen Projekt wiederverwendet, ... Und zu guter Letzt kann die Logik zum Sperren und Entsperren von GUI-Elementen recht komplex werden und dadurch fehleranfällig.
