Unschöner Code von anderen, was macht ihr damit?
-
rapso schrieb:
also ich wuerde davon ausgehen, dass leute die produktiv in einem unternehmen arbeiten, echt nicht wegen der sprache nachdenken muessen.
Wegen der Sprache nicht unbedingt, aber vielleicht darüber wie ein anderer mit der Sprache umgeht. Ich seh mich noch als Anfänger, aber häufig stolper ich über Code der mit halb so vielen Zeilen sicherer und eleganter gelöst werden kann - was auf der anderen Seite impliziert dass dem Code-ersteller diese alternativen Lösungen nicht bekannt sind.
und notfalls macht der vorgesetzter ein review mit, der sollte ahnung haben von dem was abgeht, man solle aber auch erwarten dass sein code nicht dringend ein review benoetigt.
Der Vorgesetzte eines Entwicklers ist nicht unbedingt selber Entwickler, gerade bei flachen Hierarchien. Ich würde nicht darauf wetten, dass jemand dessen Hauptaufgabe die Organisation der Mitarbeiter ist, alle von denen verwendeten Programmiersprachen ähnlich gut beherrscht wie die Mitarbeiter selbst.
-
~fricky schrieb:
Simon2 schrieb:
Was ich aber ganz gerne mache, ist "Schnittstellenverengung" via const. Da gibt es genug Fälle, wo Leute das einfach vergessen haben und man das problemlos nachziehen kann.
das verengt doch nix. man kann die funktion weiterhin mit nicht-const argumenten aufrufen.
Eine Schnittstelle hat alt 2 Seiten ... und für den Implementierer wird sie schon enger....
...weswegen ich diese Form der "Verengung" relativ guten Gewissens mache, weil das eigentlich nur dann in Frage kommt, wenn ich die Implementation sowieso anfassen muss.Gruß,
Simon2.
-
Bitte ein Bit schrieb:
...Projektarbeit ... Prof. ... Doktoranden...
Also ich denke, dass gerade an der Uni (vermutlich durch mangelnde Erfahrung, hohe Fluktuation, kaum "maintenance"- und service-level-Anforderungen) besonders viel schlechtes Design zu finden ist. Ist zumindestens nach meiner Erfahrung so.
Dabei will ich mich nicht ausnehmen: Meine Diplomarbeit könnte auch den Titel tragen "Beweis durch Antithese: Warum Scott Meyers doch Recht hatte"....Gruß,
Simon2.
-
rapso schrieb:
...der vorgesetzter ... sollte ahnung haben von dem was abgeht...
In was für einer Welt lebt Ihr denn ? Also wenn hier einer Chef ist, dann meistens nicht, weil er als Programmierer unglaublich viel getaugt hat!
Das finde ich vom Konzept her auch gut: Wer gut programmieren kann, soll programmieren - wer Führungsqualitäten hat, soll führen.
... und sooo viele Leute, die in beiden Gebieten Spitze sind, gibt's nicht.
Und ehrlich gesagt: Unsere Firma leidet ziemlich darunter, dass immer noch zu viele Programmierer in Führungspositionen aufgestiegen sind - die leider ziemliche Managementblinsen sind und sich stattdessen mit ihren (längst veralteten) technischen Vorstellungen in fachliche Arbeit einmischen.Nenene - bloß keinen Programmierer zum Chef haben.
Gruß,
Simon2.
-
Simon2 schrieb:
nep schrieb:
...halt irgendwie in Kommunikation mit der Person treten...
Irgendwie geht Ihr anscheinend von "Code-Ownership" aus. Das mag in bestimmten Firmen/Projekten so sein, aber die Codebasis an der wir hier arbeiten, "gehört" niemandem (außer der Firma an sich). Wenn ich ein Codestück in die Finger bekomme, haben da oft über Jahre hinweg viele verschiedene Leute dran gearbeitet. Ich wüsste gar nicht, an wen ich mich da wenden sollte ...
Das ist prinzipiell richtig, aber dann hat ja trotzdem immer wieder einer den Code "übernommen", also hat sozusagen das "Code-Ownership" über diesen historisch gewachsenen Code. So war zumindest meine Erfahrung bis jetzt. Aber variiert wohl.
-
pumuckl schrieb:
rapso schrieb:
also ich wuerde davon ausgehen, dass leute die produktiv in einem unternehmen arbeiten, echt nicht wegen der sprache nachdenken muessen.
Wegen der Sprache nicht unbedingt, aber vielleicht darüber wie ein anderer mit der Sprache umgeht. Ich seh mich noch als Anfänger, aber häufig stolper ich über Code der mit halb so vielen Zeilen sicherer und eleganter gelöst werden kann - was auf der anderen Seite impliziert dass dem Code-ersteller diese alternativen Lösungen nicht bekannt sind.
minimalismus ist halt nicht immer das ziel, manchmal will man schnellen code haben, manchmal lesbaren (in dem implizite dinge nicht uebersehen werden).
und notfalls macht der vorgesetzter ein review mit, der sollte ahnung haben von dem was abgeht, man solle aber auch erwarten dass sein code nicht dringend ein review benoetigt.
Der Vorgesetzte eines Entwicklers ist nicht unbedingt selber Entwickler, gerade bei flachen Hierarchien. Ich würde nicht darauf wetten, dass jemand dessen Hauptaufgabe die Organisation der Mitarbeiter ist, alle von denen verwendeten Programmiersprachen ähnlich gut beherrscht wie die Mitarbeiter selbst.
ich spreche natuerlich von der technischen seite, der lead programmer sollte dazu faehig sein. ich erwarte natuerlich nicht dass der producer irgendwelchen code vom technical director pruefen muss.
-
Simon2 schrieb:
rapso schrieb:
...der vorgesetzter ... sollte ahnung haben von dem was abgeht...
In was für einer Welt lebt Ihr denn ? Also wenn hier einer Chef ist, dann meistens nicht, weil er als Programmierer unglaublich viel getaugt hat!
Das finde ich vom Konzept her auch gut: Wer gut programmieren kann, soll programmieren - wer Führungsqualitäten hat, soll führen.ich sprach selbstverstaendlich von der hierarchy innerhalb der programmierer.
... und sooo viele Leute, die in beiden Gebieten Spitze sind, gibt's nicht.
Und ehrlich gesagt: Unsere Firma leidet ziemlich darunter, dass immer noch zu viele Programmierer in Führungspositionen aufgestiegen sind - die leider ziemliche Managementblinsen sind und sich stattdessen mit ihren (längst veralteten) technischen Vorstellungen in fachliche Arbeit einmischen.da haben die vorherigen vorgesetzten wohl versagt beim verteilen der leitpositionen, aber ich glaube das hat nicht wirklich viel mit dem topic hier zu tun. ich stimme dir zu, aber naja... darueber aufregen bringt wohl nichts.
-
rapso schrieb:
ich sprach selbstverstaendlich von der hierarchy innerhalb der programmierer.
Dazu muss es so eine Hierarchie erstmal geben.
-
Simon2 schrieb:
~fricky schrieb:
Simon2 schrieb:
Was ich aber ganz gerne mache, ist "Schnittstellenverengung" via const. Da gibt es genug Fälle, wo Leute das einfach vergessen haben und man das problemlos nachziehen kann.
das verengt doch nix. man kann die funktion weiterhin mit nicht-const argumenten aufrufen.
Eine Schnittstelle hat alt 2 Seiten ... und für den Implementierer wird sie schon enger....
das stimmt natürlich. z.b. wenn von der schnittstelle, der du ein so freimütig 'const' verpasst hast, andere funktionen aufgerufen werden, die 'nicht-const' sind, musst du die auch anpassen usw. und schon hast du den berüchtigten 'const is a virus'-effekt. für den implementierer kann's in der tat ziemlich eng werden.
Shade Of Mine schrieb:
Natuerlich verengt es die schnittstelle - einfach mal einen schritt weiter denken.
na, wenigsten hast du mich nicht zum mitdenken aufgefordert. damit hättest du mich schwer beleidigt.
-
Bashar schrieb:
rapso schrieb:
ich sprach selbstverstaendlich von der hierarchy innerhalb der programmierer.
Dazu muss es so eine Hierarchie erstmal geben.
das klaert deinen postcount, capt obvious
-
Wie bitte? Wieso ist es auf einmal "obvious", dass es nicht überall eine Hierarchie aus Programmierern gibt, wo du doch gerade wie selbstverständlich davon ausgegangen bist, dass ein "Vorgesetzter" Code-Reviews machen kann.
-
~fricky schrieb:
...
das stimmt natürlich. z.b. wenn von der schnittstelle, der du ein so freimütig 'const' verpasst hast, andere funktionen aufgerufen werden, die 'nicht-const' sind, musst du die auch anpassen ...Rischtisch!
Aber das "consten mache ich auch nicht zum Spaß, sondern wenn die Funktion es mir nahelegt - und es mit vertretbarem Aufwand verbunden ist.
Das war immer eine ganz schöne Übung: So überprüfe ich, ob ich die Schnittstelle (bzgl. dieses Aspekts) richtig einschätze: Einfach mal den Parameter, von dem ich denke, dass er reiner Inputparameter ist, const-en und compile anwerfen.
Dann zeigt sich sehr schnell, um welchen der 3 Fälle es sich handelt:
a) mein Irrtum (Parameter ist tatsächlich notwendigerweise un-const)
b) ich habe Recht gehabt (und damit die Schnittstelle besser dokumentiert)
c) ich habe Recht gehabt ... aber ein const-Einführung wäre zu aufwendig.Nicht selten ist leider auch die Schnittselle total in der Wurst (wilder Mix von Parametern, die im Rahmen verschiedenster (eigentlich orthogonaler) Fachlichkeiten upgedatet werden) - tja, da mache ich mir nie die Arbeit eines Redesigns. Allerdings dokumentiere ich den Mißstand und hoffe auf eine spätere Beauftragung (die aber in 90% der Fälle ausbleibt).
Die "const-is-a-virus"-Anhänger weisen zwar auf einen wichtigen Punkt hin ("const-as-const-can" ist ein übertriebenes Vorgehen, das im Endeffekt mehr Aufwand nud weniger Lesbarkeit erzeugt), aber man sollte auch nicht die Aussagekraft von gut plazierten consts unterschätzen (ein separates keyword für "Schnittstellen-consts" wäre vll. nicht schlecht gewesen)...
Gruß,
Simon2.
-
Simon2 schrieb:
Aber das "consten mache ich auch nicht zum Spaß, sondern wenn die Funktion es mir nahelegt - und es mit vertretbarem Aufwand verbunden ist.
Das war immer eine ganz schöne Übung: So überprüfe ich, ob ich die Schnittstelle (bzgl. dieses Aspekts) richtig einschätze: Einfach mal den Parameter, von dem ich denke, dass er reiner Inputparameter ist, const-en und compile anwerfen...Kannst Du mir ein praktisches Beispiel - am besten in Code - nennen, in dem das von Nutzen wäre
-
pointercrash() schrieb:
Kannst Du mir ein praktisches Beispiel - am besten in Code - nennen, in dem das von Nutzen wäre
Dies ist ohne Ausnahme an allen stellen sinnvoll, wo man einerseits sichergehen will das keine Änderungen erfolgen, anderseits aber nicht unnötige Kopien erstellen will. Ich vermisse const in manch einer Sprache, da mir die Information fehlt ob die Schnittstelle nun manipulieren kann oder nicht.
cu André