Hallo, wenn man als Anfänger seinen eigenen Code bewerten soll, welche Anhaltspunkte würdet ihr wählen?
jetzt mal unabhängig von funktioniert/ funktioniert nicht oder versetht es ein andere ja/ nein
Ich denke nicht das ein Anfänger (vlt. sogar jeder) seinen eingenen Code sinnvoll berwerten kann. Was ein Anhaltspunkt sein könnte: wenn du nach einer Weile deinen Code ändern oder erweitern willst und dabei größere Schwierigkeiten hast, dann ist der Code schlecht dokumentiert oder strukturiert.
USS schrieb: > wenn man als Anfänger seinen eigenen Code bewerten soll, welche > Anhaltspunkte würdet ihr wählen? Die klassische Bewertung eines Programmcodes (oder allgemeiner eines Algorithmus), in jeder Informatik-Grundvorlesung, geht nach dem Aufwand den der Prozessor hat die Aufgabe zu bearbeiten, also die Anzahl der Maschienbefehle die (nicht der code lang ist sondern die) ausgeführt werden um das Problem (inklusive Fehlerbearbeitung) zu lösen. So sind Programme, die eine Aufgabe mit mehr Rechenaufwand lösen, schlechter als solche, die es schneller mit weniger Aufwand hinbekommen. Es gibt da ganze Notationen mit O(n) als Komplexitätsbetrachtungen von Algorithmen. Das macht man in der Grundvorlesung mit einfachem code (z.B. Sortieralgorithmen), später wird vorausgesetzt daß man den Aufwand den man dem Prozessor aufhalst abschätzen kann. Leider besuchen viele self taught programmes keine Grundvorlesung. Üblicherweise gilt, daß Programme die weniger Aufwand enthalten, auch einfacher zu erweitern und warten sind.
Michael B. schrieb: > Die klassische Bewertung eines Programmcodes ... geht nach dem Aufwand > den der Prozessor hat die Aufgabe zu bearbeiten Das ist nur ein Aspekt. Was ist mit Testbarkeit, Fehlerverhalten, Wartbarkeit (nicht als Nebeneffekt), Dokumentation und (dank der BLWer) Time-to-Market?
Danke für die Rückmeldungen. Michael B. schrieb: > Informatik-Grundvorlesung, habe so eine Vorlesung nie besucht, das grobe Zeug, was ich beherrsche, selber beigebracht. =) Michael B. schrieb: > Anzahl der > Maschienbefehle wie kann ich das in meinem konkreten Fall herausfinden? Also was ich so höre, hängt es von der Hochsprache usw ab
Michael B. schrieb: > So sind Programme, die eine Aufgabe mit mehr Rechenaufwand lösen, > schlechter als solche, die es schneller mit weniger Aufwand hinbekommen. Das stimmt so pauschal sicher nicht. Manchmal ist genug Rechenzeit da, aber der Speicher ist knapp. Dann wäre es unklug, wenn man einen Algorithmus verwendet der viel Speicherplatz benötigt, aber mit der Rechenzeit sparsam umgeht. "Für nicht genutzte Rechenzeit gibt es kein Geld zurück." :-)
Wolfgang schrieb: > Fehlerverhalten interessanter Punkt. Wie macht man das "messbar", also wie kann ich da eine quantitative Aussage treffen?
USS schrieb: > Hallo, > > wenn man als Anfänger seinen eigenen Code bewerten soll, welche > Anhaltspunkte würdet ihr wählen? Der Code ist dann gut, wenn er: 1.) Das korrekte Ergebnis liefert. 2.) Von einer anderen Person gelesen und ohne großen Aufwand verstanden werden kann. Das erzielt man durch vernünftige Namen für Funktionen und Veriablen, und hier und da mal einen sinnvollen Kommentar warum man Problem X jetzt auf die Art und Weise Y löst.
USS schrieb: > wie kann ich das in meinem konkreten Fall herausfinden? Also was ich so > höre, hängt es von der Hochsprache usw ab Jeder Compiler kann Dir den erzeugten Maschinencode ausgeben. Beim gcc zum Beispiel geht das mit der Option -S.
:
Bearbeitet durch User
Mark B. schrieb: > 1.) Das korrekte Ergebnis liefert. > 2.) Von einer anderen Person gelesen und ohne großen Aufwand verstanden > werden kann. Das erzielt man durch vernünftige Namen für Funktionen und > Veriablen, und hier und da mal einen sinnvollen Kommentar warum man > Problem X jetzt auf die Art und Weise Y löst. naja, obs jemand versteht ist subjektiv. Ich wollte mehr in die wissenschaftliche Richtung
USS schrieb: > Wolfgang schrieb: >> Fehlerverhalten > > interessanter Punkt. Wie macht man das "messbar", also wie kann ich da > eine quantitative Aussage treffen? Fehleingaben provozieren und das Ergebnis messen. Alle Eingaben sollten im Code auf Plausibilität geprüft werden. Wenn irgendein Wert nicht plausibel ist, braucht man eine vernünftige Fehlerreaktion. Durch Null teilen ist zum Beispiel meistens nicht sehr vorteilhaft. ;-)
USS schrieb: > naja, obs jemand versteht ist subjektiv. Ich wollte mehr in die > wissenschaftliche Richtung Es gibt kein strenges wissenschaftliches Kriterium für die Qualität von Code (oder besser: für manche Aspekte der Qualität). Wenn es das gäbe, könnte man einfach einen Analyzer bauen der einem sagt "hier die Stelle ist schlecht und die und die". Was es gibt, sind Tools zur statischen Codeanalyse. Die weisen auf Fehler hin wie nicht initialisierten Speicher und dergleichen. Aber sie können nicht die Verständlichkeit des Codes für Menschen prüfen. Die ist aber in großen Software-Projekten, an denen mehrere Menschen arbeiten, extrem wichtig.
:
Bearbeitet durch User
Einem Anfänger anzuraten den Maschinencode als Maß von Softwarequalität heran zu ziehen halte ich für falsch. Auf Sourcecode Ebene gibt es brauchbare Richtlnie nach denen der code erstellt werden sollte. Man muß ja nicht gleich MISRA-C anlegen, aber einiges davon ist durchaus sinnvoll. Lesestoff (und weiter führende links) gibt es z.B. hier: https://de.wikipedia.org/wiki/Programmierstil
USS schrieb: > Hallo, > > wenn man als Anfänger seinen eigenen Code bewerten soll, welche > Anhaltspunkte würdet ihr wählen? Code wird in WTF / Minute bewertet. Lasse einen andere über deinen Code schauen und zähle wie oft er "What the fuck" sagt.
:
Bearbeitet durch User
Wolfgang schrieb: > Das ist nur ein Aspekt. > Was ist mit Testbarkeit, Fehlerverhalten, Wartbarkeit (nicht als > Nebeneffekt), Dokumentation und (dank der BLWer) Time-to-Market? Auf Time-to-Market würde ich nur Optimieren, wenn ich weiß das die Firma verlasse bevor das nächste Update Kommt. Bei denn anderen Aspekten gehe ich mit. Wichtig ist auch immer, das der Autor des Codes sagt auf was er Optimiert hat. Was nutzt mir ein super schnelle Algorithmus, der viel Speicher braucht wenn ich nur wenig davon habe. Die Wartbarkeit ist auch so ein Faktor, denn man Schwer Objektiv messen kann, aber guten Code von Schlechten unterscheidet. Ich zum Beispiel finde die Simple Erkenntnis: "Code wird öfters gelesen als Geschrieben, also Optimiere auf das leichte Verständnis!" Im allgemeinen besser, als, auf das letzte µ-laufzeit von Hand optimierte Programme. Als High frequency Broker hätte ich vielleicht andere Prioritäten.
USS schrieb: > wenn man als Anfänger seinen eigenen Code bewerten soll, welche > Anhaltspunkte würdet ihr wählen? Wie groß bzw. umfangreich ist dein Code? Und da du im Elektronik/uC Unterforum geschrieben hast, gehe ich davon aus, dass dein Code für uC gedacht ist? Gruß,
Cyblord -. schrieb: > Code wird in WTF / Minute bewertet. Genau, beim Review :-) https://www.osnews.com/story/19266/wtfsm/
NichtWichtig schrieb: > Lesestoff (und weiter führende links) gibt es z.B. hier: > https://de.wikipedia.org/wiki/Programmierstil danke, guter Hinweis
Al3ko -. schrieb: > Und da du im Elektronik/uC Unterforum geschrieben hast, gehe ich davon > aus, dass dein Code für uC gedacht ist? das ist richtig
Es lässt sich kurz zusammenfassen, dass es mannigfaltige Kriterien zur Bewertung von Sourcecode gibt. Das hängt stark davon ab, was Deine Aufgabe in einem Projekt ist und ob es sich um PC-Software oder Firmware handelt. Meiner Erfahrung nach, wirst du Sourcecode einmal schreiben und vielfach lesen müssen. Schreib ihn so, dass er einfach lesbar ist. Davon ausgenommen sind lediglich performance-kritische Codeteile. Die dann mit entsprechend noch höherer Sorgfalt dokumentiert werden müssen. Für mich hat sich folgendes Kriterium als brauchbar erwiesen: google nach: "the only valid measurement of code quality wtfs/minute"
Angehängte Dateien:
-
programmierstil.PNG
62 KB
kann man soetwas als Programmierstil bezeichnen (gibt es eine Norm)? Ist das soetwas, an das ihr euch haltet?
USS schrieb: > kann man soetwas als Programmierstil bezeichnen (gibt es eine Norm)? Ist > das soetwas, an das ihr euch haltet? Normen sind je nach Branche unterschiedlich. Im Automotive Bereich wird oft MISRA verwendet, in der Luft- und Raumfahrt DO-178C, im Eisenbahnbereich EN 50128 und EN 50657, ...
:
Bearbeitet durch User
USS schrieb: > kann man soetwas als Programmierstil bezeichnen ein "Prinzipieller Aufbau" ist erstmal kein "Stil", sondern "Struktur". So wie ein Auto prinzipiell ein Lenkrad hat. Ein weiteres schräges Beispiel: Eine Wohnung kann durchaus "Struktur" haben (z.B. hat Wohnung_1 und Wohnung_2 ein Schlafzimmer und ein Badezimmer) Ob es noch zur "Struktur" gehört, das das Schlafzimemr "zur Strasse raus" ist, und das Badezimmer ein Durchgangszimmer ist, darüber kann man philisophieren. Der Stil (die eigentliche Ausführung) mag dann jedoch unterschiedlich sein: Das Durchgangs-Badezimmer hat feinsten Marmor und goldene Wasserhähne, und das andere Bad hat angedötschte Fliesen aus den 50ern ...
:
Bearbeitet durch User
USS schrieb: > kann man soetwas als Programmierstil bezeichnen (gibt es eine Norm)? Ist > das soetwas, an das ihr euch haltet? Lies bitte den verlinkten Wikipedia-Artikel. Mir scheint die Frage wichtig, worum es Dir geht. Ich vermute, Du nimmst an, dass es einen richtigen, allgemein anerkannten Stil gibt. Das trifft nicht zu. Es gibt vielmehr eine Reihe verschiedener, sich teilweise widersprechende, teilweise umstrittene Regeln, auf die man sich festlegen kann oder auch nicht. Der Wikipedia-Artikel beschreibt das Problem der Entscheidung und einige Regeln recht verständlich und ausführlich, denke ich. Das wesentliche scheint mir zu sein, sich, für sich persönlich oder für eine Gruppe, zunächst mal auf ein paar Regeln festzulegen und sie strikt zu befolgen. Man wird im Laufe der Zeit erfahren, ob der Sinn, der Effekt dieser Regeln für einen selbst wichtig ist oder nicht. Ebenso, ob es Regeln gibt, die einem fehlen oder sogar solche, an die noch niemand gedacht hat. Sinnvolle Fragen i.d.Zshg. scheinen mir also zu sein: Welche Regeln gibt es (Wikipedia und anderswo)? Welche will ich anwenden? Welchen Effekt sollen sie haben? Haben (nach einer Weile der Anwendung) diese Regeln den gewünschten Effekt? Welche externe Kritik gibt es? Halte ich diese Kritik für relevant?
USS schrieb: > kann man soetwas als Programmierstil bezeichnen (gibt es eine > Norm)? Ist > das soetwas, an das ihr euch haltet? Kommt Darauf an (TM) Wenn es Teil des Pflichtenheft/Projektstandard ist, halte ich mich dran. Meiner Persönlichen Meinung widerspricht der Aufbau diese Struktur. Zum Beispiel Wenn die Funktionen so wie so in der gleichen Datei Implementiert werden, wozu dann die Protoypen über der Main? Die Main am Ende hätte den Vorteil, dass ich mit einer guten IDE sofort dahin springen kann und das Programm so lesen wie es der Computer tut und so weiter.
Wegstaben V. schrieb: > Das ist erstmal kein "Stil", sondern "Struktur". macht Sinn. Gibt es Normen für Strukturen
> Üblicherweise gilt, daß Programme die weniger Aufwand enthalten, auch > einfacher zu erweitern und warten sind. Dass die Effizienz eines Programms in die Qualitätsbewertung eingeht, steht außer Frage. Allerdings habe ich eher die Erfahrung gemacht, dass effiziente Lösungen meist komplexer und schwerer zu warten sind als triviale, einfache und offensichtlich korrekte, dafür aber meist weniger effiziente Lösungen. Zu entscheiden, welche davon die "bessere" Lösung ist, erfordert Erfahrung und einen guten Überblick über das Gesamtproblem. >> Anzahl der Maschienbefehle > > wie kann ich das in meinem konkreten Fall herausfinden? Also was ich so > höre, hängt es von der Hochsprache usw ab Beim Betrachten der Laufzeit unter Groß-O-Notation ist die konkrete Implementierung eher nebensächlich. Man betrachtet die Abhängigkeit der Laufzeit von der Menge an Eingabedaten: doppelte soviele Eingabedaten, doppelte Laufzeit -> O(N); doppelte Eingabedaten, 4-fache Laufzeit -> O(N²); etc. Ob die Implementation in Sprache A nun 30% schneller ist als in Sprache B, ist irrelevant, da konstante Faktoren rausfliegen. Die Sprache wird erst relevant, wenn sie bestimmte (effiziente) Lösungen nicht ermöglicht.
USS schrieb: > Wegstaben V. schrieb: >> Das ist erstmal kein "Stil", sondern "Struktur". > > macht Sinn. Gibt es Normen für Strukturen Nennt sich UML. https://de.wikipedia.org/wiki/Unified_Modeling_Language
Ich vergaß zu erwähnen, dass es auch ästhetiche Gesichtspunkte gibt. In manchen Fällen widersprechen sie auch einer Stilregel. Mir z.B. ist es lieber, Bedingungen wie
1 | if (i == 7) ... |
nicht so
1 | if (7 == i) ... |
zu schreiben, obwohl es mir korrekt erscheint, dass die zweite Schreibweise einen Fehler wie
1 | if (i = 7) ... |
vermeidet. Im übrigen ist es durchaus eine Ansichtssache, was unter "Stil" fällt. Der Wikipedia-Artikel nennt einige Regeln und (sogar) Paradigmen bzw. Entwicklungsmuster, die er "im weiteren Sinn" als "Stil" bezeichnet; also nicht im eigentlichen. Muss man sich überlegen, ob man so eine Abgrenzung für wichtig hält und wofür.
> nicht so: if (7 == i) ...
Dass dir das nicht gefällt, mag aber auch an deiner Muttersprache
liegen. Ein Japaner verteidigte mal diese Schreibweise damit, dass sie
eher der japanischen Sprache entspricht (Wortreihenfolge im Satz) -
klingt einleuchtend, weiß aber nicht, ob das tatsächlich so ist ;-)
Solange der TO nicht schreibt, wofür oder auf was er bewerten will, ist das alles hier.kaffesatzleserei. Sollst Du für irgendwas oder irgendwen bewerten? Wird jemand anders bewerten? Dann nenne Ross und Reiter. Willst du besser werden? Dann schreibe und lese Code, und ein paar gute Bücher. Zu beidem kannst Du auch konkret hier fragen.
Es kommt drauf an. Bei Python wäre man schon froh, jeder würde sich an den PEP8-Guide halten.
Mark B. schrieb: > Fehleingaben provozieren und das Ergebnis messen. Das ist doch nur UI. Viel kritischer ist, das Laufzeitprobleme vernünftig behandelt werden. Sonst gibt es soetwas wie eine Ariane 5.2 mit der bewährten Ariane 4 Software.
USS schrieb: > wenn man als Anfänger seinen eigenen Code bewerten soll, welche > Anhaltspunkte würdet ihr wählen? das geht nicht. Anfänger können ihren eigenen Code nicht bewerten.
ihr gebt mir viel Input, was gut ist, aber einiges geht durcheinander. Das Bild von dem Aufbau eines C-Programmes -> habe ich in öffentlich zugänglichen uochschulmaterila gefunden. Es stand keine Norm dabei oder ähnliches. Aber ich bezweifel, dass der prof sich das aus der Nase gezogen hat. Deswegen die Frage, ob es zu dem konkreten Beispiel eine Norm gibt Ansonsten erstmal vielen dank, lese mich ein und sonst melde ich mich nochmal
USS schrieb: >> Anzahl der Maschienbefehle > wie kann ich das in meinem konkreten Fall herausfinden? Das bekommst du indirekt über Performance-Tests heraus, bei denen man nicht nur die Ausführungszeit sondern auch die CPU und Speicherlast berücksichtigt.
Mark B. schrieb: > "Für nicht genutzte Rechenzeit gibt es kein Geld zurück." :-) Das ist nur halb richtig. Denn schlafende Computer nehmen weniger Strom auf (nicht alle, aber die meisten). Und den vergangenen 20 Jahren haben Intel und AMD ihre x86 Prozessoren in dieser Hinsicht extrem verbessert.
Wolfgang schrieb: > Mark B. schrieb: >> Fehleingaben provozieren und das Ergebnis messen. > > Das ist doch nur UI. Nicht unbedingt: Eine Fehleingabe könnte auch von einem Sensor kommen, der einen nicht plausiblen Messwert ausgibt.
Cyblord -. schrieb: > Code wird in WTF / Minute bewertet. Das ist witzig, aber auch richtig. Bringt es prägnant auf den Punkt.
USS schrieb: > ihr gebt mir viel Input, was gut ist, aber einiges geht durcheinander. > Das Bild von dem Aufbau eines C-Programmes -> habe ich in öffentlich > zugänglichen uochschulmaterila gefunden. Es stand keine Norm dabei oder > ähnliches. Aber ich bezweifel, dass der prof sich das aus der Nase > gezogen hat. Deswegen die Frage, ob es zu dem konkreten Beispiel eine > Norm gibt > Ansonsten erstmal vielen dank, lese mich ein und sonst melde ich mich > nochmal Aber lieber USS! Dann musst Du Deine Frage sorgfältiger formulieren. Du hast ursprünglich gefragt: "wenn man als Anfänger seinen eigenen Code bewerten soll, welche Anhaltspunkte würdet ihr wählen?" Das ist eine ganz andere Frage. Nämlich die woher Dein Prof. irgendein Bild hat und ob das aus einer Norm stammt. Wenn hier irgendwas durcheinander geht, dann Deine Fragen. Bitte habe Verständnis dafür, dass die Verständigen hier genau die Frage beantworten, die Du stellst. Nicht die, die Du nicht stellst. Wir lesen keine Gedanken und unsere Glaskugeln sind alle beim polieren. :-)
Stefan ⛄ F. schrieb: > Cyblord -. schrieb: >> Code wird in WTF / Minute bewertet. > > Das ist witzig, aber auch richtig. Bringt es prägnant auf den Punkt. Das höre ich oft.
Stefan ⛄ F. schrieb: > Das bekommst du indirekt über Performance-Tests heraus, bei denen man > nicht nur die Ausführungszeit sondern auch die CPU und Speicherlast > berücksichtigt. weiß ich nicht, wie so ein Test aussieht
Theor schrieb: > Bitte habe Verständnis dafür, dass die Verständigen hier genau die Frage > beantworten, die Du stellst. Nicht die, die Du nicht stellst. > Wir lesen keine Gedanken und unsere Glaskugeln sind alle beim polieren. > :-) passt doch alles, die Frage hat sich herauskristallisiert
https://www.informatik.uni-leipzig.de/~meiler/Propaed.dir/PropaedWS12.dir/Vorlesung.dir/V01.htm#_Toc272238785 also das was ich gepostet habe, entspricht in etwa dem ansi-standard?
Das alleinige Kriterium ist, ob der Code die Anforderungen erfüllt. Code ist ja kein Kunstwerk, für das der Künstler beliebig viel Zeit investieren soll. Alles was der Code erfüllen soll ist im Vorfeld festgelegt. z.B. - maximaler Speicherbedarf - Ausführungsgeschwindigkeit - Reaktionsgeschwindigkeit - Skalierung - Fertigstellungstermin - Kosten/Zeitaufwand und nicht zuletzt auch firmeninterne Regelungen wie - Coding-Style - Variablenbenennungen - Dokumentation - Versionierung - Testkriterien Dann kannst z.B. ein Netzdiagramm machen, wie gut die einzelnen Anforderungen erfüllt sind. Alles was nicht im Vorfeld festgelegt wurde, kann nicht in Qualitätsbetrachtungen eingehen.
Meiner Meinung nach können Anfänger Code schon auch bewerten, aber halt nach simplen Kriterien. Zwei Dinge die mir da ad-hoc einfallen sind: -) Zu lange Funktionen -) Zu große Einrückungstiefe Das sind erfahrungsgemäß auch so Dinge die quasi jeder am Anfang falsch macht.
Salopp gesagt heißt zu große Einrückungstiefe dass der Code zu komplex ist was Verzweigungen und Co angeht.
Vincent H. schrieb: > Salopp gesagt heißt zu große Einrückungstiefe dass der Code zu komplex > ist was Verzweigungen und Co angeht. ah verstehe. tatsächlich habe ich, was das angeht, gut gepunktet
Michael B. schrieb: > also die Anzahl der Maschienbefehle die (nicht der code lang ist sondern > die) ausgeführt werden um das Problem (inklusive Fehlerbearbeitung) zu > lösen. Mit heutigen Prozessoren kann die Performance auch mal mit der Anzahl der ausgeführten Instruktionen steigen, ist also eher eine sinnlose Metrik. Gemessene Taktzyklen sind aussagekräftiger.
USS schrieb: > Aber ich bezweifel, dass der prof sich das aus der Nase gezogen hat Wenn es darum geht, Code für einen Prof zu schreiben: das hat nichts mit echten Code zu tun. Das wäre, als bewerte man ein Gedicht nach der Handschrift. Die ganzen akademischen Regeln gelten für Code von genau dem Umfang (1000 Zeilen ). Und wenn der Prof an ungarischer Notation hängt, dann macht es den Code nicht besser, aber deine Zensur.
USS schrieb: > weiß ich nicht, wie so ein Test aussieht Kann man auch nicht pauschal sagen- Performance Tests sind immer sehr Anwendungsspezifisch und werden in der Regel selbst wiederum schrittweise entwickelt. An besten von einem separaten Team - nicht von den Programmierern.
A. S. schrieb: > Und wenn der Prof an ungarischer Notation hängt, dann > macht es den Code nicht besser, aber deine Zensur. Genau, womit wie wieder darauf zurück kommen, dass der Code die Anforderungen des Kunden erfüllen muss. In diesem Fall ist der Professor der Kunde und auch derjenige, der Struktur und Stil vorgibt. Als Entwickler orientiert man sich besser daran, was die Leute um einen herum haben wollen, als an irgendwelchen Standards. Über Standards sollte man genau so wie über eigene Ideen mit Team und ggf. Kunde diskutieren, bevor man sie umsetzt.
Stefan ⛄ F. schrieb: > das geht nicht. Anfänger können ihren eigenen Code nicht bewerten. Grundsätzlich kann jemand, der ein Stück Code geschrieben hat, dessen Qualität nicht bewerten. Egal ob Anfänger oder nicht. Wer (funktionierenden) Code geschrieben hat, hat das Problem verstanden und offensichtlich auch den Algorithmus (sonst würde der Code wahrscheinlich nicht funktionieren). Für den wird es immer einfacher sein, das Programm zu verstehen als für jemanden, der sich (noch) nicht eingehend mit dem Problem beschäftigt hat. Wenn beispielsweise jemand, der sich länger mit Grafik-Algorithmen beschäftigt hat, wird er einen Bresenham- oder DDA-Algorithmus auch ohne ausgiebige Kommentierung mehr oder weniger sofort als solchen erkennen. Wer Finanzsoftware programmiert, wird selbst mit Kommentaren wahrscheinlich noch Literatur benötigen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.