Laden...

Brauche Hilfe für Überzeugungsarbeit für Dispose u.ä. ...

Erstellt von ViperNeo vor 13 Jahren Letzter Beitrag vor 13 Jahren 6.240 Views
V
ViperNeo Themenstarter:in
352 Beiträge seit 2008
vor 13 Jahren
Brauche Hilfe für Überzeugungsarbeit für Dispose u.ä. ...

Hallo Leute,

ich arbeite seit dieser Woche in einem Unternehmen, die .NET Software entwickeln.

Mein erster Weg soll in Richtung Code-Optimierung der bestehenden Anwendungen führen. Nun habe ich festgestellt, dass in keiner Anwendung Dispose eingesetzt wird... Das ist nicht der einzige Makel, denn es werden auch Dignewie DoEvents genutzt, DialogResults ignoriert und stattdessen mit Propertys gearbeitet und und und... Also es gibt eine Menge was man da optimieren könnte.

Nun hatte ich heute morgen ein GEspräch mit dem Chefprogrammierer und der stellt sich sturr^^

Ich habe ihm versucht zu erklären, dass Dispose ein wesentliches Mittel ist um die Resourcen wieder freizugeben und über den GC weg zu räumen. Er meinte doch tatsächlich, dass man das nicht braucht und es eher von Nachteil wäre Dispose aufzurufen... Nun bin ich etwas ratlos, da ich das GEfühl habe, dass er sich etwas auf die Füße getreten fühlt von einem Jungspund wie mir (er ist seit 10 Jahren in diesem Unternehmen und entwickelt hier in .NET). Jedoch bin ich der Meinung, dass viele seiner Ansätze einfach besser gehen... Er stellt sihc in die typische Programmiererabwehrhaltung: er weiß das alles, hat aber keine zeit dafür, aber dispose ist wirklich unnötig.

Wie würdet ihr an so eine Sache rangehen? Ich arbeite das erste mal wirklich fest in einem Entwicklungshaus und habe da wenig ERfahrung. Ich weiß das Entwickler schnell verletzt sind wenn man ihr können auch nur ein bisschen anzweifelt oder kritisiert. so sind zum GLück nicht alle, aber ja leider viele und dieser Kollege wohl auch.

Danke schonmal!

Grüße ViperNeo

Gelöschter Account
vor 13 Jahren

ein sehr heikles thema... du solltest es wirklich extremst behutsam angehen.

natürlich kannst du keinem senior entwickler sagen, das das was er 10 jahre lang gemacht hat, nur mist ist. und schon garnicht, wenn er ein chef-entwickler ist .

das mit dispose ist ja nur ein kleiner teilbereich und wenn du wirklich was ändern willst, dann brauchst du viel viel zeit... (meist sogar jahre).

jetzt für die erste zeit würde ich dir raten garnichts zu unternehmen und erstmal mitzuschwimmen.

es ist einfacher veränderungen von innen heraus zu machen anstatt gegen den strom zu schwimmen und von außen änderungen einzuprügeln (dafür fehlt dir als neuling die autorität).

V
ViperNeo Themenstarter:in
352 Beiträge seit 2008
vor 13 Jahren

das ist sehr schön geschrieben und ich glaube da hast du wohl recht. das mit dem dispose hat sich erledigt gehabt, daihc in einem anderen thread unter meinem einige argumente rauslesen konnte. vllt ist das dann eher was für off-topic.

grüße

61 Beiträge seit 2009
vor 13 Jahren

Einmal den Tipp von JAck30lena beachten 😉

und

für den Fall einmal hier gucken - unter dem Punkt "IDisposable-Schnittstelle"

In der Zeit vor fünf Minuten ist Jetzt die Zukunft. Jetzt ist die Gegenwart. Die Zeit, in der ich zu erzählen begonnen habe, ist die Vergangenheit von Jetzt und die Zukunft von der Gegenwart der Zeit, fünf Minuten bevor ich zu erzählen begann.

Gelöschter Account
vor 13 Jahren

aihc in einem anderen thread unter meinem einige argumente rauslesen konnte

