Programmierrichtlinen (Uni-Paderborn)

[Gast]

life schrieb:

Optimizer schrieb:

Du hast nicht mal kapiert, was das Problem bei deiner Zerlegung war. Die Namen sind es nicht. Gregor hat es sauber gemacht.
1. Fehler: Eine Funktion heißt printIrgendwas, rechnet aber was aus und printed das dann. Das könnte man zerlegen. Später machst du noch irgendwas anderes mit dem Preis und müsstest ihn neu ausrechnen. Vielleicht wird das mal geändert, dass es nicht immer *2 ist, dann musst du alle Stellen, wo du das ausrechnest suchen und die Rechnung ändern.
2. Fehler: Eine Funktion heißt printAlterPreis und druckt den neuen Preis mit aus. Du hast einfach nur den Code so aufgeteilt, dass es keine Compilerfehler gibt, sinnvolles hast du nicht gemacht.
3. Fehler: Eine Funktion heißt printDatumMauerfall und druckt den alten Preis mit aus. Sie macht was anderes als sie heißt und sie macht ein Ding zu viel. Nein, 2, weil das druckt auch noch den neuen Preis aus.

ok schaun wir mal aha 1. Fehler: schlechter name, 2. Fehler: schlechter name, 3. Fehler: schlechter name.

Willst du es nicht verstehen? Die Funktionen von dir machen keine sinnvolle Aufgabenteilung. Du musst doch, mit einem einfach Blick in den Code feststellen können, dass Gregor völlig anders aufgeteilt hat als du.

Ui, jetzt hast du mir aber sauber zum Denken gegeben. Warum werden mir hier ständig non-Probleme hingeworfen? Wo ist denn das Problem bei Exceptions, Rückgabewerten? Warum darf ich die Sichtbarkeit von Variablen nicht ändern? Wie kommst du dazu, einfach mal in den Raum zu stellen, dass ich die Sichtbarkeit von Variablen nicht nach meinen Gutdünken verändern darf, weil es dann unmöglich ist, dass das Programm korrekt arbeitet? Ein bisschen Begründung wäre angebracht.

Rückgabewerte: man kann nur eins zurückgeben, jedefalls auf einfachem wege. Hat man aber viele Variablen die lokal in main sichtbar sein sollen, aber nicht global, bekomsmte probleme.

Du musst mir nicht das Programmieren erklären. Wie gesagt, bin ich schon 9mm weiter. Das Problem mit mehreren Rückgabewerten kriegst du natürlich oft, nämlich dann, wenn du solche Kaskaden wie oben machst. Dass berechneDatum() außerdem noch den alten und den neuen Preis berechnet und zurückgibt. Außerdem ist das jetzt ein technisches Problem, das erstens sehr spezifisch ist und nicht für ein Beispiel taugt und zweitens du nicht in jeder Sprache hast. Hier tut es gut, etwas abstrakter zu denken und nicht das Aufteilen von Funktionen an sowas scheitern zu lassen. Es geht hier darum, ein Konzept per indirekter Verbindung zwischen unseren beiden Gehirnen zu übermitteln. Ich dachte, an einem Beispiel sieht man das schön und versteht es leichter, aber vielleicht muss ich dich auch erst zum kollektiven Bewusstsein hinzufügen.

Sichtbarkeit: weil das Programm das verändert wird. Gut vielleicht ist es sinnvoll hier es zu verändern, aber nicht überall kannste die sichtbarkeit so sauber trennen. Bei meiner verschärfungen oben, bekommste damit gleich probleme (beim code von gregor)

Ähhhhhhhm lassen wir das. Also ich schaffe es irgendwie, dass die Sichtbarkeit meiner Variablen passt und meine Programme funktionieren. Was du mir sagen willst, verstehe ich nicht.

Mach einfach mal halblang. Ich muss von dir nichts lernen, du stehst noch ganz am Anfang, einen Millimeter neben der 0 auf einen Meter. Ich stehe schon mindestens einen cm neben der 0.

ach die liebe Arroganz. Ich sag dir was: Du kannst jede Menge von mir lernen. Das heißt aber nicht, dass ich nichts von dir lernen kann :).
Btw. worauf begründest du deine Erhabenkeit eigentlich

Auf meine 9mm Vorsprung natürlich. Und weil ich jetzt natürlich, so wie du mir geraten hast, endlich mein Gehirn eingeschaltet habe.

