4. Frage zur Organisation des Quellcodes - Aufteilung in verschiedene Dateien

Frage zur Organisation des Quellcodes - Aufteilung in verschiedene Dateien

  • ?

    Hallo.
    Ich hätte da mal eine grundsätzliche Frage zur Strukturierung von Programmen. Ich habe ein Programm, dessen realer Hintergrund sich in grob in 3 Abschnitte zerlegen lässt. Wenn ich das jetzt in 3 Funktionen ummünze, benutzen die natürlich teilweise die gleichen Variablen (je Funktion etwa 30 Variablen, paarweise etwa 60% Überschneidung). Kann mir jemand sagen, wieviel Zeit oder generell "Performance" ich durch die ständige Neudeklaration usw. verliere? Und macht es überhaupt Sinn, dafür 3 verschiedene Funktionen zu bemühen? (grundsätzlich werden nur Sachen berechnet und in eine (die gleiche) Struktur geschrieben)

    Und wenn ich jetzt 3 Funktioen verwende, die jeweils um die 100 Zeilen lang sind (inkl Leerzeilen, Kommentaren) - wieviel Sinn macht es dann, die in eine eigene *.c Datei zu schreiben? Wo ist da die Grenze zwischen Übersicht und Mehraufwand für Pflege?

    \// Mogoon

    0
  • A

    Es ist wirklich eine gute Frage.
    Oft wir einem gesagt dass man sein prog in viele verschiedene Dateien aufteilen soll. Tja eigentlich...ich mach das nicht da mir das zu aufwendig ist... naja ich verteile mein src-code nur dann auf versch dateien , wenn mein prog etw größer wird , also ab 1000 Zeilen.Das kommt bei mir aber eher selten vor. 😋 ...ich mach eh meist nur kleine progs bis max 250 Zeilen oder so.
    Außerdem heißt es ja , dass die Dateien sich möglichst nicht einander "includen" sollen , damit es keinen "CODE-SALAT" gibt...naja das dürfte schwierig werden wenn du um die (zB) 30 oder mehr Dateien hast... und nun zu dir: Bei 3 Funktionen solltest du es lieber in eine Datei schreiben..ich finde es kommt etw lächerlich pro datei eine funktion...ist aber Geschmackssache :p

    0
  • -

    also ich mach das immer so: ich nehme mir das gesamtproblem und teile es in immer kleiner teilaufgaben eine groessere teilaufgabe kommt in eine datei und die zerlegung des problems kommt methoden in die datei! Stichwort: SCHRITTWEISE VERFEINERUNG

    0
  • C

    was der "l.user" da beschrieben hat nennt sich "divide and conquer". beliebt fuer rekursionen.

    0
  • A

    ...oder Teile und Hersche...
    ..mach ich aber net
    😉 😉 😉 😉 😉 😉 😉

    0
  • C

    wie du die funktionen aufteilst ist dir ueberlassen. wenn du funktionen siehst, die du evtl wiederverwenden koenntest, lager sie aus. wenn die compilierung zu lange dauert, spalte die stabilen funktionen raus und linke die spaeter dazu.
    alles andere wird schon von der sprache vorgegeben (extern, static, wasweissich). k&r c, 2te ausgabe, lohnt sich auch, weil da drinsteht, wie man code aufteilt.

    0
  • A

    Das C++ Buch das ich gelesen hab , da stand auch drin wie man den Quellcode aufteilt , aber ich halte mich eh nicht dran(es sei denn ich code was größeres...kommt bei mir net so oft vor)

    Jetzt mal im ernst c.rackwitz:
    Wie groß sind deine progs im Durchschnitt?
    (Also wie viele Zeilen im Quellcode?)

    Ich schätze mal dass du meistens auch "nur" kleinere progs schreibst...

    Folgendes find ich RICHTIG SCHWACHSINNIG:

    /*Datei1.h*/
int f1(int a , int b); /*tolle Funktion*/

    /*Datei1.c*/
int f1(int a , int b)
{
    return a+b;
}

    /*Datei2.h*/
int f2(int a , int b); /*tolle Funktion*/

    /*Datei2.c*/
int f2(int a , int b)
{
    return a-b;
}

    Und die main funktion:

    #include "Datei1.h"
#include "Datei2.h"

int main (void)
{
    char alex89ru[128];
    int num1 = f1(7 , 8);
    int num1 = f2(8 , 7);
    if (num1 == num2)
    {
        sprintf(alex89ru , "Gott!"); /* MUAHAHAHAHAHA */
    }
    else
    {
        sprintf(alex89ru , "Trotzdem Gott!"); /* MUAHAHAHAHAHA */
    }
    return 0;
}

...unglaublich sinnvolle Aufteilung... ha :p
    0
  • C

    alex89ru schrieb:

    Jetzt mal im ernst c.rackwitz:
    Wie groß sind deine progs im Durchschnitt?
    (Also wie viele Zeilen im Quellcode?)

    kleine bis mittlere tools etwa 300-1000, wenn ich ohne gui auskomme (quasi immer).
    und die programme leisten auch was, auch wenn sie klein sind.

    ok, sowas wie in deinem beispiel mit 2 funktionen ist schwachsinn. wuerd ich nie so machen.

    0
  • A

    OK! Bei 300-1000 Zeilen sollte man schon den Quellcode in mehrere Dateien aufteilen. (eher bei 1000 Zeilen).Da hasst du schon recht.
    ps: Für meine Verhältnisse sind 1000 Zeilen nicht kurz.

    Aber wie du schon gesagt hast , ist die Quellcodeaufteilung in meinem Beispiel schwachsinnig.
    🙂 🙂 🙂 🙂

    0
  • ?

    ich progge immer functions mit mindestens 2000 zeilen. dann fang ich ne neue an. das ist kühl. 🕶

    0
  • A

    super-progger schrieb:

    ich progge immer functions mit mindestens 2000 zeilen. dann fang ich ne neue an. das ist kühl. 🕶

    Wie sehen dann deien Funktionen aus?
    Mal im ernst: Es kommt eher selten vo , dass Funktionene über 2000 Zeilen haben
    (glaub ich zumindest)...es sei denn du proggs in ASSEMBLER!!!
    ich mag assembler

    Wenn deine Funktionen so aussehen , dann... :

    #include <dings.h>
/*
Ja
voll
die
fette
Datei
mit
voll
den
fetten
Features
alda
*/

/*
Jetzt
kommt
die
super
funktion
*/
int
func(
int sinnlos1 ,
int sinnlos2 ,
int sinnlos3 ,
int sinnlos4 ,
int sinnlos5 ,
int sinnlos6 ,
int sinnlos7 ,
int sinnlos8 ,
int sinnlos9 ,
int sinnlos10 ,
int sinnlos11 ,
int sinnlos12 ,
int sinnlos13)
{

/*
so
viele
argumente
a
l
t
e
r
*/

int a,b,c,d,e,f,g,h,i,j,k,l,m,n;
/*Wow
wie
viele
variablen*/

int i;
for (i = 0; i< sinnlos1*sinnlos2/sinnlos3%sinnlos11 , sinnlos1++)
{
    /*weitere sinnlose Dinge*/
}

}

/*
Unglaublich:
Durch
diese
Kommentare
erscheint
der Quellcode
richtig
lang
und
die
whitespaces
machen
den
Rest*/

return 123;
}
    0
Anmelden zum Antworten