[Video-Tutorial]: Programmieren in C -Teil1 [German]

Hallo liebe HaBo-Community! Ich habe vor, eine Reihe von Video-Tutorials zu produzieren in denen ich schrittweise das Programmieren in C unterrichte. Hier ist der erste Teil dieser Tutorial-Reihe und ich hoffe, dass die Lautstärke diesmal stimmt und alles gut zu verstehen ist. Falls nicht, bitte ich um entsprechendes Feedback.:)

Look: Programmieren in C -Teil1 [German] - YouTube
 
Moin,

dass du direkt das Kommentieren einführst find ich gut. ( "//" is böse ;) ) Hat mich letztens erst wieder genervt dass jemand seinen Code nicht vernünftig kommentiert hat.

Ansonsten: Ich weiß nicht wie viele deutschen Video-tuts es zu C gibt (Wahrscheinlich einige) aber ich find gut dass du direkt auch die nutzung von GCC zeigst.

Netter Einstieg muss ich sagen.

Grüße, lynx
 
Inwiefern Satire? Erkläre das bitte mal genauer und dann akzeptiere ich deine Meinung natürlich.
 
Früher sprach man bei solchen Sammlungen von Anleitungen zum Mailbomben und DDoSsen mit Hilfe diverser "Toolz" auch verächtlich und stark abwertend (!) von Scriptkiddies. Heute scheint man sich daran nicht mehr zu stören und es werden munter weiter Informationen im Netz verbreitet, die explizit auf dieses Client ausgelegt sind, also versuchen ihre minderwertige Qualität sogar noch hervorzuheben. Da die "Großen" das auch machen, würzt man das ganze noch mit etwas politischer Propaganda, die sich bei genauerer Betrachtung in nahezu allen Fällen als plumpes, unreflektiertes Nachplappern extremer Positionen entpuppt. Es gibt also zwei Antworten auf die Frage nach dem "Warum":
1. Du meinst es ernst und willst, dass sich Administratorinnen und Administratoren auch weiterhin mit nervigen Scriptkiddies rumschlagen müssen.
2. Du meinst es satirisch, übertreibst bewusst und willst eigentlich nur die minderwertige Qualität der vielen YT-Videos kritisieren.

Das C-Video unterstützt die zweite Antwort. Keine historischen oder fachlichen Hintergründe, dafür nur nervige Hintergrundmusik von Kid Rock, krude Behauptungen ohne fachlichen Begründungen schon ab Zeile 1 und irgendwas von "mathematischen Grundlagen", 1337-Desktopoberfläche mit obligatorischem Exploitz-, DDOS-Toolz- und Pornz-Ordner, usw.. Eigentlich fehlt nur die Anonymous-Stimme und die Nutzung von generierter 1337-ASCII-Art. Die typische satirische Übertreibung macht aber trotzdem auch hier keinen Halt, sodass man wieder nur breit grinsen kann.
 
Zuletzt bearbeitet:
Inwiefern Satire?

Realsatire dann eben. :wink: Das ist schon sehr offensichtlich bei der Aufmachung (siehe SchwarzeBeeres Kommentar).

Mir gefallen auch diverse Schmankerl wie z.B., dass printf angeblich für "print file" stünde. Hat natürlich nichts damit zu tun, dass man damit einen String formatieren kann. :D

Ich danke in jedem Fall für das Video. Ich habe mich herzlich amüsiert. :)
 
Vielen Dank für die konstruktive Kritik!:) Nur sollte man auch bedenken, dass Wissen stets frei ist und wir alle danach streben. Von daher finde ich es eigentlich weniger schlimm, wenn man verbreitet wie man z.B. einen Mailbomber/Fakemailer erstellen kann. Auf die "Anmache" bezüglich des Desktop-Hintergrundes gehe ich garnicht ein, denn das ist jedem seine eigene Entscheidung, wa. Solange man nicht Kacke-Adolf o.ä. als Hintergrundbild verwendet. Aber sonst okay und ich werde weiter an Besserung arbeiten. Vielen Dank!
 
Als Tipp: wenn Du bei Beere punkten willst, müsstest Du so etwas als Hintergund verwenden :)
WDTfNBa.jpg
*scnr*