[life]

Gregor schrieb:

life: Dein Code gefällt mir aus einem ganz anderen Grund schon nicht. Du hast eine ganze Menge if-else-Konstrukte, die zudem teilweise eine sehr ähnliche Struktur haben. Das ist eine Form von Redundanz, die man beseitigen kann. Teilweise geht das tatsächlich schon dadurch, dass man bestimmte Codestücke in Methoden zusammenfasst, teilweise gibt es andere Möglichkeiten da ran zu gehen. In Java nutze ich bei solchen Dingen oft Polymorphie. Das kannst du auch in meinem Code sehen. Ich habe da ein Objekt pointProcessor als Member in der Klasse. Das ist nur dafür da, unterschiedliche Verhaltensweisen meines Codes zu erzeugen. Statt dieser Membervariable hätte ich auch so eine if-else-Orgie machen können, um alle möglichen Verhaltensweisen einzubauen. Das ist aber nicht gut, weil da oft noch etwas dazukommt. Der Code wird dann lokal immer länger und damit unwartbarer. Ok, du hast da keinen Javacode, sondern C++. Ich weiß nicht, wie man da mit soetwas umgeht, aber es wird da auch ein Möglichkeit geben, solche if-Orgien zu vermeiden. Manchmal kann man soetwas auch dadurch lösen, dass man sich irgendwelche Tabellen anlegt, in denen man bestimmte Werte oder so nachguckt.

nun die if orgien kommen daher, dass es eigentlich sehr viele verschiede funktionen sind, die in einer template funktion zusammengefasst wurden. Die ganzen ifs werden zu 95% vom compiler rausgehauen weil ihre werte statisch und konstant sind. Trotzdem brauch ich sie, damit ich eben nicht 24 mal die gleiche Funktion mit wenigen unterschieden schreiben muss. Vielleicht kann man das codetechnisch noch weiter optimieren, aber einfach ist es nicht (man darf ja kein performance verlust dabei haben) (funktion wird bis zu 30000 pro frame aufgerufen)

[life]

Optimizer schrieb:

Willst du es nicht verstehen? Die Funktionen von dir machen keine sinnvolle Aufgabenteilung. Du musst doch, mit einem einfach Blick in den Code feststellen können, dass Gregor völlig anders aufgeteilt hat als du.

richtig hat er. Aber er hat eben die sichtbarkeit gravierend verändert (manche variablen sind globaler, andere lokaler) und ich sage ja nur, dass man das nicht überall so einfach machen darf oder kann. Natürlich gibts viele Beispiele, bei denen das funktioniert, aber eben genausoviele bei denen es einfach nicht so leicht funktionert.

Du musst mir nicht das Programmieren erklären. Wie gesagt, bin ich schon 9mm weiter.

muss ich offensichtlich doch

Auf meine 9mm Vorsprung natürlich. Und weil ich jetzt natürlich, so wie du mir geraten hast, endlich mein Gehirn eingeschaltet habe.

Worauf begründest du deine angeblichen 9mm Vorsprung? Glaub ich kein Wort von. Student an einer FH hört sich jedenfalls schonmal nicht nach Vorsprung an Und intelligentmäßig kannste mir offensichtlich auch nichts vormachen ^^

[Gregor]

life schrieb:

Worauf begründest du deine angeblichen 9mm Vorsprung? Glaub ich kein Wort von. Student an einer FH hört sich jedenfalls schonmal nicht nach Vorsprung an Und intelligentmäßig kannste mir offensichtlich auch nichts vormachen ^^

Optimizer hat in diesem Forum schon oft gezeigt, dass er weiß, wovon er spricht. Ich glaube, er hat hier bei vielen einen entsprechenden Ruf, da er auch schon vielen bei Problemen geholfen hat. Natürlich ist er schon deutlich weiter als ein Anfänger an der Uni. Und wenn er an einer FH studiert, dann ist das eher ein Zeichen dafür, dass ihm mehr in Richtung Softwaretechnik, Programmierung usw. in seiner Ausbildung begegnet als jemand, der an die Uni geht.

...ich gehe im Übrigen schon lange an die Uni. Ich weiß, was man hier lernt und was man nicht lernt. Und ich habe auch eine IMHO gute Vorstellung davon, inwiefern sich die Lehrinhalte von Uni und FH unterscheiden.

