Anwenderprogrammierung in ANSI-C, Programmierung eines nicht banalen Anwenderprogramms

So eine Programmierung hat von der Seite des Programmierers gesehen drei Bereiche:

Bereich 1: die formale Programmierung von Bausteinen, Strukturierung und Bildschirmdarstellung

Bereich 2: der Dialog mit dem Anwender

Bereich 3: die eigentliche Datenverarbeitung

Der Bereich 1 ist sozusagen eine Kreativleistung. Man stellt sich vor, wie das Programm nach außen wirken soll, und strukturiert es innen möglichst "schön" durch. Es stört einen niemand dabei, die Datentypen auszufeilen und die innere Logik zu implementieren.

Der Bereich2 ist der "nervigste". Man soll dem Anwender ermöglichen, schnell und einfach seine Eingaben zu machen, muß aber formale und logische Fehler abfangen und plagt sich mit ellenlangen Dialogfunktionen herum. Nun, wie schon oben bemerkt, auch das wurde standardisiert, da läßt es sich leichter handhaben.

Dagegen ist der Bereich 3 die reinste Erholung.

Hier liegen nun alle Daten vor, die formale Struktur des Programms ist erledigt, und nun muß man nur noch vorhandene Daten, ohne vom Anwender gestört zu werden, verarbeiten.

Da werden die Funktionen wieder kürzer, Bierdeckel ist in Reichweite.

Auf die FIBU bezogen, ist natürlich das Hauptergebnis die BWA, die Erfolgsrechnung, das eigentliche Programmierziel.

Dieses hängt von steuerlichen und sonstigen Vorgaben ab und läßt sich programmiertechnisch-mathematisch nicht eingrenzen.

Der SKR03 hat 9 Kontenklassen, 0 bis 8. Nun sind aber nicht alle Konten dieser Kontenklassen ertragswirksam.

Dies schon deshalb nicht, weil man in den Kontenklassen normalerweise auch Verrechnungskonten unterbringt, die in der Ertragsrechnung nichts zu suchen habe. Eine andere Frage ist die Berücksichtigung der Umsatzsteuer. Es gibt da die Option vorsteuer-abzugsberechtigt, Kleinunternehmer oder eine Mischform aus beiden, getrennte Geschäftsbereiche, der eine ist vorsteuerabzugsberechtigt, der andere nicht.

Das läßt sich wie gesagt nach den Kontenklassen nicht automatisch ableiten.

Es bleibt daher nichts übrig, als die einzelnen Konten mit einem FLAG zu versehen, ob sie ertragswirksam sind oder nicht.

Oder man löst es so, daß man für jede Kontenklasse ein Array definiert, welches die gewünschten ertragswirksamen Konten enthält. Programmiert man selbst, kann man die Initialisierung und Pflege innerhalb der Programmierung durchführen, programmiert man allgemein, braucht es dafür wieder einen Dialog, wo die Konten entsprechend gekennzeichnet werden.

Eine andere Frage ist die der Historie. Es könnte ja sein, daß irgendwann umgestellt wurde, z. B. was die Umsatzsteuer betrifft, Umsatzsteuerpflicht ab dem Jahr X eingetreten ist. Dann muß man diese Konten noch mit Verfallsdaten kennzeichnen.

Darum, und im Hinblick auf zukünftige weitere Spezifikationen, spricht alles dafür, die einzelnen Konten des Kontenrahmens neutral zu lassen, denen keine FLAG zu verpassen, sondern die ertragswirksamen Gruppen als Arrays zu definieren, nach denen, abhängig vom Zeitraum, die BWA dann erstellt wird.

Was ist eine BWA im Zusammenhang mit einer EÜR? Addieren und subtrahieren, mehr nicht. Bilanziert man, muß man Abgrenzungskonten einführen etc., programmiertechnisch auch nix dolles, nur das muß ich nicht und zerbreche mir auch den Kopf nicht drüber.

Über die AfA muß man sich auch keinen Kopf machen, das ist Sache des Steuerberaters. Spricht man das vorher mit dem ab, kann man die Bestandskonten mit einem AFA-Prozentsatz belegen. So oder so keine große Sache.

Der Jahresabschluß kann ja während des Jahres nicht im voraus berücksichtigt werden, man denke da an Privatanteil vom PKW oder anteilige Umsatzsteuer. So gesehen ist jede BWA zur "Laufzeit" nur eine Annäherung, bis zum 31.12. der Jahresabschluß die Konten gegeneinander auflöst.

Also, die Sache nähert sich dem Ende. 90 Prozent sind erledigt.

Was jetzt noch anliegt, ist reine Datenverarbeitung, eine wirkliche Erholung gegenüber dem "Krieg mit dem Anwender".

Ich möchte zum Abschluß noch einmal auf ein Prinzip hinweisen beim Umgang mit indizierten oder dynamischen Listen oder Dateien, alles irgendwie im Prinzip dassselbe, das Problem

AUSGABE MIT BLÄTTERN