Damit es nicht ganz offtopic wird:
ich bin nicht gerade ein Fan von Videotutorials für Programmiersprachen, daher nur "durchgescrollt":
Nicht so schön finde ich die "Projektorganisation" a la "alles auf dem Desktop".
Zudem steht GCC für Gnu Compiler Collection und nicht Collective Compiler ;)

Nicht zuletzt: moderne Shells bieten Autoergänzung bis zum "abwinken".
D.h man/frau muss nicht mühsam eine Anweisung oder gar den Pfad komplett eintippen, sondern kann Tab+Pfeiltasten einsetzen (ggf. müssen einige Features bei den konservativ vorkonfigurierten Shells explizit freischalten) und bekommt auch Vorschläge/Autorergänzung bei Programmargumenten ;)
Zumindest könnte man die "Tipperei" bei der Nachbearbeitung ausschneiden.
 
Unabhängig von den hier bereits genannten Kritikpunkten, will ich noch einiges ergänzen.

Wenn man schon auf Kommentare eingeht, dann sollte man auch gleich erläutern welche Formen von Kommentaren es gibt (// vs /* */). Die Struktur der Erklärung geht verloren, wenn man erst später darauf eingeht. Dass nicht erläutert wird, dass /**/ für mehrzeilige Kommentare verwendet werden kann, sehe ich auch als Manko.

Wenn man eine Compiler-Direktive eingibt (#include) sollte man diese auch so benennen und erklären was es damit auf sich hat.

Wenn man eine Header-Datei verwendet, sollte man auch erläutern, dass diese im Prinzip Schnittstellen zu den im System abgelegten Programm-Bibliotheken bilden, man damit also dem Compiler sagt, dass man die Funktionen, die in dieser Datei deklariert sind, nutzen will. Ggf. ein kurzer Hinweis darauf, dass in zukünftigen Videos näher auf die Einbindung von Bibliotheken eingegangen wird. Damit dies verstanden werden kann, muss man natürlich vorher darauf eingehen was eine Funktion ist und wie man diese anwendet. Auch sollte man vielleicht erwähnen, warum man ausgerechnet die stdio.h verwendet und nicht irgendeine andere, damit klar wird, dass in der stdio.h eben nur eine Teilmenge der in C verfügbaren Funktionen deklariert ist. Ggf. auch gleich auf den Unterschied zwischen Deklaration und Definiton eingehen.

Weiterhin sollte man beim Einbinden von Headern die unterschiedlichen Möglichkeiten der Einbindung erklären ("" vs <>).

Wenn man die main-Funktion beschreibt, sollte nicht nur auf die Parameter eingegangen werden sondern auch darauf, dass dies der Eintrittspunkt für den Compiler darstellt sowie wie und warum man einen Rückgabetyp definiert. void main() wäre schliesslich auch möglich gewesen.

Wenn man die Abkürzungen, die ein Funktionsname darstellt, nicht kennt, sollte man sich informieren, was sie bedeutet. Es wurde ja bereits darauf hingewiesen, dass printf() nicht für print file sondern für print formatted steht. Du verwendest ja dann später auch eine Formatanweisung oder genauer gesagt eine Escape-Sequenz im Video. Auch wenn SDTOUT/STDERR im Prinzip auf den meisten Systemen eine Datei darstellt, auf die ausgegeben wird, ist das keineswegs bei allen Systemen so, auf denen C Anwendung findet. Hier könnte ein Anfänger also falsche Rückschlüsse ziehen.

Wenn man eine Escape-Sequenz wie den Zeilenumbruch verwendet, sollte man auch erklären was es damit auf sich hat und vielleicht auch kurz auf andere wie \t oder das Escapen von Anführungszeichen eingehen.

Es ist schlichtweg falsch, dass man die ZEILE mit einem Semikolon beenden muss. Das Semikolon zeigt das Ende der ANWEISUNG an.

Es ist gleichmaßen falsch, dass 'return 0;' am Ende nicht notwendig ist. Aufgrund dessen, dass du ein Integer als Rückgabewert für main() definiert hast, ist es sehr wohl notwendig. Sonst wird ein impliziter Wert angenommen, der nicht immer dem Wunsch des Entwicklers entsprechen muss. Der Bezug dazu hätte im Video dargestellt werden müssen, da ältere Versionen vom GCC einen fehlenden Rückgabewert in einer Nicht-void-Funktion durchaus auch beanstanden und es spätestens bei anderen Funktionen als der main() wichtig wird.

Im Fehlerfall wird auch nicht immer eine 1 zurückgegeben sondern ein Wert ungleich 0. Da hätte man auch gleich näher auf den Begriffe Rückgabewert eingehen können und was es damit auf sich hat.

Leider impliziert das Video, dass die geschweifte Klammer die Funktion schliessen würde. Auch das ist nicht ganz korrekt, denn die geschweifte Klammer schliesst einen Anweisungsblock, der auch eine Funktion sein kann, aber nicht muss.

Insgesamt fehlt dem Video also noch etwas Struktur und Hintergrundinformationen zur eingesetzten Syntax. Du hast versucht zu viele Informationen in ein Video zu packen.
Um Anfängern nicht von Anfang an schlecht lesbaren Code beizubringen, sollte man Code in solchen Videos immer entsprechend einrücken, wodurch man dann auch gleich den Begriff Anweisungsblock hätte näher erläutern und auf die Lesbarkeit eingehen können. Will man bestimmte Informationen erst in späteren Videos einbringen, sollte darauf verwiesen werden. Insgesamt würde ich empfehlen, dass du selbst erstmal mehr Erfahrung sammelst, bevor du versuchst mit deinem derzeitigen Kenntnisstand anderen Wissen zu vermitteln. In ein paar Jahren wirst du dir vermutlich selbst vor die Stirn hauen und dir denken: "Wie konnte ich nur so'nen Mist verzapfen." ;) Konzentriere dich lieber auf Themen, mit denen du dich wirklich auskennst. Aktuell merkt man dem Video leider an, dass auch bei dir das Wissen noch in den Kinderschuhen steckt.

Es ist dennoch lobenswert, dass du dein Wissen weiter verbreiten willst. Nur ist dein Ansatz für die Video-Reihe aus Lehrsicht nicht gerade zielführend. Eine Struktur wie die folgende würde dem Video-Kurs sicherlich besser bekommen:
1. Was sind Daten, Datentypen, Variablen und Konstanten und wie geht der Computer damit um
2. Was sind Anweisungen und Funktionen und wie wendet man diese an
3. Was sind Bibliotheken und wie bindet man diese ein und verwendet ihre Funktionen (hier auch gleich auf Compiler-Direktiven eingehen)
4. ...
Dadurch könnte wesentlich intensiver auf die Bestandteile eines Programms eingegangen werden und mehr Hintergrund erläutert werden.

Lass dich aber nicht von der ganzen Kritik entmutigen! Jeder von uns hat mal klein angefangen. Mach weiter, aber konzentriere dich erstmal auf die Themen, mit denen du dich wirklich gut auskennst. Du wirst feststellen, dass du dadurch auch schnell Erfahrungen darin sammelst was in solchen Kursen wichtig ist und wie man sie gut strukturiert. :)
 