[DEvent]

Artchi schrieb:

Die meisten solcher Richtlinien sind bescheuert. Muß man ja einfach mal sagen. Genauso wie diese: "Alle Membervariablem müssen mit einem Unterstrich am Anfang versehen werden." Gibt es tatsächlich bei uns. Voll hohl!

// in irgend einer Klasse:
public void foo(int a) {
  _b = _b + a;
}

Ohne Unterstrichvorschrift:

// in irgend einer Klasse:
public void foo(int a) {
  b = b + a;
}

Kann mir jemand mal sagen, wo der Vorteil bei der ersten Variante sein soll? Wieso in Gottes Namen, soll ein Programmierer angeblich nicht an Variante 2 sehen können, das b eine Membervariable ist? Diesen Programmierer, der das nicht sieht, sollte nochmal über seinen Job nachdenken!

das ist eher bei zweideutigkeit:

class Blaaa
{
    int foo;
    void machirgendwas(int foo)
    {
        foo = foo;
    }
}

in Eclipse gibts eine Compiler-Warnung und der Code wird Gelb unterstrichen. Keine Ahnung was eine C++ IDE da macht.
Aber ein Präfix für Attribute ist total altmodisch , weil die modernen IDEs Klassenatribute anders Färben als lokale Variablen.

[life]

Gregor schrieb:

Optimizer hat in diesem Forum schon oft gezeigt, dass er weiß, wovon er spricht. Ich glaube, er hat hier bei vielen einen entsprechenden Ruf, da er auch schon vielen bei Problemen geholfen hat. Natürlich ist er schon deutlich weiter als ein Anfänger an der Uni. Und wenn er an einer FH studiert, dann ist das eher ein Zeichen dafür, dass ihm mehr in Richtung Softwaretechnik, Programmierung usw. in seiner Ausbildung begegnet als jemand, der an die Uni geht.

...ich gehe im Übrigen schon lange an die Uni. Ich weiß, was man hier lernt und was man nicht lernt. Und ich habe auch eine IMHO gute Vorstellung davon, inwiefern sich die Lehrinhalte von Uni und FH unterscheiden.

ich behaupte ja nicht, dass ich ich nichts von ihm lernen kann, sondern habe sogar explizit geschrieben, dass ich sicherlich vieles von ihm lernen kann auch oder grade im bezug aufs coden. Anderseits behauptet er, dass er nichts mehr von mir lernen könnten und mir damit in jedem erdenklichen Bereich überlegen sei. Das bezweifel ich nunmal sehr stark. Auch weil er den FH Weg eingeschlagen hat und Uni und FH inhalte sich doch deutlich unterscheiden.
Außerdem wäre ich ich grade in einem Bereich wie der Informatik vorsichtig zu schlussfolgern, dass man 10x mehr von einem Thema versteht, nur weil man schon 10x länger studiert, da dies doch ein Bereich ist, mit denen sich viele (und auch ich) privat viel beschäftigen und nicht nur ihr Wissen aus der Uni/FH beziehen.

Vielleicht hat er ja sogar er ja sogar Recht und ist mir in jedem erdenklichen Gebiet überlegen, wie er behauptet und hat 10x mehr Wissen übers Programmieren als ich, dennoch wäre es aber ein Unverschämtheit einen sowas auf die Nase zu binden und damit zu argumentieren, dass er ja 10x mehr wisse als ich und daher er Recht haben müsse, zumal er es auch einfach nicht wissen kann. Deshalb ist seine Aussage imho ziemlich lächerlich

[Gast]

Vielleicht ist es bei so etwas hilfreich, sich noch einmal anzusehen, wie es angefangen hat mit Aussagen wie "schwer von Begriff" "Hirn einschalten" und der völligen Veräppelung der unsinnigen Idee, Funktionen aufzuteilen, mit der Antwort auf Gregor's Code. Nicht zu sprechen von dem Versuch, mir Grundlagen über das Programmieren nahezulegen.
Das vergleichsweise schwache Echo mit der Kernaussage "an deiner Stelle wäre ich lieber ein biiiisscchen zurückhaltender" musst du schon vertragen. Wenn du deswegen jetzt ein Jahrhundert lang schmollst, berührt mich das aber auch wenig. Überhaupt ist es nur eine Tatsachenbeschreibung die ich normal nur nicht erwähnt hätte. Sei ein harter Mann und sieh den Fakten ins Auge. Dass sich diese Skala auf jeden Bereich des Lebens oder der Informatik bezieht, hast übrigens du dazu erfunden.