etwa dem hier -> using Gültigkeitsbereich und Dispose() Unterschiede ? <- ?

vllt ist das dann eher was für off-topic

ne, das passt ja gut zum thema 😉

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo ViperNeo,

Er meinte doch tatsächlich, dass man das nicht braucht und es eher von Nachteil wäre Dispose aufzurufen...

damit hat er vollkommen Recht! Dispose braucht man im Prinzip nur für nicht-verwaltete Ressourcen; in anderen Fällen stört Dispose. Wenn ein Objekt solche nicht benutzt und auch keine Objekte verwendet, die IDisposable implementieren, sollte man selbst auch kein IDisposable implementieren, sondern die Arbeiten dem CG überlassen. Dispose ist eine (wacklige) Hilfskonstruktion, um in einer verwalteten Umgebung mit unverwalteten Ressourcen umgehen zu können.

herbivore

61 Beiträge seit 2009
vor 13 Jahren

Hier ist ja auch noch was.
Vor allem der Beitrag von norman_timo:
Dispose implementieren und verwenden (IDisposable)

Damit dürfte die Antwort "perfekt" sein. 😉

In der Zeit vor fünf Minuten ist Jetzt die Zukunft. Jetzt ist die Gegenwart. Die Zeit, in der ich zu erzählen begonnen habe, ist die Vergangenheit von Jetzt und die Zukunft von der Gegenwart der Zeit, fünf Minuten bevor ich zu erzählen begann.

S
489 Beiträge seit 2007
vor 13 Jahren

damit hat er vollkommen Recht! Dispose braucht man im Prinzip nur für nicht-verwaltete Ressourcen; in anderen Fällen stört Dispose. Wenn ein Objekt solche nicht benutzt und auch keine Objekte verwendet, die IDisposable implementieren, sollte man selbst auch kein IDisposable implementieren, sondern die Arbeiten dem CG überlassen. Dispose ist eine (wacklige) Hilfskonstruktion, um in einer verwalteten Umgebung mit unverwalteten Ressourcen umgehen zu können.

Technisch gesehen ist das richtig. Ich implementiere es dennoch gerne, denn ich mag das using Kontrukt und ich möchte, dass das Objekt auch dann zerstört wird, wenn irgendwo doch noch eine Referenz des Objektes gehalten wird - solche lassen sich damit leichter finden.

Gelöschter Account
vor 13 Jahren

puh... ok das ist wieder das andere extrem....
was amchst du in einer komplett verwalteten klasse im dispose?

N
60 Beiträge seit 2010
vor 13 Jahren

Wenn du so Argumentiert hast wäre ich auch gegen Dispose. An der Stelle missbrauchst du es. Da kann man schon sagen "ne wir haben nichts unmanged, das brauchen wir nicht".

Wenn du ein Objekt nicht mehr brauchst sorge dafür das du keine Refernezen mehr darauf hast und sei glücklich.

Grüße
Nils

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo SeboStone,

also ich halte das schon fast für einen Missbrauch des Mechanismus. Warum sollte es noch andere Referenzen geben? Und wenn es sie tatsächlich gibt, dann doch wahrscheinlich, weil sie benötigt werden. Wenn du deine Klassen (alle) mit Dispose ausstattest, erzeugst du für den Benutzer der Klassen einen unnötigen Overhead. Mal ganz abgesehen davon, dass das eine eigenwillige Vorgehensweise ist und andere Benutzer der Klassen vermutlich irritiert.

herbivore

PS: Also wenn in so kurzer Zeit soviele Leute unabhängig voneinander ins gleiche Horn stoßen, sollte dich das schon zum Umdenken bewegen.

Gelöschter Account
vor 13 Jahren

erstellst du eigendlich auch einen destruktor @SeboStone ?

888 Beiträge seit 2007
vor 13 Jahren

Hallo ViperNeo,