Von daher finde ich es eigentlich weniger schlimm, wenn man verbreitet wie man z.B. einen Mailbomber/Fakemailer erstellen kann.
Die Frage ist nicht das "was", sondern das "wie". Es ist nicht schlimm, wenn man die Hintergründe eines Mailbombers erklärt, oder wie (moderne) DDoS Angriffe funktionieren. Oder wie heute übliche Schutzmechanismen gegen diese Angriffe vorgehen - und wie man diese umgehen könnte. Schlimm ist, dass es auf so eine banale Art und Weise erklärst, dass nicht mehr das Wissen im Vordergrund steht, sondern nur noch der blose Hang zur Destruktivität. Insofern bleib mir bitte weg mit diesem pseudo-philosophischen Scheiss, dass Wissen frei ist. Darum geht es in deinen Videos nicht. Es geht um minderwertigen Stoff für Scriptkiddies. Und das ist verachtenswert.

Und ja, wenn du deinen Bildschirmhintergrund cool findest, benutze ihn bitte. Wenn es in deinem Video um deinen Desktop gehen soll, dann passt das perfekt. Beim Thema C-Programmierung geht es aber offensichtlich nicht um deinen Hintergrund und auch nicht um deine Vorliebe nach "Pornz". Es geht nicht um dein Ego, nicht um bd0rk und seine absolute Coolness. Sondern um C. Ich weiß, heutzutage ist diese Art der Kommunikation relativ unbeliebt, gerade auf YT, wo Selbstdarstellung, Egozentrik, Götzentum und die damit verbundene Inhaltslosigkeit geradezu Voraussetzungen für Erfolg zu sein scheinen. Aber bitte, bitte, bitte. Wenn du ernsthaft Inhalte produzieren und publizieren willst: Stell die Inhalte in den Vordergrund und nicht dein eigenes Ego.
 