[life]

bitte? ich hab einfach gesagt, dass du mehr darüber nachdenken sollst, was du postet bevor du postest, da ich weiß, das du sonst eigentlich nicht solche flüchtigkeitsfehler machst.. kein grund mich deshalb anzuflamen.. jedenfalls musste damit rechnen das ich zurückflame, wenn du es doch tust.. aber von mir aus können wir jetzt zum thema zurückkommen und den flamewar erstmal bis auf weiteres verschieben. >_<

btw.: du musst schon damit rechnen veräppelt zu werden, wenn du immer so übertreibst (Funktion maximal 2 Zeilen). Vielleicht mal bischen auf dem Boden der Tatsachen bleiben, dann haste auch nicht solche Probleme..

[Redhead]

Artchi schrieb:

Die meisten solcher Richtlinien sind bescheuert. Muß man ja einfach mal sagen. Genauso wie diese: "Alle Membervariablem müssen mit einem Unterstrich am Anfang versehen werden." Gibt es tatsächlich bei uns. Voll hohl!

// in irgend einer Klasse:
public void foo(int a) {
  _b = _b + a;
}

Ohne Unterstrichvorschrift:

// in irgend einer Klasse:
public void foo(int a) {
  b = b + a;
}

Kann mir jemand mal sagen, wo der Vorteil bei der ersten Variante sein soll? Wieso in Gottes Namen, soll ein Programmierer angeblich nicht an Variante 2 sehen können, das b eine Membervariable ist? Diesen Programmierer, der das nicht sieht, sollte nochmal über seinen Job nachdenken!

Zu diesem absolut bescheuerten Beispiel erwartest du sicher keine Antwort.

Wenn du generell Programmierrichtlinien "dieser Art" für Unsinn hälst solltest
du mal darüber nachdenken, das es nicht darum geht dem Compiler einen Gefallen
zu tun. Dem ist es egal ob dein Variablen X, rewrerwe oder KarlEgon heissen.
Es geht darum MENSCHEN die den Quellcode lesen (müssen) die Arbeit zu erleichtern.

Und wenn du mal Projekte zu warten gehabt hättest die ein paar Jahre alt und nicht
10 sondern tausend Klassen enthalten, dann würdest du dich nicht nur
hin und wieder über ein paar (sinnvolle) Kommentare sondern auch über jede
sonstige Unterstützung freuen, und die "Kennzeichnung von Membervariablen"
gehört nach meiner Erfahrung dazu.

[Walli]

Um es kurz zu machen: Wenn man vernünftig programmiert, dann muss man nicht kennzeichnen. Man kann, wenn man es toll findet, aber einen Mehrwert gibt es IMHO dadurch nicht.

[Redhead]

Walli schrieb:

Um es kurz zu machen: Wenn man vernünftig programmiert, dann muss man nicht kennzeichnen. Man kann, wenn man es toll findet, aber einen Mehrwert gibt es IMHO dadurch nicht.

Verbesserte "Lesbarkeit" des Quellcodes stellt für mich einen Mehrwert dar.

[Walli]

Redhead schrieb:

Walli schrieb:

Um es kurz zu machen: Wenn man vernünftig programmiert, dann muss man nicht kennzeichnen. Man kann, wenn man es toll findet, aber einen Mehrwert gibt es IMHO dadurch nicht.

Verbesserte "Lesbarkeit" des Quellcodes stellt für mich einen Mehrwert dar.

Wo ist er denn deiner Meinung nach besser lesbar? Wenn man die Funktionen übersichtlich hält und Variablen sinnvoll benennt, dann erkennt man normalerweise sofort was offensichtlich ein Member ist und was nicht. Ich sehe da kein Problem.

[Redhead]

Walli schrieb:

Redhead schrieb:

Walli schrieb:

Um es kurz zu machen: Wenn man vernünftig programmiert, dann muss man nicht kennzeichnen. Man kann, wenn man es toll findet, aber einen Mehrwert gibt es IMHO dadurch nicht.

