Guter Programmierstil?

Hi, prgrammiere haupsächlich prozedural in C mit der Winapi und muss gestehen:
Sobal ein Programm etwas länger wird, wirds nur noch unübersichtlich und kompliziert.
Ich wollte mal fragen, obs irgendwo ein paar Tipps gibt, wie man den Quelltext übersichtlicher machen kann, wie man am Besten Variablen nennt, welche Variablen man global macht, welche nicht usw.
Danke für jeden Tip!

OOP sorg normal für übersichtlichen Quellcode, wenn man es einigermaßen kann.

Global macht man am besten keine Variablen.

Irgendwer hat immer eine Antwort

hustbaer

Global macht man am besten garnix
Variablen nennt man so dass man anhand des Namens und mit minimalen kenntnissten der Domäne oder des speziellen Programms weiss was sie beinhalten

Badestrand

hustbaer schrieb:

Variablen nennt man so dass man anhand des Namens und mit minimalen kenntnissten der Domäne oder des speziellen Programms weiss was sie beinhalten

Weil's noch keiner gesagt hat: Funktionen und Klassen sollte man auch so benennen (also aussagekräftig genug aber nicht zu lang).

Was den Weg dahin betrifft: Stöber öfter mal hier im Forum herum, tausche dich aus, veröffentliche Code und ernte Kritik und Übung macht den Meister

Benutze die ungarische Notation und Design wie in der WinAPI, dann behälst du den Überblick (die WinAPI ist ja rießig, d.h. die Entwickler wissen schon wie man so ein rießiges Projekt in C übersichtlich gestaltet).

Simmers schrieb:

Benutze die ungarische Notation und Design wie in der WinAPI, dann behälst du den Überblick (die WinAPI ist ja rießig, d.h. die Entwickler wissen schon wie man so ein rießiges Projekt in C übersichtlich gestaltet).

das soll wohl ein 153 Seiten Thread werden

Simmers schrieb:

d.h. die Entwickler wissen schon wie man so ein rießiges Projekt in C übersichtlich gestaltet

ja, gar nicht. Die WinAPI ist alles andere als übersichtlich.

Wenn die WinAPI so geil designed wäre... Warum wurde sie dann nicht konsequent weiterentwicklet? Warum haben wir keine WinAPI 2.0, 3.0 etc gesehen?

Ich denke eher das die WinAPI ein einziges Chaos ist softwaretechnisch und sich daher keiner bei MS mehr da rantraut. Zu groß, um es from Scratch neu zu schreiben, zu chaotisch um es weiterzuentwicklen. Also werden immer neue Wrapper um WinAPI herumgebaut. (Mfc, Forms etc)

loks schrieb:

Ich denke eher das die WinAPI ein einziges Chaos ist softwaretechnisch und sich daher keiner bei MS mehr da rantraut. Zu groß, um es from Scratch neu zu schreiben, zu chaotisch um es weiterzuentwicklen.

Genau. Die WinAPI wurde für Vista auch garnicht weiterentwickelt, weil die sich da ja nicht ran trauen. Wie willst du die bitte neu schreiben? Tausende von Programmen bauen darauf auf und würden nicht mehr Funktionieren, wenn du die WinAPI änderst.

Aber ein Designvorbild ist sie trotzdem nicht.

pfollprovi schrieb:

Aber ein Designvorbild ist sie trotzdem nicht.

was würdet ihr denn anders machen?

thordk

winapi-fan schrieb:

pfollprovi schrieb:

Aber ein Designvorbild ist sie trotzdem nicht.

was würdet ihr denn anders machen?

alles die winapi ist grausam

thordk schrieb:

alles die winapi ist grausam

das sagen viele. aber was er konkret verbessern würde, weiss keiner.

Hallo

kernel32.dll-freak schrieb:

thordk schrieb:

alles die winapi ist grausam

das sagen viele. aber was er konkret verbessern würde, weiss keiner.

Zum Beispiel die Benennung.

chrische

chrische5 schrieb:

Zum Beispiel die Benennung.

ja? und wie?
zeig's dich mal an hand eines beispiels.
nehmen wir zum beispiel CreateProcess: http://msdn2.microsoft.com/en-us/library/ms682425(VS.85).aspx
deine vorschläge bitte...

rüdiger

kernel32.dll-freak schrieb:

thordk schrieb:

alles die winapi ist grausam

das sagen viele. aber was er konkret verbessern würde, weiss keiner.

* Kleine spezifische Funktionen mit wenig Parametern schreiben.
* Eindeutige und verständliche Namen wählen.
* typedef gegenüber #define vorziehen.
* Wenn schon C, dann wenigstens Pseudo-Namespaces, wenn man eine Bibliothek schreibt.
* Kleine spezifische Header im Gegensatz zu einem großen Blob-Header.
* Die Einbindung von Headern sollte unabhängig von der Reihenfolge funktionieren.
* Auf Compiler-Extensions verzichten und sich so weit es geht an den Standard halten.

btw.
http://www.tilander.org/aurora/2008/01/include-windowsh.html

Hallo

refactoring-freak schrieb:

