Source lesen und verstehen lernen
-
knivil schrieb:
Falls du eine Programmiersprache lernen moechtest, dann bestimmt nicht ueber den weg, Sourcecode anderer zu lesen und versuchen zu verstehen.
Ging bei mir damals mit BASIC ganz prima
Wenn man im Übrigen ein wenig Ahnung vom Zugrundeliegenden hat, ist es auch halbwegs machbar, sich eine der modernen Sprachen auf diesem Wege anzueignen. Auch wenn es natürlich stets die extremste Form der Autodidakik mit sämtlichen ihrer Probleme darstellst.
-
+fricky schrieb:
Linux-Progger schrieb:
In großen C Projekten ist das übrigens deutlich schwerer als in großen OOP Projekten
ach nö, in gut gemachten C-projekten gibts auch funktionale einheiten, die bestimmte aufgaben übernehmen, öffentlich schnittstellen, private attribute, usw. kannste so pauschal nicht sehen, dass nur OO-programme gut analysierbar sind.
Klar, aber kurzes Nachdenken liefert die Erkenntnis, dass diese nur Konventionen sind und somit in Doxygen, oder anderen Dokumentations-/Quellcodetools nicht sichtbar sind.
-
Sorry war übers Wochenende nich da ..
hustbaer : das seltsame ist, das ich mit keinem Wort erwähnt habe, dass ich nicht programmieren kann ^^
Ich sagte nur, dass wenn ich programmieren lernen wollte, dass ich es nicht so anfangen würde.Geh mal davon aus, dass wenn ich schon sourcen analysieren will, dass ich schon programmieren kann, sonst würde das kaum Sinn ergeben oder ?
Linux-Progger : genau den Ansatz der rekursiven analyse hab ich versucht, z.B. bei Gimp, das war schon etwas komplexer, hab ja mit so großen Projekten bisher noch nicht gearbeitet, mit entsprechendem Zeitaufwand sicherlich zu machen.
Das Problem war das nur, dass so gut wie kaum dokumentation vorhanden war und ich so nach dem 10 header mit source dann schon so viele sourcen auf hatte, dass ich leicht den überblick verlohren habe auf welche inhalte sich die header noch beziehen.Wenn ich jetzt davon ausgehe ich möchte in solcher Software nur bestimmte funktionen lokalisieren, hat mich dieses vorgehen leider nicht so sehr weiter gebracht und die namensgebung half mir da nicht so sehr weiter, ich bekomm zwar nen grobem eindruck was die aufgabe sein könnte, aber mir fehlt dann noch der überblick worauf sich änderungen überall auswirken könnten und wo es evtl. probleme verursachen könnte änderungen vorzunehmen.
Ich werde nochmal in eine etwas kleinere hoffentlich überschaubarere Source reinschauen um zu sehen, wieviel ich davon verinnerlichen kann.
Würde nur gern wissen, ob hier jemand schon diesen weg gegangen ist um z.B. an Linux selbst zu arbeiten oder auch irgendwelcher größeren Anwendungssoftware.
Und wie ihr dabei vorgegangen seid.hustbaer : du sagst du machst das auf Arbeit ?
wie sieht das bei dir aus ? Welchen weg gehst du dabei ?
-
Linux-Progger schrieb:
+fricky schrieb:
Linux-Progger schrieb:
In großen C Projekten ist das übrigens deutlich schwerer als in großen OOP Projekten
ach nö, in gut gemachten C-projekten gibts auch funktionale einheiten, die bestimmte aufgaben übernehmen, öffentlich schnittstellen, private attribute, usw. kannste so pauschal nicht sehen, dass nur OO-programme gut analysierbar sind.
Klar, aber kurzes Nachdenken liefert die Erkenntnis, dass diese nur Konventionen sind und somit in Doxygen, oder anderen Dokumentations-/Quellcodetools nicht sichtbar sind.
klar, aber ein wenig praktische erfahrung liefert die erkenntnis, dass es egal ist. ich hab' z.b. mit understand C und C++ projekte und mit 'visual uml' Java-projekte seziert. im grunde können reverse engineering tools immer nur eine grobe 'mittlere' struktur sichtbar machen (was natürlich schon sehr hilfreich ist). aber was die feinheiten angeht und den blick aus der vogelperspektive muss man sich selbst erarbeiten. wie schnell man's schafft, hängt z.b. davon ab, ob die programmierer der software gnadenlose abstrahier-freaks oder pragmatiker waren.
-
spätestens, wenn man in die Verlegenheit kommt, 100K+ Zeilen an vorhandenen Algorithmen auf neue, erweiterte Datenstrukturen anwenden zu sollen, wird man aber merken, daß manchmal:
$Abstraktion $Abstraktion dient letztendlich dazu, Implementations- und vor allem Denk-Arbeit zu sparen, und das *ist* Pragmatismus, gemäß dem E=mc^2 der Wirtschaft:
$Zeit Geld$
-
u_ser-l schrieb:
Abstraktion dient letztendlich dazu, Implementations- und vor allem Denk-Arbeit zu sparen, und das *ist* Pragmatismus...
nur wenn man's nicht übetreibt. sonst geht die sache nach hinten los.
-
was ich sagen will: Abstraktion und Pragmatismus müssen bei der Programmierung kein Widerspruch sein - gerade, wenn es um Software geht, die später portiert, erweitert oder sonst wie verallgemeinert werden soll. Da stellt sich Abstraktion im Nachhinein oft als der bessere Pragmatismus heraus.
-
u_ser-l schrieb:
was ich sagen will: Abstraktion und Pragmatismus müssen bei der Programmierung kein Widerspruch sein - gerade, wenn es um Software geht, die später portiert, erweitert oder sonst wie verallgemeinert werden soll. Da stellt sich Abstraktion im Nachhinein oft als der bessere Pragmatismus heraus.
das sehe ich genau so. die frage ist nur, wie weit man abstrahieren sollte. zu wenig ist schlecht, aber zu viel auch.
-
ZSchneidi schrieb:
hustbaer : das seltsame ist, das ich mit keinem Wort erwähnt habe, dass ich nicht programmieren kann ^^
Ich sagte nur, dass wenn ich programmieren lernen wollte, dass ich es nicht so anfangen würde.Wenn ich mich richtig erinnere, wurde es unterstellt, und du hast die Unterstellung nicht berichtigt. Und damit den Eindruck bei mir erzeugt, du könntest nicht - oder nicht gut - programmieren. Aber egal.
Geh mal davon aus, dass wenn ich schon sourcen analysieren will, dass ich schon programmieren kann, sonst würde das kaum Sinn ergeben oder ?
OK
hustbaer : du sagst du machst das auf Arbeit ?
wie sieht das bei dir aus ? Welchen weg gehst du dabei ?Das ist schwer in ein paar Sätzen zu beschreiben
Wichtig ist erstmal es sich nicht selbst unnötig schwer zu machen. D.h. verwende sämtliche Tools die dir die Arbeit erleichtern könnten.
Tools wie Doxygen, Visual Assist X, ...
Dazu wiederum ist es sinnvoll, wenn du erstmal das Programm bauen kannst. Wenn das nicht baut (wegen falscher Include-Pfade, fehlender externer Dependencies etc.), dann tun sich diverse Tools auch entsprechend schwer, das korrekt zu analysieren.Und dann versucht nicht das Programm als ganzes zu verstehen. Verschaff dir einen groben überblich über den Stil und die verwendeten Patterns des Programms. Jeder Programmierer und jedes Team arbeitet etwas anders, und wenn du ein Feeling dafür entwickelst wie der/die Programmierer so drauf waren, die etwas geschrieben haben, dann tust du dich schonmal leichter. Dazu siehst du dir einfach mehr oder weniger zufällig einige Header-Files und Source-Files an, und guckst einfach was die da alles an Patterns/... einsetzen. Zusätzlich kannst du Doxygen verwenden, z.B. um schöne Vererbungs-Graphen zu bekommen, Cooperation-Graphen (wer ruft was auf, wer verwendet welche Klassen) etc.
Meiste verwende ich nichtmal Tools ala Doxygen dazu, weil es vermutlich länger dauern würde ein Doxyfile zu basteln, Doxygen laufen zu lassen etc., als wenn ich es "ohne Hilfe" macht. Aber wenn das Projekt eine gewisse Grösse hat, dann mache ich das durchaus.
Wenn du deinen "groben Überblick" hast, dann pick dir ein paar Dinge raus die du dir angucken möchtest. z.B. das Plugin Interface bei GIMP, oder was auch immer. Davon siehst du dir dann den Code an, und arbeitest dich halt durch. Dabei helfen ungemein eine gute IDE, und evtl. Tools ala Visual Assist X. Ist halt ein Unterschied ob man eine Funktion die irgendwo aufgerufen wird von Hand suche muss, oder einfach den Cursor auf den Funktionsnamen stellt, und Alt + G drückt
(Dasselbe für Klassen und Variablen)
-
hustbaer : Das war zumindest schon mal ganz hilfreich.
Da die Mehrheit eher dazu neigt, sich der Unterstützung von Tools zu bedienen, werde ich wohl den gleichen Weg versuchen.Da ich unter Linux arbeite kann ich leider nicht auf VAX zurückgreifen, werde mir aber Doxygen mal ansehen und testweise mit kleinerer Software anfangen.
Seltsam ist nur, dass bei den Sourcen immer möglichst wenig documentation vorhanden zu sein scheint ^^ Dann eben den langen weg.
Dank dir erstmal, soweit.
-
Eine wichtige Frage bleibt offen: Warum willst du Sourcecode lesen und verstehen?
Z.B. in der Kunst: Einem Bild sieht man auch nicht an, wie es entstanden ist: http://www.artyfactory.com/art_appreciation/animals_in_art/pablo_picasso/pablo_picasso.htm
-
knivil schrieb:
Eine wichtige Frage bleibt offen: Warum willst du Sourcecode lesen und verstehen?
manche wollen nun mal wissen, wie irgendwas funktioniert. nennt sich 'neugier'
findest du das so ungewöhnlich?
-
Sourcecode von besonders fähigen Programmierern zu studieren ist eine sehr gute Methode, den eigenen Codestil zu verbessern.
-
u_ser-l schrieb:
Sourcecode von besonders fähigen Programmierern zu studieren ist eine sehr gute Methode, den eigenen Codestil zu verbessern.
Jetzt geht es nur noch darum, zu beurteilen, wer denn ein besonders fähiger Programmierer ist und wer nicht. Das ist natürlich ein Kinderspiel, gerade wenn man am eigenen Stil zweifelt.
-
Ich werd mir natürlich nicht blindwegs von irgendwelchen Codern den Stil aneignen... Aber +fricky und u_ser-l habens schon gut erfasst.
Es geht für mich in erster Linie darum zu sehen, wie fähige leute ihre Probleme lösen und wie sie ihre Programme strukturieren.
Und da ich Gimp für schon sehr gute Software halte, wollte ich sehen, wie die Köpfe dahinter so ticken
Ich versuche mir einfach ein Bild davon zu machen, wie große Projekte aufgebaut werden, da ich selbst bisher nur kleinere Software bzw. teile einer Software mitentwickle, ohne den groben Überblick über ein ganzes zu haben.
-
Und da ich Gimp für schon sehr gute Software halte
-
hustbaer schrieb:
Und da ich Gimp für schon sehr gute Software halte
Hehe, warum? Wegen dem Anti-MDI-Design?
-
_matze schrieb:
Jetzt geht es nur noch darum, zu beurteilen, wer denn ein besonders fähiger Programmierer ist und wer nicht. Das ist natürlich ein Kinderspiel,
Dazu gibt es zwar keine 100% treffsichere Methode, aber Anhaltspunkte gibt es schon.
z.B.
* wer richtungweisende Software im Alleingang herstellt, ist oft auch ein besonders fähiger Programmierer, von dem man etwas lernen können wird.
* wer es schafft, ein Programm für einen bestimmten Zweck in 1000 übersichtlichen Zeilen zu programmieren, wo alle anderen dafür 10000 Zeilen brauchen, ist wahrscheinlich ein besonders fähiger Programmierer.
* Sourcen, die kaum Kommentar enthalten, und dennoch sofort erfaßbar sind, zeugen von einem fähigen Programmierer.
* Sourcen, die die ganze Bandbreite syntaktischer Konstrukte einer Prog.Sprache nutzen (und nicht nur einen Teil davon), stammen oft von fähigen Programmierern.
usw ...
-
u_ser-l schrieb:
Sourcecode von besonders fähigen Programmierern zu studieren ist eine sehr gute Methode, den eigenen Codestil zu verbessern.
Man kann auch ein gutes Buch drueber lesen und sich selbst an den Beispielen ausprobieren. Fuer die Beurteilung von Buechern geben genug Personen bei z.B. amazon.de Bewertungen ab, so dass man nicht die Katze im Sack kauft. Das halte ich fuer die bessere Alternative. Was bringt es einem, sich 1 Monat mit Quelltext zu befassen, nur um festzustellen, dass er Schrott ist. Auch kann man nicht von den Aeusserlichkeiten einer Anwendung auf deren Inneres (z.B. Gimp) schliessen.
... ganze Bandbreite syntaktischer Konstrukte einer Prog.Sprache nutzen ...
Dafuer kenne ich genug Gegenbeispiele. Auch der Rest deiner Aussagen ist zu pauschal. Was ist "richtungsweisend", "uebersichtlich" und "erfassbar"? Diese Grenzen sind bei jedem anders, gerade wenn es um Anfaenger vs. Profis (jahrelange Erfahrung) geht. Ideen koennen auch auf abstrakter Ebene wesentlich besser verdeutlicht werden. Persoenlich schaue ich mir nur Code an, wo ich es muss. Sonst wird nur mit den bereitgestellten Interfaces und deren Beschreibung gearbeitet.
Letztendlich geht es darum, wie man selbst guten Code/Architektur/Software produziert und nicht wie andere es erreichen. Es ist also ein Umweg, anderen Sourcecode zu studieren. In der iX 04/2009 war nen kleiner (netter) Artikel ueber Richtlinien drin, wie man seine eigene Codequalitaet verbessern kann.
-
ich denke ja nicht an so große Zeitspannen wie 1 Monat - diese Zeit ist natürlich besser in Studium von Büchern und eigene Programmieraufgaben investiert. Monatelang den Quellcode eines Großprojekts wie firefox zu studieren, würde ich auch nicht empfehlen, es sei denn, man will am Projekt teilnehmen.
Aber mehrere Stunden oder Tage in hochwertigen Sourcen zu schmökern, oder immer mal wieder hineinzuschauen, schadet dem Codestil eines Anfängers bestimmt nicht. Macht doch auch Spaß, zu sehen, wie andere Leute bestimmte Funktionen implementieren, vor allem, wenn der Code wirklich gut ist.
