mikrocontroller.net

Forum: PC-Programmierung Maximale Quellcodedateigröße?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Erwin M. (nobodyy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei einigen .c-Dateien in einem Projekt zeigte sich eine Dateigröße von 
mehreren MB und mehrere zehntausend Zeilen Länge.
Welche maximale Größe sollten Quellcodedatei haben, bezüglich Dateigröße 
und Zeilenanzahl?

Autor: Programmiersprachentheaterintendant (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Handgeschriebener oder Maschinengenerierter .c-Quellcode?

Autor: T. B. (bri)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Also für handgeschriebenen Code ist das eindeutig zu viel. Eine feste 
Vorgabe wie z.B. max 500 Zeilen sind erlaubt ist nicht sinnvoll. Aber 
man sollte Aufgaben schon in kleine sinnvolle Teile zerlegen und 
entsprechend in Dateien unterteilen.

Autor: Sempfdazugeber (Gast)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
> schon in kleine sinnvolle Teile zerlegen

Es spricht auch nichts dagegen, dass nicht zu tun.

Autor: Alex G. (dragongamer)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
Sempfdazugeber schrieb:
>> schon in kleine sinnvolle Teile zerlegen
>
> Es spricht auch nichts dagegen, dass nicht zu tun.
Naja, die Übersichtlichkeit die darunter leidet, spricht schon 
dagegen...

EDIT: Willst du nur deinem Namen gerecht werden? ;)

: Bearbeitet durch User
Autor: Jim M. (turboj)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Erwin M. schrieb:
> Welche maximale Größe sollten Quellcodedatei haben, bezüglich Dateigröße
> und Zeilenanzahl?

Eine mögliche Größe geben Tools wie Eclipse vor, die bei großen Files 
die Komfortfunktionen einschränken.

Bei meinem Eclipse hier ist der Indexer auf .c Files <8MB eingeschränkt, 
und ab 50.000 Zeilen wird auf "Scalability mode" geschaltet.

Autor: Filesystem (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Erwin M. schrieb:
> Bei einigen .c-Dateien in einem Projekt zeigte sich eine
> Dateigröße von
> mehreren MB und mehrere zehntausend Zeilen Länge.
> Welche maximale Größe sollten Quellcodedatei haben, bezüglich Dateigröße
> und Zeilenanzahl?

Es gilt das Limit des jeweiligen Filesystems.

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es hängt vom Codeumfang ab. Auch Zeilen je File sind in etwa 
pareto-verteilt. Bei 1 Mio Codezeilen ist es okay, wenn 2-3 zwischen 20- 
und 50.000 Zeilen liegen.

Wenn diese Files wirklich thematisch in sich geschlossen sind, lohnt 
sich oft, hier über automatisierten Code nachzudenken. Ein einfaches 
Auseinanderreißen hingegen ist Quatsch. Du liest Files ja nicht wie ein 
Buch, sondern navigierst mit der IDE. Und sobald beim zerreißen neue 
Header notwendig werden oder Fragmente kopiert werden: Vorsicht.

Autor: Programmiersprachentheaterintendant (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erwin M. schrieb:
> Bei einigen .c-Dateien in einem Projekt zeigte sich eine Dateigröße von
> mehreren MB und mehrere zehntausend Zeilen Länge.

Achim S. schrieb:
> Es hängt vom Codeumfag ab.

LOCs, Kommentar & eingebettete Doku oder ins Programm eingebettete 
Daten?

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Neben den offensichtlichen Grenzen (Dateisystemgröße, maximale 
Dateigröße, Lesbarkeit) gibt es auch compilerinterne Beschränkungen, die 
teilweise bekannt und teilweise nicht bekannt sind. Ich bin bei 
(älteren) Compilern (ARM bzw. Norcroft ADS) schon zweimal an solch eine 
Grenze gestoßen, allerdings nicht mit handgeschriebenem, sondern 
werkzeuggeneriertem Quellcode:

1. Der C-Compiler mochte keine switches mit mehr als 512 Cases.

2. Bei der Übersetzung einer ca. 20MB großen Quellcodedatei gab es 
keinerlei Probleme im ARM-Modus. Im Thumb-Modus sah es aber so aus, als 
würde sich der Compiler aufhängen und nur noch CPU-Zeit konsumieren. Als 
der Hersteller dieses Problem untersuchte, stellte er fest, dass der 
Compiler gar nicht hing, sondern ein Optimierungsalgorithmus sehr 
schlecht skalierte und somit der Compiler wohl nach nur wenigen Wochen 
damit fertig gewesen wäre. Dieses Problem konnte der Hersteller aber 
sehr schnell beheben.

Autor: georg (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Dass sich für eine Sourcedatei mit "mehreren zehntausend Zeilen" keine 
sinnvolle Einteilung nach Funktion finden lässt, ist schwer zu glauben - 
das müsste schon ein absoluter Meister des Spaghetti-Codes verbrochen 
haben, der noch nie etwas von strukturierter Programmierung gehört hat.

Nicht die Länge an sich gehört verboten, sondern der chaotische Aufbau, 
der zu der Länge geführt hat. Es ist schon eine Weile her, dass 
Unterprogramme erfunden wurden, und so mancher ist sogar auf die Idee 
gekommen, dass man so etwas wiederverwenden könnte.

Georg

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
georg schrieb:
> Nicht die Länge an sich gehört verboten, sondern der chaotische Aufbau,
> der zu der Länge geführt hat.

Bei automatisch generiertem Code handelt es sich nicht zwangsweise um 
einen chaotischen Aufbau, sondern meist um sehr gut strukturierten Code. 
Mögliche Anwendungsfälle sind z.B. Zustandsautomaten, die in komplett 
ausgerolltem Zustand eben sehr groß werden können, siehe z.B. die oben 
erwähnte 512-Case-Beschränkung.

Ebenso kann man im C-Quellcode auch z.B. Fremdcode als char-Array 
unterbringen, z.B. Fonts, Grafiken, Dateisystemabbilder, usw.. Um diesen 
Fremdcode nicht mit eigenem handgeschriebenen Code zu vermischen, kann 
es sinnvoll sein, eine Art Containerdatei dafür anzulegen. Um die 
globale Sichtbarkeit der dabei erzeugten Symbole zu begrenzen, kann es 
sinnvoll sein, als einziges nichtlokales Symbol eine Tabelle mit den 
Inhalten dort unterzubringen. Eine derartige Vorgehensweise ist z.B. 
gebräuchlich bei kleinen Embedded-Webservern, deren statische Inhalte 
auf diese Art und Weise abgelegt werden.

Natürlich kann man manche dieser Anwendungsfälle auch durch extern 
gelinkte Binärdateien umsetzen, aber ggf. muss man sich dann in die 
Tiefen der Linkerskripte und der Umsetzung von Symbolnamen begeben, was 
aber die Portabilität nicht unbedingt verbessert.

Autor: imonbln (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Erwin M. schrieb:
> einem Projekt zeigte sich eine Dateigröße von
> mehreren MB und mehrere zehntausend Zeilen Länge

Das sollte der Software Architekt mal dringend über eine Refactoring 
nachdenken, Mir kann keiner Erzählen das er erstens bei so großen 
Dateien noch den überblickt hat und das es da nichts gibt das sich als 
Thematisch auslagern lasst um da vielleicht eine Libary draus zu machen.

IHMO ist eine feste grenze wie max 1000 Zeilen sinnlos. Als weiche 
grenze kann man sagen alles was ausgedruckt 5 Blatt Din A4 übersteigt, 
braucht ein Moment bis jemand frisches Das durchsteigen kann.
Und ja mir ist bewusst das mit modernen IDE der Wunsch Code zu drucken 
um Ihn zu verstehen stark nachgelassen hat. Aber wie gesagt eine weiche 
Regel wie viel Code pro Datei finde ich dennoch sinnvoll.

Bei Projekten welche mehrere zehntausend Zeilen pro Dateien haben, ist 
die Wahrscheinlichkeit groß das es sich um Historisch gewachsene 
Strukturen handelt.  Ich persönlich habe die Erfahrung gemacht, das 
solche Walls of Text besonders Anfällig sind für, Toten Code, Code 
Dopplung und alle möglichen damit zusammenhängende Probleme.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erwin M. schrieb:
> Bei einigen .c-Dateien in einem Projekt zeigte sich eine
> Dateigröße von mehreren MB und mehrere zehntausend Zeilen Länge.
> Welche maximale Größe sollten Quellcodedatei haben, bezüglich Dateigröße
> und Zeilenanzahl?

Es gibt Compiler, die grosse Dateien nicht mehr schaffen, oft weil der 
Speicher bei der Codeoptimierung ausgeht.
Dann muss man die Datei halt kleiner machen.
Auch brauchen manche Compiler oder Editore länger, manche Diff-Programme 
können so grosses nicht.
Ansonsten gibt es keinen wirklichen fachlichen Grund, die Übersicht 
einer grossen Datei durch den unübersichtlichen Verhau vieler kleiner 
Dateien zu ersetzen.

Autor: Marc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Wahrheit ist wie immer fließend ...

Ich bin allerdings kein Freund von switches mit hunderten von case 
fällen.
Je optimierungsverhalten des compilers kommt da sehr unperformanter Code 
raus. Da sollte man immer ein Auge drauf haben.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
MaWin schrieb:
> die Übersicht
> einer grossen Datei durch den unübersichtlichen Verhau vieler kleiner
> Dateien zu ersetzen.

Da hast Du recht, das will man sicher nicht.

Aber man könnte sie stattdessen durch eine übersichtliche und 
wohlgeordnete Anzahl vieler kleiner Dateien ersetzen.

: Bearbeitet durch User
Autor: Ivo -. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Grenze liegt bei 500 Zeilen, aber das ist für mich auch keine 
harte Grenze sondern eher ein Richtwert.
Ohne Codefolding würds aber auch nicht gehen.

Ivo

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Aber man könnte sie stattdessen durch eine übersichtliche und
> wohlgeordnete Anzahl vieler kleiner Dateien ersetzen

Wenn das möglich ist, sollte man es tun. Wobei "übersichtlich" und 
"viel" halt im Auge des Betrachters liegt.

Es ist wie so oft im Leben: Eine Datei von 100.000 Zeilen ist vermutlich 
ein Müllhaufen und hat vermutlich  (wie jedes SW) 
Verbesserungspotential. Das ändert aber nichts daran, dass es 
Quelldateien dieser Größe gibt, bei denen aufteilen die Komplexität 
nicht mindert und die Überschaubarkeit (per IDE) nicht erhöht. Dann 
sollte man es auch lassen.

Und das Argument unzureichender Compiler oder IDEs: Ja, dann muss man 
wohl oder übel Abstriche beim Code machen.

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ivo Z. schrieb:
> Meine Grenze liegt bei 500 Zeilen

Bei Treibern sicher ok, also bei einer Ansammlung von vielen, einander 
unabhängigen Funktionalitäten. Dann sind 2000 Dateien je 500 Zeilen OK, 
mit je einer öffentlichen Header.

Bei einem autarken embedded Projekt mit gleicher Codezeilen-Zahl, ist 
oft schon die sinnvolle Benamung der Dateien ein Problem. Und wenn dann 
thematische Zusammenhänge auf 10-20 solcher Mini-Dateien verteilt werden 
und zusätzliche Header notwendig sind, dann wird die eigentliche 
Problematik sichtbar.

Autor: avr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marc schrieb:
> Je optimierungsverhalten des compilers kommt da sehr unperformanter Code
> raus.

Das läuft meist auf eine Look-Up-Table heraus, wenn der Compiler nicht 
ganz schlecht ist. Unda dazu würde ich sogar sagen, dass dann meist sehr 
guter Code erzeugt wird.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
imonbln schrieb:
> Bei Projekten welche mehrere zehntausend Zeilen pro Dateien haben, ist
> die Wahrscheinlichkeit groß das es sich um Historisch gewachsene
> Strukturen handelt.

Sehe ich auch so. Meist ist das über viele Jahre so geworden, und 
zwischendurch hat sich nie einer Gedanken darüber gemacht, die Struktur 
an die Veränderungen anzupassen. Dementsprechend unübersichtlich ist 
sowas dann.

MaWin schrieb:
> Ansonsten gibt es keinen wirklichen fachlichen Grund, die Übersicht
> einer grossen Datei

Alles in eine so große Datei zu stopfen, finde ich nicht besonders 
übersichtlich.

> durch den unübersichtlichen Verhau vieler kleiner Dateien zu ersetzen.

Die Idee ist ja auch, es nicht unübersichtlich zu machen.

Autor: Walter K. (walter_k488)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Maximale Größe einer Sourcecodedatei?
Unter ZFS sind es exakt:
1,844674407371e19 Byte

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Walter K. schrieb:
> Maximale Größe einer Sourcecodedatei?
> Unter ZFS sind es exakt:
> 1,844674407371e19 Byte

Na dann fang lieber schonmal an zu schreiben. Das wird diese Woche nicht 
mehr fertig.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Walter K. schrieb:
> Maximale Größe einer Sourcecodedatei?
> Unter ZFS sind es exakt:
> 1,844674407371e19 Byte

Aha. Hast du denn auch einen Texteditor, mit dem du eine so große Datei 
bearbeiten kannst? Und wieviel RAM braucht dein Compiler typischerweise 
zum Übersetzen so einer Datei?

Autor: Erwin M. (nobodyy)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Achim S. schrieb:
> Wenn diese Files wirklich thematisch in sich geschlossen sind, lohnt
> sich oft, hier über automatisierten Code nachzudenken.

Dann könnte man auch den Linux-Kernel in eine .c-Datei, weil es ja nur 
den Linux-Kernel betrifft und damit thematisch in sich geschlossen ist. 
Das wären ja nur wenig mehr als 20 Mio Zeilen.

Autor: Ivo -. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achim S. schrieb:
> Ivo Z. schrieb:
>> Meine Grenze liegt bei 500 Zeilen
>
> Bei Treibern sicher ok, also bei einer Ansammlung von vielen, einander
> unabhängigen Funktionalitäten. Dann sind 2000 Dateien je 500 Zeilen OK,
> mit je einer öffentlichen Header.
>
> Bei einem autarken embedded Projekt mit gleicher Codezeilen-Zahl, ist
> oft schon die sinnvolle Benamung der Dateien ein Problem. Und wenn dann
> thematische Zusammenhänge auf 10-20 solcher Mini-Dateien verteilt werden
> und zusätzliche Header notwendig sind, dann wird die eigentliche
> Problematik sichtbar.

Ich hab bisher nur alleine Hobbyprojekte gemacht, über 1000 Zeilen war 
ich nie nennenswert drüber, von daher habe ich mich mit solchen 
Dimensionen noch nicht beschäftigt.

Ivo

Autor: Zeno (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
MaWin schrieb:
> Ansonsten gibt es keinen wirklichen fachlichen Grund, die Übersicht
> einer grossen Datei durch den unübersichtlichen Verhau vieler kleiner
> Dateien zu ersetzen.

Bei C# scheint dies aber bei vielen Programmierern genau der Trend zu 
sein. Ich arbeite zeitweise an einem größeren WPF-Projekt mit und der 
Kollege mit dem ich da zusammenarbeiten muß ist auch ein Verfechter 
vieler kleiner Dateien. Da gibt es dann Sourcefiles wo nur eine Methode 
drin steht die nichts weiter macht, als auf eine andere Methode zu 
verweisen, welche ihrerseits auf die nächste Methode verweist. Der Code 
liest sich komplett beschissen und man kann sich dann nur sehr schwer in 
seine Logik einarbeiten. Er, der Kollege, findet das aber toll und ist 
der Meinung das sei guter Programmierstil und ist von dieser 
Arbeitsweise nicht abzubringen.

Ich persönlich halte es so, daß ich das was logisch zu einer bestimmten 
Funktionalität gehört in eine Datei schreibe.

Autor: spagetticode (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erwin M. schrieb:
> Welche maximale Größe sollten Quellcodedatei haben, bezüglich Dateigröße
> und Zeilenanzahl?

Das kommt darauf an welchen Editor du verwendest, Der Windows Notepad 
macht schon bei wenigen MB schlapp. Richtige Editoren wie z.B. emacs 
können gigabyteweise auf die Festplatte swappen wenn es nötig ist.

Autor: Rudolf S. (Firma: Ingenieurbüro ItD) (rudolfatitd)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Ich suche immer mal wieder Antworten auf Fragen in den seriösen Foren. 
Heute auch wieder - ich hatte dieselbe Frage wie am Anfang: Maximale 
Größe Quelldatei".

Hut ab vor soviel Text mit NULL hilfreicher Information. Das hätte ich 
nur bei Facebook erwartet.

Autor: c-hater (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Rudolf S. schrieb:

> Ich suche immer mal wieder Antworten auf Fragen in den seriösen Foren.
> Heute auch wieder - ich hatte dieselbe Frage wie am Anfang: Maximale
> Größe Quelldatei".
>
> Hut ab vor soviel Text mit NULL hilfreicher Information. Das hätte ich
> nur bei Facebook erwartet.

Wenn du einfache Antworten auf schwer entscheidbare Fragen suchst: 
schließ' dich irgendeiner Religion oder meinetwegen auch der AfD an. All 
diese Organisationen  sind darauf spezialisiert, denjenigen, die arm im 
Geiste sind, genau so was zu liefern...

Alle anderen machen sich die Mühe, selber zu denken. Was unmittelbar 
dazu führt, das man so'n Schwachsinn erst garnicht fragt, weil man, 
schon mit minimaler Eigenintelligenz ausgestattet, vollkommen mühelos 
selber erkennen kann: "it depends..."

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rudolf S. schrieb:
> Hut ab vor soviel Text mit NULL hilfreicher Information. Das hätte ich
> nur bei Facebook erwartet.

Das wird daran liegen, dass schon die Frage nicht sonderlich sinnvoll 
ist. Wenn du eine Quellcode-Datei öffnen willst, die so groß ist, dass 
sie ein normaler Editor nicht handhaben kann, machst du was falsch.

Autor: Thomas W. (thomas_v2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Wireshark-Quellcode gibt es einige C-Quelldateien mit mehreren 10.000 
Zeilen. Die ganz großen mit 50-200k Zeilen sind jedoch automatisch aus 
einer ASN.1 Beschreibung generiert.
Ich finde mit 10.000 Zeilen in einer Datei lässt sich noch relativ gut 
arbeiten, wenn die Funktionensnamen sinnvoll vergeben sind, damit sich 
in einem Navigationsbaum des Editors diese schnell lokalisieren lassen.

Wobei das bei Wireshark auch etwas speziell ist, weil jedes Protokoll 
üblicherweise aus nur 1-2 Quelldateien besteht, und es trotzdem knapp 
2000 Dateien gibt. Wenn man da anfangen würde die Quelldateien noch 
weiter zu unterteilen, würde es vermutlich unübersichtlicher.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas W. schrieb:
> Im Wireshark-Quellcode gibt es einige C-Quelldateien mit mehreren 10.000
> Zeilen. Die ganz großen mit 50-200k Zeilen sind jedoch automatisch aus
> einer ASN.1 Beschreibung generiert.

Aber die wird man dann in der Regel nicht von Hand bearbeiten müssen.

Autor: nur ungern C Programmierer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Da C Compiler grottig langsam sind und auch die Fehler oft nicht die 
"echte" Stelle zeigen, sind lange Quelltexte Selbstgeißelung.

Wer sich einen Gefallen tun will, macht viele kleine Quelltextdateien. 
Es braucht dann nur das durch den Übersetzer, was auch geändert wurde.

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nur ungern C Programmierer schrieb:
> Da C Compiler grottig langsam sind und auch die Fehler oft nicht die
> "echte" Stelle zeigen, sind lange Quelltexte Selbstgeißelung.

Naja, meist trifft halt der erste Fehler.

> Wer sich einen Gefallen tun will, macht viele kleine Quelltextdateien.
+ entsprechenden Overhead, sprich Header-Dateien

> Es braucht dann nur das durch den Übersetzer, was auch geändert wurde.
naja, einzelne Dateien von 100kLOC brauchen jetzt ja nicht länger als ne 
Sekunde oder so. Und Änderungen in Headern können deutlich teurer sein.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
nur ungern C Programmierer schrieb:
> Da C Compiler grottig langsam sind

Ca. 14000 Zeilen/s (clang -O2) bzw. 12500 Zeilen/s (gcc -O2) (mit -O3
kaum langsamer) für ein reales Beispiel (epan/proto.c aus Wireshark) auf
einem mäßig schnellen Laptop würde ich jetzt nicht als "grottig langsam"
bezeichnen. Welchen Compiler, der so grottig langsam ist, benutzt denn
du?

> und auch die Fehler oft nicht die "echte" Stelle zeigen, sind lange
> Quelltexte Selbstgeißelung.

Zum einen lernt man  mit der Zeit, die Fehlermeldungen richtig zu
interpretieren, zum anderen haben die Meldungen (zuerst bei Clang, dann
denn auch bei GCC) in des letzten Jahren sehr viel an Aussagekraft
gewonnen. Vielleicht hast du von dieser ENtwicklung nur noch nichts
mitbekommen.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nur ungern C Programmierer schrieb:
> Da C Compiler grottig langsam sind und auch die Fehler oft nicht die
> "echte" Stelle zeigen, sind lange Quelltexte Selbstgeißelung.

Du redest von C++-Compilern und kompliziertem, generischem Quellcode. 
Die meisten C-Compiler sind erstaunlich schnell (für die Qualität des 
erzeugten Codes).

Autor: Klaus Banaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Programmiersprachentheaterintendant schrieb:
> Handgeschriebener oder Maschinengenerierter .c-Quellcode?

oder einfach nur präprozessor cpp output um die includes pfadsicher 
einzubinden.

https://linux.die.net/man/1/cpp

Autor: nur ungern C Programmierer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Zum einen lernt man  mit der Zeit, die Fehlermeldungen richtig zu
> interpretieren

Na super! Auf der einen Seite geht es heute um KI und so ein popeliges 
Tool gibt Fehlermeldungen aus, deren Interpretation erlernt werden muss. 
:-<<<

Sorry, das Zeugs ist von gestern!

Autor: S. R. (svenska)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
nur ungern C Programmierer schrieb:
> Na super! Auf der einen Seite geht es heute um KI und
> so ein popeliges Tool gibt Fehlermeldungen aus,
> deren Interpretation erlernt werden muss.

Tja, auch KI muss auch lernen.
Lernt sie besser als du, bist wegen Doofheit raus.

Und wenn ein Tool wegen deiner eigenen Dummheit nicht funktioniert, dann 
ist deine eigene Dummheit schuld, nicht das Tool.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nur ungern C Programmierer schrieb:
> Yalu X. schrieb:
>> Zum einen lernt man  mit der Zeit, die Fehlermeldungen richtig zu
>> interpretieren
>
> Na super! Auf der einen Seite geht es heute um KI und so ein popeliges
> Tool gibt Fehlermeldungen aus, deren Interpretation erlernt werden muss.
> :-<<<
>
> Sorry, das Zeugs ist von gestern!

Einerseits beschwerst du dich, dass die Compiler angeblich "grottig 
langsam" seien, andererseits willst du da eine KI drin haben, die dir 
die Warnungen erzeugt. Das passt nicht zusammen.

Autor: nur ungern C Programmierer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
S. R. schrieb:
> Und wenn ein Tool wegen deiner eigenen Dummheit nicht funktioniert, dann
> ist deine eigene Dummheit schuld, nicht das Tool.

Wie immer: Reicht es fachlich nicht, wird man persönlich. Armer Tropf.


> Einerseits beschwerst du dich, dass die Compiler angeblich "grottig
> langsam" seien, andererseits willst du da eine KI drin haben, die dir
> die Warnungen erzeugt. Das passt nicht zusammen.
Wo schrieb ich, dass ich mir einen Compiler mit KI wünsche? Warum 
schreibst du solche falschen Behauptungen?

Der C Compiler soll nur- wie viele andere Compiler es machen - die echte 
Fehlerstelle benennen. Er soll nicht hoffen, dass noch alles gut wird 
und ein fehlendes ; 30 Zeilen tiefer mit ( erwartet melden. Das ist 
Steinzeit.

[Mod: Einer sachlichen Diskussion entgegenstehende Symbole gelöscht]

: Bearbeitet durch Moderator
Autor: Johann J. (johannjohanson)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
nur ungern C Programmierer schrieb:
> Auf der einen Seite geht es heute um KI

Wenn es an NI fehlt ist Hopfen und Malz verloren :-)

Autor: ungern C Programmierer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann J. schrieb:
> nur ungern C Programmierer schrieb:
>> Auf der einen Seite geht es heute um KI
>
> Wenn es an NI fehlt ist Hopfen und Malz verloren :-)

Nur Fachidioten hier? Es gibt auch ein Leben - mit und ohne KI - weit 
weg vom grottigen C Compiler.

Autor: Johann J. (johannjohanson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ungern C Programmierer schrieb:
>> Wenn es an NI fehlt ist Hopfen und Malz verloren :-)
>
> Nur Fachidioten hier? Es gibt auch ein Leben - mit und ohne KI - weit
> weg vom grottigen C Compiler.

Sag ich doch.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nur ungern C Programmierer schrieb:
> Wo schrieb ich, dass ich mir einen Compiler mit KI wünsche?

Du hattest doch geschrieben, dass du dir bessere Compilerwarnungen 
wünschst, weil es heute KI gibt. Wenn du damit was anderes meintest, 
solltest du vielleicht mal erklären, wo du überhaupt den Zusammenhang 
zwischen Compilerwarnungen und KI siehst.

nur ungern C Programmierer schrieb:
> Der C Compiler soll nur- wie viele andere Compiler es machen - die echte
> Fehlerstelle benennen.

Was die echte Fehlerstelle ist, ist Ansichtssache. Solange der Code 
einen Sinn ergeben kann, ist für den Compiler ja erstmal nichts 
auffälliges dran. Erst wenn der Code keinen Sinn mehr ergibt, gibt er 
auf und bricht ab. Aus Sicht der Sprache ist das dann die echte 
Fehlerstelle.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nur ungern C Programmierer schrieb:
> Yalu X. schrieb:
>> Zum einen lernt man  mit der Zeit, die Fehlermeldungen richtig zu
>> interpretieren
>
> Na super! Auf der einen Seite geht es heute um KI und so ein popeliges
> Tool gibt Fehlermeldungen aus, deren Interpretation erlernt werden muss.

Schön, dass auch du inzwischen eingesehen hast, dass C-Compiler nicht
grottig langsam sind.

Was die Fehlermeldungen betrifft: Kennst du eine Programmiersprache mit
einem Compiler, der immer den wahren Fehler anzeigt?

Wenn ja: Warum zeigt er ihn dann überhaupt an und korrigiert ihn nicht
gleich selbst?

nur ungern C Programmierer schrieb:
> Der C Compiler soll nur- wie viele andere Compiler es machen - die echte
> Fehlerstelle benennen. Er soll nicht hoffen, dass noch alles gut wird
> und ein fehlendes ; 30 Zeilen tiefer mit ( erwartet melden. Das ist
> Steinzeit.

Zeig mir ein vernünftiges (nicht konstruiertes) Beispiel, wo ein
fehlendes Semikolon erst 30 Zeilen später als Fehler erkannt wird.

Autor: nur ungern C Programmierer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Du hattest doch geschrieben, dass du dir bessere Compilerwarnungen
> wünschst, weil es heute KI gibt.

Es gibt KI und C Compiler sind auf dem Stand von Dampfmaschinen. Jetzt 
kapiert?

Yalu X. schrieb:
> Schön, dass auch du inzwischen eingesehen hast, dass C-Compiler nicht
> grottig langsam sind.
???
Nö, das sind die größten Schnarchnasen unter den (heute, von Vielen 
benutzte) Compiler.

Yalu X. schrieb:
> Wenn ja: Warum zeigt er ihn dann überhaupt an und korrigiert ihn nicht
> gleich selbst?
Sorry, aber wie blöd stelltst du dich hier dar?
Wenn eine Abweichung festgestellt wird, bitte Hinweis auf Zeile und 
Zeichen, fertig. Der grottige C Compiler macht das nur beim Supergau.

Yalu X. schrieb:
> Zeig mir ein vernünftiges (nicht konstruiertes) Beispiel, wo ein
> fehlendes Semikolon erst 30 Zeilen später als Fehler erkannt wird.
Ich bin ja C Kumnmer gewohnt und greife daher nicht mehr so oft ins C 
Compiler Fettnäpfchen.

Das Ganze erinnert mich an die Diskussionen "nur AVR, bloß kein ARM!". 
Und die damaligen ARM-Hater rühren heute die ARM Werbetrommel und 
verfluchen die AVR.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
nur ungern C Programmierer schrieb:
> Yalu X. schrieb:
>> Zeig mir ein vernünftiges (nicht konstruiertes) Beispiel, wo ein
>> fehlendes Semikolon erst 30 Zeilen später als Fehler erkannt wird.
> Ich bin ja C Kumnmer gewohnt und greife daher nicht mehr so oft ins C
> Compiler Fettnäpfchen.

Mach dir deswegen keine Sorgen. Im Fettnäpfchen steckst du ja schon seit
deinem allerersten Beitrag in diesem Thread. Am besten belassen wir es
dabei, bevor du noch weiter darin einsinkst.

Autor: ungern C Programmierer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Mach dir deswegen keine Sorgen. Im Fettnäpfchen steckst du ja schon seit
> deinem allerersten Beitrag in diesem Thread.

Nö, der Beitrag passt schon.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
nur ungern C Programmierer schrieb:
> Yalu X. schrieb:
>> Zum einen lernt man  mit der Zeit, die Fehlermeldungen richtig zu
>> interpretieren
>
> Na super! Auf der einen Seite geht es heute um KI und so ein popeliges
> Tool gibt Fehlermeldungen aus, deren Interpretation erlernt werden muss.
> :-<<<
>
> Sorry, das Zeugs ist von gestern!

Sorry, aber das ist doch Kindergarten und Bauchvermutungen von 
unbeteiligten Außenstehenden. Sobald man genug Erfahrung (mit welcher 
Sprache auch immer) hat um anzufangen ernsthafte Sachen damit zu machen 
hat man jede Fehlermeldung die vorkommen kann schon mehrmals gesehen und 
weiß ganz genau was sie bedeutet und wo man nach seinem Fehler zu suchen 
hat. Und in 99% der Fälle wird man sogar direkt mit der Nase auf die 
betreffende Codezeile gestoßen. Das ist in der Praxis(!) also überhaupt 
kein Problem, da verliert man überhaupt keine Worte mehr drüber.

Autor: Dirk K. (merciless)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erwin M. schrieb:
> Bei einigen .c-Dateien in einem Projekt zeigte sich eine Dateigröße von
> mehreren MB und mehrere zehntausend Zeilen Länge.
> Welche maximale Größe sollten Quellcodedatei haben, bezüglich Dateigröße
> und Zeilenanzahl?
Aus der Sicht von Clean Code würde ich jedes File,
das mehr als 1000 Zeilen enthält, als potentiell
zu groß bezeichnen.

Aus technischer Sicht gelten Limitierungen vom
jeweiligen Compiler und/oder Betriebs- bzw.
Filesystem.

merciless

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Dirk K. schrieb:
> Aus der Sicht von Clean Code würde ich jedes File,
> das mehr als 1000 Zeilen enthält, als potentiell
> zu groß bezeichnen.

Du hältst es also für wesentlich sauberer, als Array eingebettete 
Tabellen, Binärdateno.ä. in etliche Häppchen zu zerteilen und ggf. einen 
Haufen Code zu schreiben, der diese Tabellenstücke entweder zur Laufzeit 
oder durch obskure Präprozessoranweisungen zur Kompilierzeit wieder 
zusammensetzt? Oder eben den wenig portablen und aus Quellcodesicht 
verborgenen Weg über den Linker zu gehen? Das kann man so machen, aber 
dann wird es scheiße. BTDT

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dirk K. schrieb:
> Aus der Sicht von Clean Code würde ich jedes File,
> das mehr als 1000 Zeilen enthält, als potentiell
> zu groß bezeichnen.

Und was ist dann die sinnvolle Vorgehensweise wenn ein Hardwaretreiber 
zum Beispiel 1200 Zeilen enthält und es beim besten Willen keine 
vernünftige(!) Trennlinie mehr zu ziehen ist welchen Teil man in ein 
separates eigenständiges Untermodul auslagern könnte weil all das 
bereits längst geschehen ist und jetzt echt nur noch das drin ist was 
wirklich dort reingehört (und nirgends anderswohin), weil man auch mit 
Gewalt nichts mehr refactorn könnte ohne es komplett zu vermurksen, und 
es sind immer noch 200 Zeilen zuviel? Oder 300? Oder 500? Was machst Du 
dann?

: Bearbeitet durch User
Autor: qwertzuiopasdfghjklyxcvbnm (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Dirk K. schrieb:
> Aus der Sicht von Clean Code würde ich jedes File,
> das mehr als 1000 Zeilen enthält, als potentiell
> zu groß bezeichnen.
>
> Du hältst es also für wesentlich sauberer, als Array eingebettete
> Tabellen, Binärdateno.ä. in etliche Häppchen zu zerteilen und ggf. einen
> Haufen Code zu schreiben, der diese Tabellenstücke entweder zur Laufzeit
> oder durch obskure Präprozessoranweisungen zur Kompilierzeit wieder
> zusammensetzt? Oder eben den wenig portablen und aus Quellcodesicht
> verborgenen Weg über den Linker zu gehen? Das kann man so machen, aber
> dann wird es scheiße. BTDT

Stell dich doch nicht dümmer, als du bist! Du weißt genau, wie er das 
gemeint hat.

Autor: Sebastian S. (amateur)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Soweit mir bekannt ist gibt es keine maximale Quellcodegröße mehr.
Das heißt aber nicht, dass man seinen Quellcode unter Ausschluss von 
Hirn schreiben soll (Masochisten mal ausgenommen).

Für mich hat das Wort: Übersichtlichkeit einen sehr hohen Stellenwert.

Also was Zusammengehört sollte auch zusammen stehen. Aber nicht mehr.
Schon die Fehlersuche ist bei Endloscode ein Problem, da die 
Fehlermeldung fast immer an der falschen Stelle ausgegeben wird.

Auch wenn die heutigen Compiler relativ schnell sind unterstützt das 
Aufteilen in sinnvolle Brocken den gesamten Build Process, da 
üblicherweise nur die Teile neu übersetzt werden, an denen auch 
rumgefummelt wurde.

Autor: DPA (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Erwin M. schrieb:
> Bei einigen .c-Dateien in einem Projekt zeigte sich eine Dateigröße von
> mehreren MB und mehrere zehntausend Zeilen Länge.

Obwohl man nicht nur nach der länge gehen kann, die C Dateien sind 
definitiv zu lang. Die Kunst ist es, verschiedenes sinnvoll aufzuteilen. 
Eventuell hilft es, sich zu fragen:
 1) Braucht es den Code überhaupt?
 2) Wozu gehört etwas?
 3) Wovon hängt es ab?
 4) Gibt es schon Code, der das oder etwas ähnliches macht? (Dann 
zusammenführen, verallgemeinern oder löschen)
 5) Kann man das noch übersichtlicher organisieren?

Idealerweise sollte das Programm so aufgebaut sein, dass man bei einem 
Problem sofort begreift, dass muss Komponente X in Datei Y sein, wegen 
Funktion Z. Die ganze Architektur, der Control Flow, sollte möglichst 
einfach zu begreifen sein.

Es braucht vor allem Übung.

Hat man z.B. diverse Listenartige Strukturen, und bearbeitet diese an 
verschiedensten stellen, dann kann man sich mal eine allgemeine 
Implementierung diverser Listen & Hilfsfunktionen anlegen oder holen, 
und in separate Dateien packen.

Hat man Funktionen, die nicht wirklich spezifisch zu irgendwas sind, 
kann man diese eventuell als Utillity Funktionen verallgemeinert 
auslagern.

Hat man Code für Textausgaben, zum Parsen von Zeugs, zum Verwalten von 
X, zur Verarbeitung von Y, oder zum Verehren von Katzen, dann packt man 
die Dinge in eigene Dateien, eventuell sogar in je mehr als eine, etc.

Bei manchen Sachen macht es auch sinn, jeder Funktion eine eigene Datei 
zu geben. Ich hab z.B. bei diesem Projekt von mir ein Parser für escape 
sequenzen, der bei jeder erkannten Escapesequenz die angegebene Funktion 
aufruft: 
https://github.com/Daniel-Abrecht/libttymultiplex/blob/master/src/parser.c#L36
Die Funktionen selbst sind dann aber alle in einem Unterordner in einer 
eigenen Datei, mit nur je 20-30 Zeilen code: 
https://github.com/Daniel-Abrecht/libttymultiplex/tree/master/src/sequencehandler

Autor: Dirk K. (merciless)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Du hältst es also für wesentlich sauberer, als Array eingebettete
> Tabellen, Binärdateno.ä. in etliche Häppchen zu zerteilen und ggf. einen
> Haufen Code zu schreiben, der diese Tabellenstücke entweder zur Laufzeit
> oder durch obskure Präprozessoranweisungen zur Kompilierzeit wieder
> zusammensetzt? Oder eben den wenig portablen und aus Quellcodesicht
> verborgenen Weg über den Linker zu gehen? Das kann man so machen, aber
> dann wird es scheiße. BTDT

Bernd K. schrieb:
> Und was ist dann die sinnvolle Vorgehensweise wenn ein Hardwaretreiber
> zum Beispiel 1200 Zeilen enthält und es beim besten Willen keine
> vernünftige(!) Trennlinie mehr zu ziehen ist welchen Teil man in ein
> separates eigenständiges Untermodul auslagern könnte weil all das
> bereits längst geschehen ist und jetzt echt nur noch das drin ist was
> wirklich dort reingehört (und nirgends anderswohin), weil man auch mit
> Gewalt nichts mehr refactorn könnte ohne es komplett zu vermurksen, und
> es sind immer noch 200 Zeilen zuviel? Oder 300? Oder 500? Was machst Du
> dann?

Ja nun gut, ich kann nicht von jedem erwarten,
dass er der deutschen Sprache mächtig ist.

Ich hab das Wort "potentiell" verwendet. Dies
suggeriert dem geneigten Leser, dass es auch
Ausnahmen geben kann/wird: generierter Code,
eingebettete Daten oder einfach nur die
fehlende Möglichkeit, den Code weiter zu zerlegen.
Auch wird es nicht passieren, dass Robert C. Martin
mit der Maschinenpistole im Anschlag in der
Tür steht, wenn man ein File größer macht.

Man man man, aber mal wieder schön getrollt.

merciless

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dirk K. schrieb:
> Aus der Sicht von Clean Code würde ich jedes File,
> das mehr als 1000 Zeilen enthält, als potentiell
> zu groß bezeichnen.

Das bedeutet aber im Umkehrschluss: mit Clean Code kann ich nur kleine 
Projekte oder halt Sammlungen (Treiber etc.) machen.

Wenn 1000 eine Obergrenze ist, dann kann der Mittelwert (nach Pareto) 
nur bei wenigen 100 Zeilen liegen. Das ist für größere Projekte 
(>100.000 Zeilen) nicht sinnvoll.

Autor: Jemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Du hältst es also für wesentlich sauberer, als Array eingebettete
> Tabellen, Binärdateno.ä. in etliche Häppchen zu zerteilen und ggf. einen
> Haufen Code zu schreiben, der diese Tabellenstücke entweder zur Laufzeit
> oder durch obskure Präprozessoranweisungen zur Kompilierzeit wieder
> zusammensetzt? Oder eben den wenig portablen und aus Quellcodesicht
> verborgenen Weg über den Linker zu gehen? Das kann man so machen, aber
> dann wird es scheiße. BTDT

Das Problem gäbe es gar nicht, wenn C eine gescheite Möglichkeit zur 
Compile-Time Verarbeitung von Binärblobs, CSV, etc. aus externen Dateien 
hätte.
Trennung von Daten und Code und so.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jemand schrieb:
> Das Problem gäbe es gar nicht, wenn C eine gescheite Möglichkeit zur
> Compile-Time Verarbeitung von Binärblobs, CSV, etc. aus externen Dateien
> hätte.
> Trennung von Daten und Code und so.

Da kann man bequem herum arbeiten, das kann man immer noch absolut 
sauber trennen, auch wenn in irgendeiner Zwischenstufe generierter Code 
entsteht. Das würd ich eher als das allerkleinste von C's 
Unannehmlichkeiten betrachten.

Autor: DPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> Wenn 1000 eine Obergrenze ist, dann kann der Mittelwert (nach Pareto)
> nur bei wenigen 100 Zeilen liegen. Das ist für größere Projekte
> (>100.000 Zeilen) nicht sinnvoll.

Angenommen, man hat 1000 Dateien mit rund 100 Zeilen Code bei einem 
größeres Projekt (>100.000 Zeilen), warum soll das nicht Sinvoll sein? 
Insbesondere, wenn man auch noch Unterordner verwendet, ist das doch 
kein Problem?

Jemand schrieb:
> Das Problem gäbe es gar nicht, wenn C eine gescheite Möglichkeit zur
> Compile-Time Verarbeitung von Binärblobs, CSV, etc. aus externen Dateien
> hätte.
> Trennung von Daten und Code und so.

Die Konvertierung kann man auch beim kompilieren machen. Dazu nutzt man 
ein Makefile. Dem ist es egal, was in welcher Sprache/Format da ist, es 
macht was auch immer man ihm sagt das es soll, um das Programm zu 
erstellen. Dann konvertiert man die Daten halt einem kleinen 
Hilfsprogramm nach C, und kompiliert das dann. Auch das Hilfsprogramm 
kann man sich vorher noch automatisch von make erstellen lassen. 
Insbesondere früher wusste man auch noch, wie man mit lex/yacc Parser 
schreibt, um das sogar mit komplexeren non-standard 
Daten/Programmstrukturen zu machen. Da das auch keine Unterstützung 
irgendwelcher speziellen/spezifischen Dateiformate in C selbst 
voraussetzt, ist die Lösung ja wohl auch viel versatiler und schöner.

Autor: Dirk K. (merciless)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> Das bedeutet aber im Umkehrschluss: mit Clean Code kann ich nur kleine
> Projekte oder halt Sammlungen (Treiber etc.) machen.
>
> Wenn 1000 eine Obergrenze ist, dann kann der Mittelwert (nach Pareto)
> nur bei wenigen 100 Zeilen liegen. Das ist für größere Projekte
> (>100.000 Zeilen) nicht sinnvoll.

Ich empfehle dir die Lektüre des Buches von Robert C. Martin.

merciless

: Bearbeitet durch User
Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
DPA schrieb:
> Dann konvertiert man die Daten halt einem kleinen
> Hilfsprogramm nach C, und kompiliert das dann. Auch das Hilfsprogramm
> kann man sich vorher noch automatisch von make erstellen lassen.

Solch ein Vorgehen entspräche aber nur dann der hier als Evangelium 
vermittelten Clean-Code-Lehre, wenn sich auch das Hilfsprogramm an die 
1000-Zeilen-Beschränkung hielte.

Autor: DPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> DPA schrieb:
>> Dann konvertiert man die Daten halt einem kleinen
>> Hilfsprogramm nach C, und kompiliert das dann. Auch das Hilfsprogramm
>> kann man sich vorher noch automatisch von make erstellen lassen.
>
> Solch ein Vorgehen entspräche aber nur dann der hier als Evangelium
> vermittelten Clean-Code-Lehre, wenn sich auch das Hilfsprogramm an die
> 1000-Zeilen-Beschränkung hielte.

Auch so ein Hilfsprogramm kann man in ein eigenes Unterverzeichnis 
packen, und in mehrere Dateien aufteilen. Man kann sogar gemeinsame 
Teile der Programme in Libraries auslagern oder einige Dateien in 
mehreren Programmen linken.

Normalerweise sind diese aber sehr viel kleiner. Bei meinem Fuserescue 
Projekt linke ich die Lizenz und das Readme mit rein, um es im Programm 
ausgeben zu können. Das Hilfsprogramm ist so kurz, ich hab es direkt in 
mein Makefile rein geschrieben: 
https://github.com/Daniel-Abrecht/fuserescue/blob/master/makefile#L26
(Im nachhinein betrachtet sollte ich das wohl noch so anpassen, dass man 
explizit angibt, wenn eine Datei unverändert eingelinkt werden soll.)

Autor: Jemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DPA schrieb:
> Die Konvertierung kann man auch beim kompilieren machen. Dazu nutzt man
> ein Makefile. Dem ist es egal, was in welcher Sprache/Format da ist, es
> macht was auch immer man ihm sagt das es soll, um das Programm zu
> erstellen. Dann konvertiert man die Daten halt einem kleinen
> Hilfsprogramm nach C, und kompiliert das dann. Auch das Hilfsprogramm
> kann man sich vorher noch automatisch von make erstellen lassen.

Statt einem Einzeiler brauche ich ein externes Tool, welches meinen 
Datensatz auf ein Vielfaches ihrer Größe aufbläst, und muss das auch 
noch ins Buildsystem verwursten. So richtig überzeugend ist das nicht.

DPA schrieb:
> Da das auch keine Unterstützung
> irgendwelcher speziellen/spezifischen Dateiformate in C selbst
> voraussetzt, ist die Lösung ja wohl auch viel versatiler und schöner.

C muss keine speziellen Formate unterstützen, C muss Compile-Time 
Codeausführung unterstützen.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
DPA schrieb:
>> Solch ein Vorgehen entspräche aber nur dann der hier als Evangelium
>> vermittelten Clean-Code-Lehre, wenn sich auch das Hilfsprogramm an die
>> 1000-Zeilen-Beschränkung hielte.
>
> Auch so ein Hilfsprogramm kann man in ein eigenes Unterverzeichnis
> packen, und in mehrere Dateien aufteilen. Man kann sogar gemeinsame
> Teile der Programme in Libraries auslagern oder einige Dateien in
> mehreren Programmen linken.

Es geht nicht um die Länge des Hilfsprogramms selbst, sondern dass 
dieses Hilfsprogramm so geschrieben sein muss, dass die von ihm 
erzeugten Dateien eine maximale Länge von 1000 Zeilen aufweisen.

Das führt natürlich zu der putzigen Situation, dass die Anzahl und die 
Namen der später zu kompilierenden Dateien plötzlich von dem Inhalt der 
Ausgangsdatei abhängen, d.h. gestern ergab die Binärdatei noch 997 
Zeilen, die heutige Version dann 1002 Zeilen. Entweder muss dann also 
das Hilfsprogramm auch noch die entsprechenden Makefiles generieren oder 
das Build-System muss Wildcards zulassen. Und das nur, weil jemand für 
C-Quelltexte eine 1000-Zeilen-Beschränkung in Stein gemeißelt hat. 
Super! Und in der eigentlichen Anwendung darf dann auch nicht auf ein 
großes Array zugegriffen werden, sondern jeder Zugriff muss über eine 
weitere Tabelle o.ä. erfolgen, in der auf das jeweilige Häppchen 
verwiesen wird. Ganz toll. Damit wird also ein gewaltiger Wasserkopf in 
der Anwendung geschaffen, nur um ein paar willkürliche Richtlinien 
umzusetzen.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Und das nur, weil jemand für C-Quelltexte eine
> 1000-Zeilen-Beschränkung in Stein gemeißelt hat.

Wer soll das getan haben?

Aber wenn es dir hilft, kannst du den Array-Initialisierer ja in eine
einzelne Zeile packen.

Autor: DPA (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jemand schrieb:
> DPA schrieb:
>> Die Konvertierung kann man auch beim kompilieren machen. Dazu nutzt man
>> ein Makefile. Dem ist es egal, was in welcher Sprache/Format da ist, es
>> macht was auch immer man ihm sagt das es soll, um das Programm zu
>> erstellen. Dann konvertiert man die Daten halt einem kleinen
>> Hilfsprogramm nach C, und kompiliert das dann. Auch das Hilfsprogramm
>> kann man sich vorher noch automatisch von make erstellen lassen.
>
> Statt einem Einzeiler brauche ich ein externes Tool, welches meinen
> Datensatz auf ein Vielfaches ihrer Größe aufbläst, und muss das auch
> noch ins Buildsystem verwursten. So richtig überzeugend ist das nicht.

In meinem verlinkten Beispiel wird das direkt per pipe in den gcc 
geschaufelt. Auf die art und weise wird die Datei nicht als ganzes 
verarbeitet, und die "Aufgeblasene" form muss nie irgendwo gespeichert 
werden. Im Binary ist es wieder die Form, in der man es ja sowieso 
braucht.

Und irgendwie verwurstet wird da auch nichts. Das Buildsystem ist dafür 
da, das man ihm sagt, wie man das Programm baut. Müsste man jedes 
Programm gleich bauen, bräuchte man es nicht, aber dann kann man es auch 
für nichts mehr brauchen.

Andreas S. schrieb:
> Es geht nicht um die Länge des Hilfsprogramms selbst, sondern dass
> dieses Hilfsprogramm so geschrieben sein muss, dass die von ihm
> erzeugten Dateien eine maximale Länge von 1000 Zeilen aufweisen.

Ich würde meinen, aus der Sicht der Clean-Code-Lehre ist generierter 
Code gar kein Code. Er wurde nicht geschrieben, also existiert er gar 
nicht. Die Dateien sind ja such nur Temporär, und können/werden auch 
immer wieder gelöscht.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jemand schrieb:
> C muss keine speziellen Formate unterstützen, C muss Compile-Time
> Codeausführung unterstützen.

Die Sachen für die ich gerne C-Code erzeugen will lassen sich in 
dynamischen Hochsprachen wie zum Beispiel Python viel einfacher und 
prägnanter hinschreiben und warten als wenn ich das in C machen würde. 
Man muss nicht alles nochmal neu erfinden wenn es schon fertige Tools 
gibt die man einfach nehmen kann.

Autor: Dirk K. (merciless)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> ...Geblubber entfernt

Schönes Wetter zum Trollen, gell?
Niemand kommt und schneidet dir die
Eier ab, wenn du mehr als 1000 Zeilen
in ein File packst, ganz besonders
dann nicht, wenn es sich um Daten
handelt, die eingebettet werden.

merciless

Autor: Erwin M. (nobodyy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es wenn man hier für jeden Kommetar zahlen müsste, z. B. zwei 
Cent; würde die Maßnahme den Spam/das Trollen hier verringen oder eher 
erhöhen, nach dem Motto "Ich habe doch dafür bezahlt"?
Gibt es dazu schon Studien?

Autor: Peter D. (peda)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Du hältst es also für wesentlich sauberer, als Array eingebettete
> Tabellen, Binärdateno.ä. in etliche Häppchen zu zerteilen

Wozu sollte man sowas verrücktes machen? Aus meiner Sicht ist das gar 
kein Code im herkömmlichen Sinn. Niemand muß darin irgendwelche 
Algorithmen und Abläufe verstehen oder ändern.
Ich würde solche Datenfelder sogar als eigenständiges Projekt aufbauen 
und dann die fertige Binärdatei zum ausführenden Code hinzufügen (linken 
oder anhängen).
Es kann auch sinnvoll sein, daß solche Datenfelder überhaupt nicht in 
den ausführbaren Code kommen, sondern in einen externen seriellen Flash. 
Man kann so Daten ändern oder hinzufügen, ohne die Applikation neu 
compilieren zu müssen. Z.B. um Schriftarten, Bilder, Sounds oder 
Animationen zu ändern.

Code ist für mich nur das, wo man auch Gehirnschmalz reingesteckt hat. 
D.h. Dein Nachfolger sollte die Abläufe darin verstehen können, um ihn 
warten und erweitern zu können.

Autor: Vlad T. (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich weiß, dass das Visual Studio 10 Probleme mit Code-Dateien über 65k 
+x Zeilen hatte.

Zumindest der Debugger kam damit überhaupt nicht klar. (Der Compiler 
hats anstandslos gefressen)

Aufgefallen war mir das, als ich ein Program debuggen wollte, was das 
SQLite  amalgamation - c File nutzte - ich musste damals das file auf 2 
oder 3 aufteilen.
Das aktuelle amalgamation file (--> 
https://www.sqlite.org/download.html) ist fast 223000 Zeilen groß.

: Bearbeitet durch User
Autor: leo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vlad T. schrieb:
> Das aktuelle amalgamation file (-->
> https://www.sqlite.org/download.html) ist fast 223000 Zeilen groß.

Wow, das ist ja x-fach krank:
- der Debugger (MS?) kommt nicht damit zurecht
- Entwickler nutzen wohl eher einzelne Files (schon mal "make -j" auf 
einer 64 CPU Sun gestartet) - i.e. die parallele Verarbeitung wird damit 
verhunzt
- Endanwender werden wohl ein fertiges Paket installieren

Zum TO - kommt darauf an, aber bei ca. 10k Zeilen wird wohl ein Split 
übersichtlicher.

leo

Autor: DPA (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
leo schrieb:
> Vlad T. schrieb:
>> Das aktuelle amalgamation file (-->
>> https://www.sqlite.org/download.html) ist fast 223000 Zeilen groß.
>
> Wow, das ist ja x-fach krank:

Ja, aber das ist bei den "amalgamation" also "Zusammenschluss" auch 
nicht erstaunlich. Warum die so einen scheiss bieten, keine Ahnung. 
Links zu den Repos hab ich hier gefunden: (abschnitt 3.1)
https://sqlite.org/whynotgit.html#the_official_github_mirror

Und als ich den mist unter: https://sqlite.org/copyright.html und 
https://sqlite.org/src/artifact/df5091916dbb40e6 gelesen habe, WTF. Also 
SQLite ist für mich tot.

Autor: Vincent H. (vinci)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
DPA schrieb:
> Warum die so einen scheiss bieten, keine Ahnung.

Ich vermute mal um auch ohne LTO möglichste kleine Binaries zu erzeugen.

Autor: Vlad T. (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DPA schrieb:
> Warum die so einen scheiss bieten, keine Ahnung.
> Links zu den Repos hab ich hier gefunden: (abschnitt 3.1)
> https://sqlite.org/whynotgit.html#the_official_github_mirror

ich fand es sehr bequem.
Einfach eine Datei dem Projekt hinzufügen und schon hat man sqlite drin.
Kein umständliches Lib-Bauen oder hunderte extra-files dem Projekt 
hinzufügen.

Außerdem bietet der Ansatz dem Compiler beste Möglichkeiten zur 
Optimierung.

hier ist dazu auch was:
https://www.sqlite.org/amalgamation.html

da steht auch was über ein split-amalgamation was sie anbieten wegen 
Debuggingproblemen über 32k lines. vielleicht hab ich mich auch um eine 
Potenz getäuscht.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erwin M. schrieb:
> Bei einigen .c-Dateien in einem Projekt zeigte sich eine Dateigröße von
> mehreren MB und mehrere zehntausend Zeilen Länge.
> Welche maximale Größe sollten Quellcodedatei haben, bezüglich Dateigröße
> und Zeilenanzahl?

Eigentlich ist die Frage in der Form unzureichend beschrieben, denn die 
.c oder .h Dateigröße ist eigentlich unerheblich. Wichtiger für den 
Compiler ist die Größe der Translation Unit, also das .i file ausgegeben 
vom Präprozessor. (Wer bei GCC bugs submittet soll auch immer die .i/.ii 
files nehmen, weil da alles zum Übersetzen/Reproduzieren des Fehlers 
enthalten ist und keine obskuren header fehlen.)

Eine andere Beschränkung wäre die maximale Größe für den AST.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DPA schrieb:
> Ja, aber das ist bei den "amalgamation" also "Zusammenschluss" auch
> nicht erstaunlich. Warum die so einen scheiss bieten, keine Ahnung.

SQLite ist kein normales Projekt, sondern vermutlich das weltweit 
meistverbreitete Stück Software. Das wird auch da eingesetzt, wo die 
Compiler- und Buildinfrastruktur wesentlich weniger gut ausgebaut ist.

Deswegen gilt dort noch immer C89 und kein Verlass auf 
Compilererweiterungen (wie z.B. LTO) oder Infrastruktur (wie z.B. make, 
CMake oder irgendwas anderes).

Autor: Johann J. (johannjohanson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erwin M. schrieb:
> Welche maximale Größe sollten Quellcodedatei haben, bezüglich Dateigröße
> und Zeilenanzahl?

424242 Byte mit rund 5300 Zeilen Code.
Aber ordentlich vollschreiben!

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.