Zuletzt bearbeitet:
Hallo liebe HaBo-Community! Ich habe vor, eine Reihe von Video-Tutorials zu produzieren in denen ich schrittweise das Programmieren in C unterrichte.

Du kannst nicht C unterrichten, da du selbst kein C kannst. Du lehrst mehr Fehler in einem "Hallo Welt" Programm, als das Programm Funktionen hat.
- printf
- return
- Anweisungsblöcke
- "leerer" Datentyp in Main

Z.B. bedeutet void in main() nicht "leerer Datentyp" (das gibts ohnehin nicht), sondern dass du eine Argumentenübergabe explizit ausschließt. Im Detail ist das ein wesentlicher Unterschied (anders als bei C++). Überhaupt ist auch die Bezeichnung Datentyp falsch, da die eingehenden Daten eine "Argumentenliste" ist. Und die Argumente sind bis dahin auch erst mal Typenlos - also keine definierten Datentypen. Darüber hinaus ist "void" selbst kein Datentyp, sondern das krasse Gegenteil in Form eines Schlüsselworts für den Compiler.

Es ist durchaus löblich dass du Wissen vermitteln willst. Aber:

- Wissen geht vom Meister an den Schüler, nicht umgekehrt.

- Sprache: Bei diesen Themen sind wir alle (besonders Anfänger) auf eine absolut exakte Sprache angewiesen (leerer Datentyp). Du "meinst" zwar das richtige, aber das ist in diesem Fall nicht das gleiche. Ein gutes Lehrwerk zeichnet sich IMMER durch die Sprache aus (die codebeispiele sind immer die gleichen).


Lass dir (und den anderen) die nötige Zeit. C ist eine mächtige aber oftmals schwer zu erlernende Sprache und jeder Typ, der dir was anderes erzählt ist entweder außergewöhnlich begabt oder ein Spinner. In jedem Fall wirst du aber davon profitieren und viel über das "Innenleben" eines Rechners lernen.
 
Eure Kritik ist hart aber dennoch hilfreich und vorallem ehrlich, wie ich finde und dafür danke ich auf jeden Fall! Man könnte natürlich auch sprichwörtlich Scheisse in Geschenkpapier einwickeln und diese übergeben. Es bleibt ja trotzdem Scheisse, wa.^^ Ich werde in Zukunft auf genaue Beschreibung/Erklärung achten, wenn ich ein Tutorial anfertigen sollte. Wie dem auch sei... Danke für die ehrliche Kritik! ...und ob ich C kann oder beherrsche ist 'ne andere Frage, denn zwischen KÖNNEN und BEHERRSCHEN liegt dennoch ein Unterschied. Man lernt nämlich nie aus, wa.
 
Es wurde bereits viel kritisiert, deswegen möchte ich dir eigentlich primär ein paar Tipps geben, wie du so ein Tutorial aufbauen kannst. So ein Vorhaben ist nämlich deutlich schwieriger, als die meisten Leute annehmen.

Begriffe
Benutze neue Begriffe erst, wenn du sie auch einführst (im Video: Compiler, Linker). Pass auf, dass du nicht zu viele neue Begriffe auf einmal einführst, das sorgt nur für Verwirrung.
Überlege dir gut, wie du einen Begriff einführst. Folgende Überlegungen und Beispiele (die Beispiele solltest du so nicht übernehmen, ich habe mir nicht viel dabei überlegt) können dabei helfen:
  • Welche Merkmale / Eigenschaften hat der Begriff bzw. Gegenstand (Bsp. Compiler: Macht aus einer Textdatei ein ausführbares Programm)
  • Alle Gegenstände, welche unter diesen Begriff fallen (Bsp. Datentypen: int, long, float, char, ...)
  • Begriffsnetz: Falls möglich, mit bereits gelerntem vernetzen
  • Fehlerwissen: Dieses kann bereits vorhanden sein oder erst nach der Einführung des Begriffs auftauchen (Bsp. Datentypen: void ist ein Datentyp). Unbedingt ansprechen!