Verbesserte "Lesbarkeit" des Quellcodes stellt für mich einen Mehrwert dar.

Wo ist er denn deiner Meinung nach besser lesbar? Wenn man die Funktionen übersichtlich hält und Variablen sinnvoll benennt, dann erkennt man normalerweise sofort was offensichtlich ein Member ist und was nicht. Ich sehe da kein Problem.

Woran erkennt man das denn bei dir. Ich würde gern mal ein Beispiel dazu sehen.
Aber bitte keinen 5- oder 10-Zeiler, oder wie von Artchi so einen genialen Einzeiler.

[Gast]

life schrieb:

btw.: du musst schon damit rechnen veräppelt zu werden, wenn du immer so übertreibst (Funktion maximal 2 Zeilen). Vielleicht mal bischen auf dem Boden der Tatsachen bleiben, dann haste auch nicht solche Probleme..

Ich habe doch gar keine Probleme. Die Übertreibungen bringen genau auf den Punkt, was es zu sagen gibt. Irgendwo hab ich es ausgeschrieben, dass bei kürzeren Funktionen automatisch die Tendenz besteht, die Variablen am Anfang zu definieren. Das kann jetzt jeder glauben oder nicht. Aber natürlich kann man das auch veranschaulichen. Mach eine Funktion bestehend aus zwei Anweisungen, da muss die Variablendefinition die erste sein. Für etwas längere Funktion gilt das noch fast genauso.

Da du ja anscheinend die Übertreibung als solche erkannt hast, hättest du sie nicht veräppeln brauchen sondern stattdessen überlegen können, wo der wahre Kern liegt. Du hast doch nicht wirklich angenommen, dass ich strikt gegen jede Funktion bin, die länger ist als 2 Zeilen.

[Artchi]

DEvent schrieb:

das ist eher bei zweideutigkeit:

class Blaaa
{
    int foo;
    void machirgendwas(int foo)
    {
        foo = foo;
    }
}

in Eclipse gibts eine Compiler-Warnung und der Code wird Gelb unterstrichen. Keine Ahnung was eine C++ IDE da macht.
Aber ein Präfix für Attribute ist total altmodisch , weil die modernen IDEs Klassenatribute anders Färben als lokale Variablen.

Naja, was hat die Zweideutischkeit mit Kennzeichnung zu tun? Dein Beispiel ist eher ein Programmierfehler bzw. wohl ungewollt?

class Blaaa
{
    int foo;
    void machirgendwas(int foo)
    {
        this->foo = foo;  // Zweideutischkeit nicht mehr möglich
    }
}

Warum ich immernoch Membervariablen kennzeichnen muß, ist mir immer noch nicht klar.

[life]

Optimizer schrieb:

life schrieb:

btw.: du musst schon damit rechnen veräppelt zu werden, wenn du immer so übertreibst (Funktion maximal 2 Zeilen). Vielleicht mal bischen auf dem Boden der Tatsachen bleiben, dann haste auch nicht solche Probleme..

Ich habe doch gar keine Probleme. Die Übertreibungen bringen genau auf den Punkt, was es zu sagen gibt. Irgendwo hab ich es ausgeschrieben, dass bei kürzeren Funktionen automatisch die Tendenz besteht, die Variablen am Anfang zu definieren. Das kann jetzt jeder glauben oder nicht. Aber natürlich kann man das auch veranschaulichen. Mach eine Funktion bestehend aus zwei Anweisungen, da muss die Variablendefinition die erste sein. Für etwas längere Funktion gilt das noch fast genauso.

Da du ja anscheinend die Übertreibung als solche erkannt hast, hättest du sie nicht veräppeln brauchen sondern stattdessen überlegen können, wo der wahre Kern liegt. Du hast doch nicht wirklich angenommen, dass ich strikt gegen jede Funktion bin, die länger ist als 2 Zeilen.

hättest du aufmerksam gelesen, wäre dir aufgefallen, dass ich dir schon attestiert habe, dass es einen wahren kern hat, obgleich es übertrieben war.

[Artchi]

Redhead schrieb:

Wenn du generell Programmierrichtlinien "dieser Art" für Unsinn hälst solltest
du mal darüber nachdenken, das es nicht darum geht dem Compiler einen Gefallen
zu tun. Dem ist es egal ob dein Variablen X, rewrerwe oder KarlEgon heissen.
Es geht darum MENSCHEN die den Quellcode lesen (müssen) die Arbeit zu erleichtern.