Du könntest auch ein kleines Demo-Program schreiben, in dem du z.B. in einer Schleife
Images, Pens, Brushes, oder ähnliches erzeugst ohne Dispose() aufzurufen. Dabei hast Du den Taskmanager offen und kannst zeigen wie die verwendeten GDI-Objekte rapide ansteigen --> irgendwann gibt's keine Handles mehr.

Als weiteres praktischen Argument (von Microsoft) könntest du im VisualStudio die statische codeanalyse aktivieren, die sagt Dir genau, wann und warum Dispose() zu implementieren ist.

Grüße

G
46 Beiträge seit 2010
vor 13 Jahren

Hallo herbivore,

damit hat er vollkommen Recht! Dispose braucht man im Prinzip nur für nicht-verwaltete Ressourcen;

... weshalb er wiederum Unrecht hat. Wenn ich eine Komponente nicht selbst entwickelt habe und diese Komponente IDisposable implementiert sollte ich - der Sicherheit halber - auch davon ausgehen, dass nichtverwaltete Ressourcen verwendet werden. Ergo sollte Dispose() aufgerufen werden, wenn es vorhanden ist.

Grüße
Gwar

S
489 Beiträge seit 2007
vor 13 Jahren

puh... ok das ist wieder das andere extrem....
was amchst du in einer komplett verwalteten klasse im dispose?

Ich cleare Listen (gegebenenfalls Dispose ich deren Elemente), lösche Event Handler, rufe Dispose Methoden anderer Klassen auf und rufe explizit den GC auf.

Der FxCop schreit nach einer Dispose Implementierung wenn man in einer Klasse eine Resource hat die Disposable ist.

Warum sollte es noch andere Referenzen geben? Und wenn es sie tatsächlich gibt, dann doch wahrscheinlich, weil sie benötigt werden.

Ja das frage ich mich in manchen Projekten bei manchen Kunden auch immer. 😁 Nein, leider nicht. Defacto wird nicht überall sauber entwickelt. 🙁

PS: Also wenn in so kurzer Zeit soviele Leute unabhängig voneinander ins gleiche Horn stoßen, sollte dich das schon zum Umdenken bewegen.

Nein, nicht alle meine Klassen bekommen ein Dispose, das wäre tatsächlich Blödsinn. Aber vielleicht werde ich mir in Zukunft etwas mehr Gedanken darüber machen ob es wirklich sinnvoll IDisposable zu implementieren. Ich neige oft dazu manche Dinge aus Gewohnheit zu machen. Sicherlich kennt Ihr das auch, man entwickelt mit der Zeit Vorgehensweisen, man kann vielleicht sogar von "persönlichen Pattern" sprechen. 😉

erstellst du eigendlich auch einen destruktor @SeboStone ?

Nein.

Gelöschter Account
vor 13 Jahren

Ich cleare Listen

nicht notwendig. der garbagecollector geht immer alle referenzen durch und wenn die aktuelle klasse keinen weg zum root hat, dann wird der gesamte ast freigeräumt.

rufe Dispose Methoden anderer Klassen auf

ja, das ist sinnvoll, wenn deine klasse diese als felder hält.

und rufe explizit den GC auf.

das wiederrum ist garnicht sinnvoll. der gc weiß besser wann er zu laufen hat und wann nciht. so bringst du nur sein generationssystem durcheinander, was dich unmengen an performance kostet.

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo Gwar,

Wenn ich eine Komponente nicht selbst entwickelt habe und diese Komponente IDisposable implementiert sollte ich - der Sicherheit halber - auch davon ausgehen, dass nichtverwaltete Ressourcen verwendet werden. Ergo sollte Dispose() aufgerufen werden, wenn es vorhanden ist.

deckt sich voll mit dem, was ich gesagt habe.

Nur kann man aus

Nun habe ich festgestellt, dass in keiner Anwendung Dispose eingesetzt wird