Die Liste basiert auf Fachdidaktik Mathematik, Kapitel 7 (S. Prediger und G. Wittmann).

Grobplanung
Das wichtigste ist, dass Dein Tutorial einen klaren Aufbau hat (siehe bitmunchers Kommentar) und sich somit ein roter Faden nicht nur durch ein einzelnes Kapitel, sondern durch die ganze Serie zieht. Damit du das erreichst, empfehle ich dir folgendes: Erstelle ein Mind Map, auf welchem du die wichtigsten Eigenschaften von C festhältst (z. Bsp. Datentypen, Funktionen, Compiler, Speichermanagement, ...). Mir fällt es so relativ leicht zu sehen, was wovon abhängig ist und kann dann so den groben Ablauf (welches Video kommt wann) einfacher planen. Ein grösseres Themengebiet kannst du dann auch gleich in mehrere Teile (Videos) splitten.
Falls du kein Fan von Mind Maps bist, suche dir eine andere, für dich bessere, Methode.

Lektionsplanung
Aus deiner Grobplanung nimmst du jetzt die Einzelnen Lektionen und überlegst dir ganz genau, was dein Publikum am Ende des Videos können soll (in der Schule nennt sich das ganze Lernziele ;) ). Auch hier kannst du wieder ein Mind Map erstellen, falls du das Gefühl hast, es hilft.
Ich mache das mal für den Compiler (Achtung: auch hier wieder Stichwortartig und nicht vollständig):
Mein Publikum...
  • ... kann einen Compiler installieren
  • ... weiss, was die Aufgabe des Compilers ist
  • ... kann das "Hallo, Welt" Programm kompilieren
  • ... weiss, wie auf Fehlermeldungen reagiert wird

Diese Lernziele kannst du dann auch gleich in die Beschreibung packen, dann wissen deine Zuschauer, was sie erwartet. Es ist wohl selbstverständlich, dass du nicht zu viele Lernziele in ein Video reinpackst :wink:. Falls nötig, ein Thema auf mehrere Videos verteilen.

Jetzt kannst du dir den Ablauf des Videos notieren: Wie willst du welchen Aspekt erklären? Ist es einfacher zu erklären, wenn ich ein Bild habe statt nur mit Worten erkläre? Wenn das Video eine fixe länge haben soll: Wie lange dauern die einzelnen Sequenzen?

Und am wichtigsten von allem, die alte Grundregel: Versuche immer, von etwas bekanntem zum unbekannten zu gelangen und vom einfachen zum schwierigen.

Schreibe die neu gelernten Begriffe aus dem Video für dich heraus, dann kannst du auch in künftigen Videos darauf verweisen. Und wie Chromatin bereits völlig richtig geschrieben hat: "Ein gutes Lehrwerk zeichnet sich IMMER durch die Sprache aus". Wenn du nicht mehr sicher bist, wie du etwas genannt hast (habe ich den englischen oder den deutschen Begriff benutzt?), findest du es sofort.

Du siehst, wenn du ein seriöses und gutes Tutorial machen willst, musst du auch noch einiges an Zeit in die Planung investieren. Lass dich davon aber nicht abschrecken, die Planung macht genauso viel Spass wie danach das Video aufzunehmen! Vielleicht kannst du dir ja ein Projekt ausdenken, welches sich durch die ganze Videoreihe zieht?
Auch ein Punkt den du dir überlegen solltest: Wieso willst du eine eigene Videoreihe machen, es gibt doch schon so viele Tutorials? Ich will dich mit dieser Frage nicht demotivieren sondern lediglich dazu anregen, dass du dich fragst, was du anders oder besser machen willst als die anderen.

Es gibt natürlich noch viele andere Aspekte, aber dieser Post ist bereits länger als ich ursprünglich geplant hatte... Falls ich mich irgendwo nicht klar oder ausführlich genug ausgedrückt habe, einfach nachfragen ;) Und lass dich nicht entmutigen!
 
Zurück
Oben