Und wenn du mal Projekte zu warten gehabt hättest die ein paar Jahre alt und nicht
10 sondern tausend Klassen enthalten, dann würdest du dich nicht nur
hin und wieder über ein paar (sinnvolle) Kommentare sondern auch über jede
sonstige Unterstützung freuen, und die "Kennzeichnung von Membervariablen"
gehört nach meiner Erfahrung dazu.

Gaaanz ruhig brauner! Woher willst du wissen, ob und in welchen Projekten ich noch nicht gearbeitet habe? Hab zwei Jahre lang in einem Projekt mit 10 bis 15 Leuten gearbeitet, das Packet mit Java-Archiven ist knapp 100 MByte groß. Also nichts kleines. Ansonst belaufen sich die Projekte bei 3 bis 6 Leuten (schwankt immer, je nach Anforderungen zum aktuellen Zeitpunkt). Bin also kein Greenhorn nach 7 Jahren Berufserfahrung.

Hab auch 1 Jahr das Spiel Heroes of Might & Magic III von PC auf Dreamcast portiert. Hab den Code auch ohne Namenskonventionen verstanden.

Und nein, in keinem Projekt haben wir bisher solche Namenskonventionen gehabt und auch nicht gebraucht. Auch wenn immer Leute von "Aussen" uns solche Konventionen aufzwingen wollen.

[Redhead]

Hi Artchi,

Es gilt ja bekanntlich

Geht nicht, gibts nicht.

Ich bezweifle nicht das du deine und andere Quellcodes auch ohne solche
Restriktionen "geregelt" bekommst. Meine Erfahrung zeigt das die Einhaltung
von gewissen Regeln mir das Lesen fremder Quellcodes oft erleichtert hat.
Meine Kollegen, auch in früheren Firmen, sind/waren meist sehr begeistert wenn
spezielle Kollegen ihren "privaten" Coding Styles gepflegt haben, unabhängig
vom Ergebnis ihrer Programmierung.
Und daher gehöre ich, wenn Projektleiter bin, zu denen die auf Einhaltung der
von dir ungeliebten Richtlinien bestehen.

[DEvent]

Naja, was hat die Zweideutischkeit mit Kennzeichnung zu tun? Dein Beispiel ist eher ein Programmierfehler bzw. wohl ungewollt?

naja stell dir vor, du arbeitest seit 12 Stunden, bis Nachst um 4 Uhr, uns machst sowas ( mein Beispiel ). Jetzt stellen wir uns vor, dieser armer Programmierer hat die billigste IDE die es gibt. Dem Compiler ist es scheiss egal ob der Programmierer so ein scheiss macht wie foo = foo.
Was kommt? der armer und überarbeiter Programmierer sucht noch die ganze Nacht bis zum Morgengrauen nach einem Fehler.
Mit Zweideutigkeit meinte ich, das es nicht ersichtlich ist ob foo eine Membervariable ist oder nicht.
Und jetzt sag blos, du weist Membervariablen immer mit this->xxxx zu.
PS: das mit den Unterschrichten ist brutal, schonmal den STL-Code gelesen?

Wo ist er denn deiner Meinung nach besser lesbar? Wenn man die Funktionen übersichtlich hält und Variablen sinnvoll benennt, dann erkennt man normalerweise sofort was offensichtlich ein Member ist und was nicht. Ich sehe da kein Problem.

[otze]

Ponto schrieb:

otze schrieb:

hats in C++ auch nicht. Die Compiler sind da schon intelligent genug

Das glaube ich nicht:

class Obj {
public:
   Obj() { sock.open("127.0.0.1"); }
   ~Obj() { sock.close(); }
   void write(char const * str) { sock.write(str); }
private:
   SocketObj sock;
};

void func(int value) {
  Obj ob;

  if (value > 10) return;
  
  ob.write(value);
}

ich wette einfach mal mit dir, dass die compiler erkennen können, dass "ob" nichts mit "value" zu tun hat, und so die beiden zeilen getauscht werden können.

Helium schrieb:

Dann ist dein Compiler kaputt. Er sollte schon das machen, was du ihm sagst.

bei non pods stimm ich dir zu. bei pods trau ich den compilern aber alles zu