chrische5 schrieb:

Zum Beispiel die Benennung.

ja? und wie?
zeig's dich mal an hand eines beispiels.
nehmen wir zum beispiel CreateProcess: http://msdn2.microsoft.com/en-us/library/ms682425(VS.85).aspx
deine vorschläge bitte...

Weg mit der UN. da gibt es aber wirklich 1000m Threads zu, also lass uns keinen neuen starten.

chrische

chrische5 schrieb:

Weg mit der UN.

einverstanden. das ist wirklich doof.

@rüdi

* Kleine spezifische Funktionen mit wenig Parametern schreiben.

macht man am anfang so. später stellt sich heraus, dass man immer wieder 5 dieser funktionen in der selben reihenfolge aufrufen muss. also macht man sich eine grosse, die u.u. auch mehr parameter hat.

* Auf Compiler-Extensions verzichten und sich so weit es geht an den Standard halten.

ist bei plattformabhängigem code wie winapi nicht wichtig.

* Kleine spezifische Header im Gegensatz zu einem großen Blob-Header.

so'n blob-header ist unglaublich praktisch, wenn man code schreiben will, der zugriff auf alles hat. ansonsten müsste man jedes source-file mit 50 #includes beginnen.

* typedef gegenüber #define vorziehen.

geht aber nur für typen, sonst kann typedef #define nicht ersetzen.

* Eindeutige und verständliche Namen wählen.

da stimme ich dir zu, aber die namen der winapi-funktionen sind im grossen und ganzen gar nicht so schlecht, ausser dass etwas mehr prefixe angebraucht wären.

DEvent

rüdiger schrieb:

http://www.tilander.org/aurora/2008/01/include-windowsh.html

#define small char
#define far
#define near

Das ist guter Codestil
Vorsicht: dieser Beitrag enthaelt Ironie.

audacia

Zumindest für far und near gibt es keine Alternative.

Diese großen Funktionen der WinAPI sind oftmals sehr mühsam in der Verwendung, aber die WinAPI ist die Schnittstelle zum System, sie muss nicht nur die 99% der Anforderungen abdecken sondern nahezu 100%, also auch Randfälle und deshalb sind die Funktionen so flexibel gehalten.
Die WinAPI hat viele Altlasten das wird keiner Bestreiten, aber einfach neuschreiben ist nicht möglich, zumindest nicht bei der Windows-Philosophie (Abwärtskompatibilität).

Viele der Defines müssten wirklich nicht sein, aber auch da muss man bedenken wie lange es die WinAPI schon gibt.

Das Design selbst finde ich für C sehr gelungen, da die WinAPI eine objektbasierten Ansatz verfolgt.

lolz_ausgeloggt schrieb:

Das Design selbst finde ich für C sehr gelungen, da die WinAPI eine objektbasierten Ansatz verfolgt.

das ganze OS ist objektbasiert. man denke nur mal an die 'handles', die nichts anderes sind als objektreferenzen.

ghorst

lolz_ausgeloggt schrieb:

Diese großen Funktionen der WinAPI sind oftmals sehr mühsam in der Verwendung, aber die WinAPI ist die Schnittstelle zum System, sie muss nicht nur die 99% der Anforderungen abdecken sondern nahezu 100%, also auch Randfälle und deshalb sind die Funktionen so flexibel gehalten.

diese flexibilität kann man auf zwei weisen erreichen. die variante, wie sie etwa in der win32-api gewählt wurde, nämlich abgeschlossene funktionen zu schaffen, die über alle möglichen und nötigen parameter gefüttert werden oder wie es bspw in posix getan wurde, eine interaktion zwischen den einzelnen funktionen zu ermöglichen und so die einzelnen funktionen überschaubar zu halten.
das hier schon erwähnte CreateProcess vs. fork+anhang ist aus meiner sicht der klassische unterschied zwischen ansätze. CreateProcess kann schlicht alles und man muss auch alles machen (und wenn es nur ist, zu sagen, dass es doch bitte genauso haben will, wie bisher.). fork kann eigentlich erstmal nicht viel. man kann dann aber die dinge, die einen in dem speziellen fall tatsächlich interessieren sehr einfach nach dem fork lösen und muss auch nur das machen, was einen interessiert.
ich denke, die posix-variante zur prozesserzeugung ist günstiger, da sie die normalen anwendungsfälle erleichtert, die etwas seltsameren nicht unmöglich macht und vor allem flexibel angepasst werden kann (bald vierzig jahre die gleiche grund-api, aber immer sinnvoll angepasst worden...).

lolz_ausgeloggt schrieb:

Viele der Defines müssten wirklich nicht sein, aber auch da muss man bedenken wie lange es die WinAPI schon gibt.

man kann defines auch so wählen, dass sie einem nicht ständig auf die füße fallen. siehe posix und dessen ursprünge sind _deutlich_ älter...

edit: bevor jemand schreit: ich weiß, dass die winapi deutlich umfangreicher ist als posix. ich habe nur jetzt posix verwendet, um mal zu zeigen, dass sauberes design auch nach jahren noch ohne große nebenwirkungen und altlasten leben kann.