Wir haben da die Grenzwerte zu berücksichtigen, BOF und EOF, beginning und end of file bzw. list. Daneben wären, als Kontante, die Anzahl Zeilen auf dem Bildschirm bzw. der Druckvorlage zu berücksichtigen. Der Befehl in ANSI-C für den Seitenumbruch ist '\f', formfeed.

Die Gefahr liegt in der Bereichsüberschreitung. Wenn man von der Subroutine direkt auf den Index zugreift (wie gesagt: Index vom Array oder Pointer bewegen ist intern sowieso dasselbe, Bereichsüberschreitung mit Pointer oder Index daher auch), besteht die Gefahr, daß man in den undefinierten Bereich greift.

Es empfiehlt sich als GOLDENE REGEL das ,was ANSI-C uns mit der sehr schönen Funktion fseek() vormacht, daß man nämlich den Zugriff unterteilt, folgendermaßen:

1. Subfunktion äußert einen Wunsch, setze Dateizeiger auf Position xy

Damit darf aber noch nichts passieren, das ist der Trick, da die Subroutine keinen Überblick hat über die Bereichsgrenzen, zweitens damit man Redundanz vermeidet (Bereichsgrenzen in Subroutinen zu überprüfen, ist ja zwangsläufig Redundanz) und bei Programmänderungen keine Leichen im Keller produziert, nämlich diejenigen Funktionen, die man vergessen hat anzupassen (alles läßt sich wiederum auf Redundanz zurückführen).

ES IST NUR EIN WUNSCH.

2. die aufrufende Funktion nimmt den Wunsch zu Kenntnis und nur an dieser EINEN STELLE wird der Bereich überprüft. Die aufrufende Routine muß so geschrieben sein, daß da nichts anbrennt.

Siehe fseek() Nach vorn, über den Dateianfang rückwärts, bleibt es bei 0. fseek() liefert niemals -n Nur nach hinten läuft sie über, aber das hat beim Dateizugriff mit fread() keine Auswirkungen, der Dateizeiger bleibt auf EOF stehen.

Genauso muß man diese aufrufenden Funktionen programmieren, daß alle Bereichsüberschreitungen der anfragenden Subroutinen, die einen WUNSCH äußern, daraufhin überprüft werden.

EIN WUNSCH IST KEIN BEFEHL.

Und dann wird das geliefert, was möglich ist.

Etwas kürzer:


Aufrufende Funktion:

--------- Subfunktion 1 äußert einen Wunsch, den Dateizeiger zu verstellen

--------- Subfunktion 2 äußert einen Wunsch, den Dateizeiger zu verstellen

...

--------- und so weiter, alle haben sie Wünsche, aber die Bereichsüberprüfung findet nur an einer einzigen Stelle statt, in der aufrufenden Funktion oder in einer, die dieser noch übergeordnet ist, jedenfalls nur an EINER STELLE.

Die Vermeidung von Redundanzen ist hier lebenswichtig, sonst macht das Programm irgendwann, was es will.

So wollen wir natürlich nicht programmieren.

Der Beitrag wurde von sharky bearbeitet: 02.03.2012, 20:38 Uhr

Beim Blick auf diesen alten Beitrag:

Vor zwei Jahren hab ich die FiBu in Ansi-C programmiert und benutze sie seitdem. Das Programm ist stabil wie sonstwas, es hatte niemals einen einzigen Programmabsturz oder einen einzigen Programmfehler, obwohl es in Bezug auf die Steuererklärung in vielen Punkten erweitert wurde.

Ich erledige seitdem die gesamte Buchführung mit der FiBu abends online am Bildschirm, rufe mir mein Banking Programm auf, wo die Kontoauszüge angezeigt werden, und tippe das in die FiBu ein. Das sind manchmal 10-12, manchmal aber auch gar keine Kontobewegungen pro Tag. Der Zeitaufwand ist minimal, vielleicht einige Minuten am Tag.

Dafür spare ich, gegenüber vorher, die Kosten für die Buchführung durch den Steuerberater. Wie ich das dunkel in Erinnerung habe, waren das mal so ca. 1800 Euro im Jahr. Nein, es waren ca. 2500 Euro.

Wieviel sind 2500*3?

Nun ja, solche Programme kann man ja auch kaufen.

Sobald man sich mit der Buchführung selbst beschäftigt, treten Seiteneffekte auf. Das ist ganz unvermeidbar. Die sieht man erstmal, für was für einen Sch... man sein Geld ausgibt. Stichwort unnütze Abos und Verträge, die haben dann gern Laufzeiten von bis zu 2 Jahren und verlängern sich dann wieder.

Die Wurmlöcher im Boden vom Faß stopfen ist eine fast zwangsläufige Folge der Tatsache, daß man sich um seine Buchführung selbst kümmert. Die Löcher kann man aber nur stopfen, wenn man sie auch sieht. Was interessiert das den Steuerberater schon?

Mehr aus Hobby als aus Notwendigkeit schreibe ich das Programm jetzt neu als WIndows.Forms Anwendung.

Ansi C hat eben den Nachteil, es hat keine Windows-Oberfläche.

Der Beitrag wurde von sharky2014 bearbeitet: 08.04.2014, 20:41 Uhr