wie mir jetzt klar geworden ist, nicht genau erkennen, ob es darum geht, vorhandenes Dispose aufzurufen oder darum geht, in (allen) Klassen IDisposable zu implementieren. Ich habe letzteres verstanden. Denn der Satz "dass in keiner Anwendung Dispose eingesetzt wird" klingt danach, dass eine Anwendung nur gut ist, wenn in ihr auch wirklich irgendwo Dispose zu Einsatz kommt. Und das ist natürlich Quatsch. Wenn es nichts zu disposen gibt, sollte man kein Dispose einbauen. Wenn es was zu disposen gibt, gilt natürlich, was du und ich gesagt haben: dann sollte man es auch so (früh wie möglich) aufrufen.

herbivore

S
489 Beiträge seit 2007
vor 13 Jahren

Hier ist ja auch noch was.
Vor allem der Beitrag von norman_timo:

>

Damit dürfte die Antwort "perfekt" sein. 😉

Absolut! In dem Post finde ich alle meine Argumente in ausführlicher Form wieder und sie werden auch bestätigt. 😉

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo SeboStone,

damit widersprichst du dir jetzt allerdings selbst. Die Regel, die norman_timo aufgestellt hat und die den Kern der Aussage des Beitrags ausmacht, sagt:

Unmanaged Ressourcen werden verwendet: IDisposable umsetzen
Nur Managed Ressourcen: Kein IDisposable

Oben schreibst du aber noch was von

Ich cleare Listen

Eine Liste ist aber eine verwaltete Ressource:

Wobei die Regel von norman_timo noch erweitert werden muss, um präzise zu sein.

Unverwaltete Ressourcen oder Objekte, die Dispose anbieten, sind enthalten ==> IDisposable implementieren
Andernfalls: ==> Kein IDisposable implementieren

herbivore

S
489 Beiträge seit 2007
vor 13 Jahren

nicht notwendig. der garbagecollector geht immer alle referenzen durch und wenn die aktuelle klasse keinen weg zum root hat, dann wird der gesamte ast freigeräumt.

Es ist notwendig, wenn die Elemente darin ebenfalls Disposable sind.

das wiederrum ist garnicht sinnvoll. der gc weiß besser wann er zu laufen hat und wann nciht. so bringst du nur sein generationssystem durcheinander, was dich unmengen an performance kostet.

Das kann gut sein, aber ich arbeite mit FxCop und der verlangt dort ein expliziten Aufruf. Über den Sinn FxCop hier Rechnung zu tragen kann man wirklich streiten, aber oft wird FxCop verwendet um die Qualität von Code zu beurteilen und dann bin ich mit meinem Argument wieder im Geschäft. 😉

S
489 Beiträge seit 2007
vor 13 Jahren

Oben schreibst du aber noch was von

Ich cleare Listen

Ich habe geschrieben, dass ich in der Dispose Methode Listen cleare - warum auch nicht - aber ich habe nicht geschrieben, dass ich IDisposable implementiere um Listen zu clearen - das mache ich ganz sichern nicht. Wenn ich aber sowieso schon eine Dispose Methode habe, warum sollte ich dann nicht alles "aufräumen"?

N
60 Beiträge seit 2010
vor 13 Jahren

Weil das Aufwendig ist und der GC das mindestens genau so gut macht?

G
46 Beiträge seit 2010
vor 13 Jahren

Hallo herbivore,

wie mir jetzt klar geworden ist, nicht genau erkennen, ob es darum geht, vorhandenes Dispose aufzurufen oder darum geht, in (allen) Klassen IDisposable zu implementieren. Ich habe letzteres verstanden.

... womit das "Missverständnis" geklärt ist, denn ich habe ersteres verstanden 😃

Grüße
Gwar

Gelöschter Account
vor 13 Jahren

Das kann gut sein, aber ich arbeite mit FxCop und der verlangt dort ein expliziten Aufruf.

meisnt du vielleicht den aufruf zu .SuppressFinilize? oder meinst du wirklich .Collect ?

Wenn ich aber sowieso schon eine Dispose Methode habe, warum sollte ich dann nicht alles "aufräumen"?

weil das der garbagecollector deutlichst perfomanter macht wie du. das "clearen" einer liste ist vollkommend unnötig, da die objekte dadurch ja immernoch nciht weg sind, sondern nur nciht mehr referenziert werden. was du machst, ist im prinzip nur die referenzen auf null setzen, was jedoch irrelevant ist, da der gc diese ohnehin weggeräumt/überschrieben hätte.

aber ich habe nicht geschrieben, dass ich IDisposable implementiere um Listen zu clearen

ok das ist was anderes... da hast du recht, das du durch die liste gehst und dispose aufrufst... aber clear.... nicht notwendig aber bei einer standard list nur marginal schädlich... schlimmer ist es bei bindings...

U
282 Beiträge seit 2008
vor 13 Jahren

was amchst du in einer komplett verwalteten klasse im dispose?

Ist vielleicht nicht der Hauptzweck von Dispose: Aber wenn ein Objekt, welches auf Events von injizierten anderen Objekten hört, zertört werden soll, muss es ja eine Möglichkeit geben, die Events wieder auszutragen. Da kann man nun eine Methode "UnsubscribeEvents" machen, aber eigentlich ist doch Dispose auch ganz passend für diese Fälle.

5.657 Beiträge seit 2006
vor 13 Jahren

Die Diskussion verstehe ich gar nicht mehr. MSDN erklärt alles in einem Satz, und zwar eindeutig:

IDisposable-Schnittstelle
Definiert eine Methode zur Freigabe von reservierten, nicht verwalteten Ressourcen.

Es geht um reservierte, nicht verwaltete Resourcen, nicht um Listen Clearen und Events austragen!

Christian

// Edit
Quellenangabe: IDisposable-Schnittstelle 😃

Weeks of programming can save you hours of planning

S
489 Beiträge seit 2007
vor 13 Jahren

meisnt du vielleicht den aufruf zu .SuppressFinilize? oder meinst du wirklich .Collect ?

Ähm ja, ersteres. Ok, da habe ich was verwechselt.

Ist vielleicht nicht der Hauptzweck von Dispose: Aber wenn ein Objekt, welches auf Events von injizierten anderen Objekten hört, zertört werden soll, muss es ja eine Möglichkeit geben, die Events wieder auszutragen. Da kann man nun eine Methode "UnsubscribeEvents" machen, aber eigentlich ist doch Dispose auch ganz passend für diese Fälle.

Richtig, habe ich vergessen zu erwähnen - das mache ich immer in Dispose, ein anderer Weg ist mir noch nie unter gekommen.

IDisposable-Schnittstelle
Definiert eine Methode zur Freigabe von reservierten, nicht verwalteten Ressourcen.

Ich weiß ja nicht aus welcher MSDN Du das hast, aber wenn Du das aus der hier hast, dann zitiere bitte auch richtig:

...werden hauptsächlich nicht verwaltete Ressourcen freigegeben...

V
ViperNeo Themenstarter:in
352 Beiträge seit 2008
vor 13 Jahren

puh wahnsinns diskussion und großes interesse am theman... danke 😃

Also in meiner Ursprungsfrage geht es nicht darum überall Dispose zu implementieren. Der Sinn und Zweck war mir schon klar soweit eigentlich. Das Problem ist nur, dass es nicht mal bei Brushes, Pens etc. genutzt wird. Ihc war immer der Meinung, dass wenn eine .NET Klasse ein Dispose anbietet, ich diese auch mal aufrufen sollte wenn ich das Objekt nicht mehr brauche. Und genau dieser Sachverhalt wurde in allen Projekten einfach ignoriert. Die Jungs haben hier Software entwickelt, die durch Verbindungen mit Datenbanken und ein paar Bildgeschichten schnell in die 500-800MB Speicherauslastung hochschießen. Da kann und muss irgendwas nicht stimmen. Da war für mich ein erster Ansatz mal über das Disposen von entsprechenden Objekten nachzudenken, doch hier stellt man sich wie eingangs beschrieben sturr. WIe ich bereits angesprochen hatte ist das auch nur ein Teilbereich meiner langen Optimierungsliste für das Unternehmen, jedoch meiner Meinung war das ein wichtiger Aspekt um erstmal Performance und Speicherauslastung zu drücken.

F
10.010 Beiträge seit 2004
vor 13 Jahren

Und wer mal mit CAB/SCSF gearbeitet hat wird feststellen, das man immer dann IDisposable implementieren sollte, wenn Objekte in Containern verwaltet werden.

Bei CAB/SCSF ist es leider so, das der IOC Container harte Referenzen auf Objekte hält, und selbst wenn man seine Objekte überall freigibt, bleiben sie dadurch bestehen.

Es ist sogar so, das man dann keine 2 Views vom selben Typ öffnen kann, weil der andere in CAB noch eingetragen ist, das Fenster aber ist bereits disposed.

Es gibt also immer mal wieder Ausnahmen von dem "nur Unmanaged Resources".

@ViperNeo:
Dein Senior Dev kommt nicht zufällig von VB6?

5.657 Beiträge seit 2006
vor 13 Jahren

Das Problem ist nur, dass es nicht mal bei Brushes, Pens etc. genutzt wird.

Dann kannst du ja ziemlich gut nachweisen, daß bei häufigen Aufrufen und längerer Nutzung irgendwann der Speicher für nicht-verwaltete Objekte ausgeht. Das sollte doch ein gutes Argument sein. Ob es dann gehört wird oder sogar Konsequenzen daraus gezogen werden, ist dann wieder eine andere Sache...

Weeks of programming can save you hours of planning

V
ViperNeo Themenstarter:in
352 Beiträge seit 2008
vor 13 Jahren

@FZelle: Doch das tut er. Haste da tips oder erklärungen^^?

X
40 Beiträge seit 2005
vor 13 Jahren

Vielleicht hilft dir auch der folgende Artikel bzw. der folgende Absatz daraus:

Practical Tips For Boosting The Performance Of Windows Forms Apps: Resource Management

S
489 Beiträge seit 2007
vor 13 Jahren

@FZelle: Doch das tut er. Haste da tips oder erklärungen^^?

Wenn Du jemals glücklich werden willst, wechsle die Firma, bei mir hats geholfen.

V
ViperNeo Themenstarter:in
352 Beiträge seit 2008
vor 13 Jahren

Nunja ich habe Hoffnung das bessere Zeiten kommen. Die Firma ist überschaubar und ihc habe Montag erst hier angefangen. Eingestellt wurde ich ja um neuerungen und innovationen in die bestehenden Produkte und kommenden Produkte einfließen zu lassen, weil hier sonst nur alte Hasen sitzen 😉

Grüße

S
489 Beiträge seit 2007
vor 13 Jahren

Dein Chef will vielleicht, dass Du das machst, aber Du brauchst die Bereitschaft Deiner Kollegen. Aus deren Sicht ist Ihr Chef unzufrieden mit Ihnen und deswegen kommt da so ein Weltverbesserer der angeblich alles besser weiß und Ihnen nun zeigen soll wie man in .NET Software entwickelt. Implizit haben sie die letzten Jahre und Jahrzehnte Ihres Lebens also nur sch.... produziert - Du bist ganz sicher herzlich willkommen und sehr beliebt.

Wenn Du auch noch (deutlich) jünger bist als Deine Kollegen und sie wirklich so stur sind wie Du sagst, dann brauchst Du Machtwörter (Mehrzahl!!) Deines Chefs. Da kannst Du Dich dann schon mal drauf einstellen, dass Du Dich von "unbeliebte Person" nach "unbeliebteste Person" steigern wirst.

Erteilt Dir Dein Chef Weisungsbefugnis (muahaha) damit sich überhaupt irgendwas bewegt, dann ist Dein bester Freund die Putzfrau - nichts gegen diesen Beruf ohne diese Leute bleibts dreckig.

Fazit:

Egal wie Du es drehst, Du wirst Dich hoffnungslos zum Affen machen und dafür straft man Dich mit Missgunst und Ablehnung. Oder Du bist "clever" und schwimmst einfach mit im Sumpf. So oder so, glücklich wird man so sicher nicht.

Gelöschter Account
vor 13 Jahren

Oder Du bist "clever" und schwimmst einfach mit im Sumpf....

... und lenkst intern immer mehr in die richtige richtung.
das hat zumindest bei mir ganz passabel funktioniert. dauert lang und man kassiert schon den einen oder anderen rückschlag aber spätestens dann ,wenn die hälfte der kollegen ab und an zu dir kommen, damit du ihnen verrätst wie dies und jenes in .net geht, hast du gewonnen.

edit: aber dieses jahr solltest du ncihts unternehmen. und stell dich darauf ein, das das ein langer prozess wird.

V
ViperNeo Themenstarter:in
352 Beiträge seit 2008
vor 13 Jahren

ich glaube das werde ich mal tun besser... wobei ich nun im laufe des tages etwas wärmer geworden bin mit dem chef entwickler... ihm gefällt mein stil und er ist bei weniger zeitdruck auch bereit über optimierungen zu sprechen.

mal schauen was das noch so gibt im laufe der zeit 😃

die programmierer welt ist wirklich verrückt^^

Gelöschter Account
vor 13 Jahren

wobei das ja keine optimierung, sondern bugbehebung ist... aber ich finde es gut, das dein chef entwickler bereits einen schritt auf dich zugegangen ist. sieht so aus als würde das doch nciht so extrem schwierig wie ich anfangs vermutet habe.

301 Beiträge seit 2009
vor 13 Jahren

Am besten finde ich es immer selbst ein Vorbild zu sein. D.h. den Code den du schreibst, schreibst du so wie du es für richtig hältst. Das dein Chef sich nicht auf neue Vorschläge etc. einlässt ist eine Schwäche von ihm aber das sollte man als Neuling natürlich für sich behalten und wie viele hier schon geschrieben habe von innen heraus angehen. Irgendwann wird er sehen das du es drauf hast und dir auch zuhören

S
443 Beiträge seit 2008
vor 13 Jahren

Ich könnte mir denken das geschriebene Codingguidelines auch bei der Überzeugungsarbeit helfen.
z.B. nur ein lapitares Beispiel das Try-Pattern
Jede Methode die mit Try beginnt muss ein bool retunieren und als letzten Parameter einen out parameter haben.
Jede Aufruf muss mit einem if statement behandelt werden.

Als Argument dafür gilt
Was nützt mir ein Int.TryParse() wenn ich sowieso davon ausgehe das ich es parsen kann. Dann kann ich ja auch gleich (int) oder Parse verwenden.

Und wenn sich dann ein kleines Dokument mit ->guten<- Vorschlägen zusammenstellen lässt, das jeder mal lesen soll und jeder mal gelesen hat, hat man glaube ich die Hälfte der Miete gewonnen.

mbg
Rossegger Robert
mehr fragen mehr wissen

Montag morgen ist die beste Zeit um eine erfolgreiche Woche zu beginnen

1.815 Beiträge seit 2005
vor 13 Jahren

Hallo!

@ViperNeo:
Wie bereits spike24 angemerkt hat, solltet ihr evtl. mal interne Code-Richtlinien aufstelle, also z.B. sowas wie die 10 Gebote für eure Projekte. Dann hättet ihr zumindest schonmal eine gemeinsame Basis und in der Diskussion kommen da evtl. auch Standpunkte ans Licht die der jeweils andere noch garnicht berücksichtigt hat.

Nobody is perfect. I'm sad, i'm not nobody 🙁

S
443 Beiträge seit 2008
vor 13 Jahren

Und, so weit meine Erkenntnis, nur weil einer kompletten Bullshit programmiert heist das noch lange nicht, dass er keine guten Ideen hat.

bin immer wieder selbst über meine Ideen erstaunt 😃

mbg
Rossegger Robert
mehr fragen mehr wissen

Montag morgen ist die beste Zeit um eine erfolgreiche Woche zu beginnen

U
1.578 Beiträge seit 2009
vor 13 Jahren

PS. Bevor über Optimierungen gesprochen wird, sollte erstmal gemessen werden wo es am meisten Brennt.