Hallo Leute!
Wer kennt das nicht, man kommt vom Urlaub zurück in die Arbeit, und
möchte an seinem Code weiter arbeiten, welcher fast fertig war und nur
noch feinschliff brauchte, stellt fest, dass der nette Kollege
regelrecht mit dem Pflug durchgefahren ist und so ziemlich jede Funktion
und Klassen unbrauchbar gemacht hat, 0 Dokumentiert und alles schön in
einem commit regelrecht gequetscht. Irgendwie zuckt da mein linkes Auge
dezent.
Wie sind eure Erfahrungen damit und wie geht ihr damit um bzw. löst die
Situation konstruktiv?
Klar habe ich auch meine Backups, aber die Vorgabe vom CTO ist linearer
Fortschritt, "muss alles nachvollziehbar sein". Und der Kollege darf
nicht getriggert werden. Das heißt man muss auf alle Fälle seinen Code
mindestens 30% verändern, andere Namensvergebung gelten dabei nicht
sondern die Funktionen und Klassen sind dabei entscheidend.
Kai schrieb:> man kommt vom Urlaub zurück in die Arbeit, und möchte an seinem Code> weiter arbeiten, welcher fast fertig war und nur noch feinschliff> brauchte
Also Du hast den Kollegen was halbfertiges hinterlassen?
Entweder die brauchten das, dann haben sie alle Legitimation.
Oder es war klar, dass Du es jetzt weitermachen kannst, weil es noch
nicht verwendet wird, dann ist das übergriffig und muss geklärt werden.
Ja, kommt häufig vor, dass Leute meinen, etwas verbessern zu müssen.
Lager oder Werkstatt umräumen, wenn der erste Mann nicht da ist,
Dokumente neu formatieren, ...
Kai schrieb:> Wer kennt das nicht, man kommt vom Urlaub zurück in die Arbeit, und> möchte an seinem Code weiter arbeiten, welcher fast fertig war und nur> noch feinschliff brauchte
Ja, kenn ich.
Der nette Kollege, hat 1 Jahr an einem Auftrag zugebracht, Abgabetermin
1.1. und der Honk geht einfach in Urlaub bevor irgendwas läuft.
Lässt den code, an dem nichts funktioniert, undukumentiert zurück und
der Chef sagt: mach mal eben fertig, die bugs noch raus.
Da beim Programm wie üblich die ersten 10% der Arbeitszeit zwar 90% des
Produkts ergeben, aber die letzten 10% noch 90% der Zeit erfordern, hab
ich eben mal 9 Jahre seiner Arbeitsleistung in den 3 Wochen seines
Urlaubs erledigt.
Uff, gerade noch geschafft, zumindest die bekannten bugs sind raus, und
dann kommt der Honk aus dem Urlaub zurück und jammert, dass er seinen
code nicht wiedererkennt.
Das Gejammer ertrag ich nicht, kann man den nicht rausschmeissen ?
Kai schrieb:> Wie sind eure Erfahrungen damit und wie geht ihr damit um bzw. löst die> Situation konstruktiv?
Wir haben das was highly sophisticated, das nennt sich Prozess. Da
wissen die Kollegen, welcher Code (branch) noch nicht freigegeben ist
und wo sie Wildsau spielen können. Alles in einem Commit würde bei uns
im Codereview abgelehnt werden, daher versucht das keiner erst.
Das Gefühl kenne ich also eher nicht, aber generell: Reden hilft, sprich
mit deinen Kollegen, gib konstruktive Kritik und vereinbare mit Ihnen
Prozesse, an die sich alle halten und die Situation verbessern.
Hattest du vorher eine Testsuite in der schon vieles grün war?
Und die Tests sind jetzt rot?
Falls ja: Rollback und er soll seine Arbeit in einzelne Commits
aufteilen und einchecken ohne Tests kaputt zu machen.
Falls nein beginnt jetzt der Machtkampf anders vs. besser/schlechter.
Oder du wurstelst dich durch, findest dich zu recht und reparierst was
kaputt ist.
Blöd ist, wenn dein Kollege einen ganz anderen Programmierstil hat und
ihr euch deswegen im Code hinterherputzt.
Dann lohnt es, sich über eine Coding Guideline zu unterhalten.
Sinnvollerweise geht die dann über Zeilenformatierung hinaus und wird
aufgeschrieben, zumindest da wo ihr unterschiedlicher Meinung seid.
Kai schrieb:> Klar habe ich auch meine Backups, aber die Vorgabe vom CTO ist linearer> Fortschritt, "muss alles nachvollziehbar sein".
Sind denn die Änderungen des Kollegen alle nachvollziehbar?
> Und der Kollege darf nicht getriggert werden.
Was heißt "darf nicht getriggert werden"? Verbesserungen des
Entwicklungsprozesses sind nicht erwünscht?
> Das heißt man muss auf alle Fälle seinen Code mindestens 30% verändern,
Ist das eine Vorgabe? Das klingt irgendwie ziemlich dämlich.
Generell muss es eben einen Maintainer geben, also jemanden, der für den
Code verantwortlich ist und der entscheidet, ob Änderungen in den
Haupt-Entwicklungszweig übernommen werden oder nicht. Direkt dort wird
gar nichts geändert, sondern nur in separaten Branches, die dann vom
Maintainer nach Begutachtung übernommen oder eben abgelehnt werden.
Wenn jeder da unabhängig vom anderen im Code herumfuhrwerkt und man
nicht miteinander reden darf, kommt natürlich nur Mist raus.
MaWin schrieb:> Ja, kenn ich.>> Der nette Kollege,
viel besser man fragt micht ich sage das geht nicht!
Der Kollege übernimmt mit "kann ich, hier hier hier", meldet fertig,
wird befördert!
6 Monate später die ersten Baugruppen kommen ich soll das in Betrieb
nehmen und jeder Test läuft gut, mit und OHNE Baugruppe!
Den Schrott habe ich mir dann auch nicht mal angesehen!
Ich erwähnte ja schon da es so nicht funktioniert!
Kenne ich auch zu gut. Einfach so lassen, lächeln und winken, und wenn
das nächste mal ein Änderungswunsch kommt sagst du "ich hab gar keinen
Überblick mehr über den Code, das muss der Kollege machen". Wenn das
aber dir aufgebrummt wird, bei jedem Problem auf das du stößt den
Kollegen nerven à la "warum hast du daraus eine globale Variable
gemacht?" und ihn das korrigieren lassen.
Wenn er sich wehrt, musst du halt damit leben. Dann dauern halt alle
späteren Änderungen länger, weil man erstmal das Gewirr durchblicken
muss, und man zig Folgefehler beheben muss. Dass die Entwicklung immer
langsamer wird schert normalerweise keinen.
Falls doch, kannst du sagen "Seit Januar 2022 haben wir viel
technologischen Ballast, den wir erstmal beheben müssen". Wenn du Glück
hast darfst du dann aufräumen, ansonsten ist es dann halt so. Da kann
man nicht viel gegen machen, das ist leider Berufsalltag. Apathie und
Ignoranz beim Thema (Code-)Qualität sind allgegenwärtig. Der Trick ist,
sich nicht darüber aufzuregen, und am vermurksten Code so wenig wie
möglich zu machen und das dem Vermurkser zu überlassen. Die Arbeit, die
du nicht vermeiden kannst, musst du halt "irgendwie" reinfummeln, aber
fasse so wenig Code wie möglich an. Bloß nicht selber mit Refactorings
und Aufräumaktionen anfangen. Bei auftretenden Problemen aufgrund der
vermurksten Struktur immer den Kollegen fragen bzw. auf ihn abwälzen,
oder dem Chef sagen "Der Kollege hat das hier irgendwie so komisch
gemacht, das verstehe ich nicht, ich kann die Änderung da nicht
integrieren, was mache ich jetzt?".
Witzig ist's natürlich, wenn der Kollege es auch "besser weiß" und die
selbe Strategie fährt. Da landet man in einem Nash-Equilibrium in
welchem alle versuchen so wenig wie möglich zu machen.
Dadurch verrottet die Struktur natürlich immer mehr, aber das ist
sowieso unvermeidbar wenn man unantastbare Störfaktoren wie solche
Kollegen hat. Schade ist das i.W. für die Kunden, die sich mit so einer
verbockten Software herumplagen müssen. Wenn du Glück hast darfst du
irgendwann alles neu machen oder kannst in ein anderes Projekt fliehen.
Solche strukturellen Probleme kann man als Entwickler normalerweise
nicht angehen, weil die Chefs so etwas nicht interessiert und man dafür
keine Rückendeckung bekommt und das Unkraut halt leise vor sich hin
wuchert. Erst wenn von oben oder außen Stress kommt, z.B. weil Kunden
sich über die Qualität beschweren oder auffällt dass die Arbeit immer
ineffizienter wird, werden möglicherweise Nachforschungen angestellt und
dann kannst du ganz neutral sagen "wir haben im Code eine schlechte
Struktur weil Antipatterns XY vorhanden sind", und dann kommt eventuell
die Aufgabe das aufzuräumen nachdem man sich auf Best Practices geeinigt
hat.
Kai schrieb:> Und der Kollege darf> nicht getriggert werden. Das heißt man muss auf alle Fälle seinen Code> mindestens 30% verändern,
Wie meinst du das?
Imonbln schrieb:> Wir haben das was highly sophisticated, das nennt sich Prozess.
Haben viele Firmen nicht, wird oft aktiv abgelehnt, gern auch von ganz
oben. Da muss man sich mit arrangieren.
Imonbln schrieb:> Das Gefühl kenne ich also eher nicht, aber generell: Reden hilft, sprich> mit deinen Kollegen
Oft nicht so einfach, wenn die Kollegen schon länger in der Firma sind,
grundsätzlich keine anderen Meinungen akzeptieren und die Teamleiter nur
auf diese Kollegen hören.
Tilo R. schrieb:> Hattest du vorher eine Testsuite in der schon vieles grün war?> Und die Tests sind jetzt rot?
Tests oder CI werden von vielen Firmen ebenso abgelehnt.
ich werf hier regelmäßig Versionen aus der Verfolgung, wenn sie nicht
dokumentiert sind.
wenn jemand eine neue Version mit "Bugfix" eincheckt, werfe ich sie am
Tag darauf mit "Bug weiterhin vorhanden" raus.
wo ist das Problem?
Das Spiel können wir alle.
sg
Clemens S. schrieb:> ich werf hier regelmäßig Versionen aus der Verfolgung, wenn sie> nicht> dokumentiert sind.
Das kannst du aber nur machen wenn du selbst "Gewicht" und Einfluss
hast. Ansonsten kann sowas stark nach hinten losgehen.
Kai schrieb:> Wie sind eure Erfahrungen damit und wie geht ihr damit um bzw. löst die> Situation konstruktiv?
Das kommt drauf an. Öfter auch auf den Zusammenhang. Man fragt also
erstmal nach Warum und Standards, und wenn es explosiv wird, nach guter
Moderation.
Letztlich scheint die Kommunikation untereinander auch nicht so toll zu
sein? Vielleicht lässt sich hier etwas optimieren.
Aber Standards, Kommunikation, Mediation sollten schon irgendwie präsent
sein.
Also von oben betrachtet, wenn zwei Leute so völlig aneinander
vorbeicoden - das muss nicht sonderlich effektiv sein. Falls doch, und
man auf Ideensuche ist ok, aber so im normal-Alltag?
rbx schrieb:> Also von oben betrachtet, wenn zwei Leute so völlig aneinander> vorbeicoden - das muss nicht sonderlich effektiv sein.
dafür hatten wir genau einen Informatiker Werkstudenten der die
gesammelten Ing. Codes in eine gemeinsame LIB überführte, so hatte die
ganze Truppe was davon und es wurde kein Code doppelt erstellt, der Eine
machte dies, der Andere das und alle profitierten!
rbx schrieb:> Aber Standards, Kommunikation, Mediation sollten schon irgendwie präsent> sein.
Sollte, aber gibt's oft nicht. Man muss irgendwie damit leben.
rbx schrieb:> Also von oben betrachtet, wenn zwei Leute so völlig aneinander> vorbeicoden - das muss nicht sonderlich effektiv sein.
Ist es auch nicht, aber das interessiert oft auch nicht. Gerade in
Konzernen gibt es oft Behörden-Denke: Es dauert so lange, wie es dauert.
Und wenn man mehr Bugs als Zeilen hat - was soll's, wird das Projekt
halt 6 Monate später "fertig", Bugs kann man auch noch beheben wenn das
Produkt schon im Feld ist. Arbeitszeit wird ja sowieso über einen
anderen Topf abgerechnet, die ist eh gratis.
Joachim B. schrieb:> dafür hatten wir genau einen Informatiker Werkstudenten der die> gesammelten Ing. Codes in eine gemeinsame LIB überführte,
Spannend, viele Ingenieure würden niemals einem Informatiker zuarbeiten,
erst recht nicht einem Werkstudenten!
Programmierer schrieb:> Spannend, viele Ingenieure würden niemals einem Informatiker zuarbeiten,> erst recht nicht einem Werkstudenten!
warum nicht?
Wir mussten auch erst lernen das ein Informatiker kein "Programmierer"
sondern eher ein Architekt ist der Software auf ein stabiles Fundament
stellt.
Als E-Ings hatten wir programmieren nur angerissen oder uns das hobby
mäßig beigebracht, aber würden niemals an ein Informatikstudium ran
reichen!
Es ist borniert als -Ing über Informatiker die Nase zu rümpfen, das ist
zu oft Unwissenheit, denn wer weiss schon was ein Informatiker wirklich
macht?
> Und der Kollege darf> nicht getriggert werden. Das heißt man muss auf alle Fälle seinen Code> mindestens 30% verändern.
laut CTO: zur Steigerung der Diversity, ist es unerlässlich.
Der Verlauf von der Versionsverwaltung wird im Prinzip "nur für den
Kunden" verwendet und ausgehändigt um unsere Produktivität darzulegen.
Und im Meeting kommen dann so Weisheiten, da hätten wir 5 Zeilen sparen
können und hier könnte doch noch ne KI rein ist ja "easy"
pfff.... kann nicht mal ne If Abfrage formulieren.
Morgen Meeting!
Ich habe mir paar Notizen gemacht werde die Sache ruhig und bestimmt
angehen und eure Tipps ansprechen, bin gespannt wie es wird.
Kai schrieb:> Wie sind eure Erfahrungen damit und wie geht ihr damit> um bzw. löst die Situation konstruktiv?
Den aktuellen fall kannst du nicht ohne Ärger retten. Aber du kannst den
Kollegen und Chefs immer wieder klar machen, warum Doku wichtig ist.
Dokumente jeden darauf entstehenden Mehraufwand. Steter Tropfen höhlt
den Stein.
In der Firma wo ich derzeit arbeite war das fast vollständige Fehlen von
Doku ein riesen Problem. Alle haben die Augen davor verschlossen. Doch
inzwischen sind wir so weit, dass ich das Erstellen einer Lieferung ggf.
verweigern kann, ohne mich dafür umfangreich rechtfertigen zu müssen.
Auch der betrieb fordert sie inzwischen ein, wenn sie fehlt oder
unzureichend ist.
Was die unerwarteten Änderungen angeht würde ich dir empfehlen, mit
gutem Vorbild voran zu gehen. Diskutiere deine geplanten Änderungen
vorher mit den betroffenen Kollegen und lasse dir erste Entwürfe von
ihnen Abnicken. Dann werden die das irgendwann auch von sich aus nach
machen - wenn sie gut sind.
Wenn sie nicht, bleibt dir nur, es hinzunehmen oder dich für ihren
Rauswurf einzusetzen. Letzteres ist allerdings eine ganz heikle Sache
die du sehr vorsichtig und auf keinen Fall alleine angehen solltest.
Mir fällt dazu noch etwas ein: Wenn ihr im Team mit einem Source
Repository (Git oder so) arbeitet und eure Änderungen nach dem 4-Augen
Prinzip gegenseitig checkt, werdet ich ganz automatisch unnötig
umfangreiche Änderungen vermeiden.
Denn das wirft Fragen auf.
Beispiel: Zur irgend einer Liste soll ein Eintrag hinzugefügt werden. Da
kannst du nicht 20 Klassen umbenennen, packages verschieben und
Bibliotheken austauschen. Das wird dir der Kollege, der es kontrollieren
soll, umgehend um die Ohren hauen.
Solche Aktionen stimmt man vorher ab und erstellt sich intern einen
separaten Auftrag dafür der dann eigens committed wird. Und das macht
man nur dann, wenn alle Beteiligten dafür Zeit haben.
4-Augen Code-Review ist eine prima Methode, um sich gegenseitig zu
coachen.
Kai schrieb:> Wer kennt das nicht, man kommt vom Urlaub zurück in die Arbeit, und> möchte an seinem Code weiter arbeiten, welcher fast fertig war und nur> noch feinschliff brauchte, stellt fest, dass der nette Kollege> regelrecht mit dem Pflug durchgefahren ist und so ziemlich jede Funktion> und Klassen unbrauchbar gemacht hat, 0 Dokumentiert und alles schön in> einem commit regelrecht gequetscht. Irgendwie zuckt da mein linkes Auge> dezent.
Ich kenne das nicht. Mein Code ist mein Code - es sei denn für
Anpassungen / Korrekturen nach Produktivnahme. So lange es mein Projekt
oder meine Projektarbeit ist, ist es so. (Punkt) In welcher Klitsche
arbeitest Du denn (wenn Du denn beschäftigt ist, was ich bezweifle)?
Programmierer schrieb:> Erst wenn von oben oder außen Stress kommt, z.B. weil Kunden> sich über die Qualität beschweren oder auffällt dass die Arbeit immer> ineffizienter wird, werden möglicherweise Nachforschungen angestellt und> dann kannst du ganz neutral sagen "wir haben im Code eine schlechte> Struktur weil Antipatterns XY vorhanden sind", und dann kommt eventuell> die Aufgabe das aufzuräumen nachdem man sich auf Best Practices geeinigt> hat.
Das muss man sich trauen. Ich hatte mit einige Kollegen zu tun, die sich
nicht trauten, die Mängel klar aufzudecken. Es könnte passieren, dass
der Chef/Projektleiter den Ball zurück spielt und dir vorwirft, Misst
gebaut zu haben. Dann muss man den Mum haben, zu sagen "Ja Chef, wir
hatten damals unter Zeitdruck unsauber gearbeitet. Ich möchte das jetzt
gerne in Ordnung bringen".
Joachim B. schrieb:> Programmierer schrieb:>> Spannend, viele Ingenieure würden niemals einem Informatiker zuarbeiten,>> erst recht nicht einem Werkstudenten!>> warum nicht?
Mach dafür doch mal nen neuen Thread auf, hier im Forum gibt's
anscheinend viele solcher Profi-Ings. Für die gilt halt "was der Bauer
nicht kennt", und wenn der Informatiker etwas weiß das nicht im
"Grundkurs Programmieren" des Ing-Studiums abgedeckt wurde ist das
automatisch böse. Außerdem wissen Ings sowieso grundsätzlich alles
besser, erinnere dich an den Fliesenleger der keine Audi-Ings als Kunden
will...
Stefan ⛄ F. schrieb:> Dokumente jeden darauf entstehenden Mehraufwand. Steter Tropfen höhlt> den Stein.
Das wird ausgesessen. Du glaubst gar nicht wie groß die Kapazität ist,
"wir brauchen Doku" zu ignorieren!
Stefan ⛄ F. schrieb:> Was die unerwarteten Änderungen angeht würde ich dir empfehlen, mit> gutem Vorbild voran zu gehen. Diskutiere deine geplanten Änderungen> vorher mit den betroffenen Kollegen und lasse dir erste Entwürfe von> ihnen Abnicken.
Das gibt unendliche Diskussionen ("Bikeshedding") in denen man gründlich
auseinander genommen wird, was sich über Zig Meetings hin zieht in denen
jeder zu jedem Entwurf seinen Senf dazu geben will. Das hält nur aus,
wer sehr sehr starke Nerven hat.
Stefan ⛄ F. schrieb:> und eure Änderungen nach dem 4-Augen> Prinzip gegenseitig checkt, werdet ich ganz automatisch unnötig> umfangreiche Änderungen vermeiden.
Hat das gleiche Problem.
Stefan ⛄ F. schrieb:> Solche Aktionen stimmt man vorher ab
Super nervenaufreibend. Solche Aktionen überlässt man den anderen und
hält sich raus.
Stefan ⛄ F. schrieb:> 4-Augen Code-Review ist eine prima Methode, um sich gegenseitig zu> coachen.
Das wird eher ein frustrierendes "das haben wir schon immer so gemacht,
du machst das jetzt gefälligst auch so".
Hugo H. schrieb:> In welcher Klitsche> arbeitest Du denn
Ich kenne solche Probleme sowohl vom KMU mit 100 MAs als auch vom
Konzern mit 20000 MAs.
Stefan ⛄ F. schrieb:> Das muss man sich trauen. Ich hatte mit einige Kollegen zu tun, die sich> nicht trauten, die Mängel klar aufzudecken.
Ach, Mängel kann man gerne immer wieder ansprechen. Es bringt nur halt
nix, weil es sowieso ignoriert wird. Kann man schriftlich machen um sich
abzusichern, falls doch irgendwann mal eine Nachfrage kommt. Es gibt in
manchen Führungsetagen aber eben auch die Mentalität "es ist wie es
ist", die haben gar nicht den Anspruch Missstände zu erkennen und zu
beheben. Solange alle brav am Schreibtisch sitzen (bloß nicht im
HomeOffice!) und fleißig aussehen ist alles gut.
Programmierer schrieb:> Super nervenaufreibend. Solche Aktionen überlässt man den anderen und> hält sich raus.
Nicht wenn man der leitende Entwickler im Team ist. Dann muss man da
durch. Ich freue mich sehr, dass ich den "Senior Developer" Titel
bekommen habe, trotz meines "nur" Realschul Abschlusses. Aber jetzt muss
ich auch was dafür tun, damit ich nicht links und rechts von den anderen
überholt werden.
Stefan ⛄ F. schrieb:> Nicht wenn man der leitende Entwickler im Team ist. Dann muss man da> durch.
Stimmt, dann hat man aber auch ganz andere Möglichkeiten und kann
Mindeststandards durchsetzen. Ich hatte das Gefühl dass es um den Fall
eines normalen Entwicklers ohne Entscheidungsgewalt geht.
Stefan ⛄ F. schrieb:> Ich freue mich sehr, dass ich den "Senior Developer" Titel> bekommen habe, trotz meines "nur" Realschul Abschlusses.
Nicht schlecht. So mancher hochqualifizierter M.Sc. darf vielleicht
gerade mal Kaffee kochen weil alle anderen auf ihrer Machtposition
sitzen.
Programmierer schrieb:> Ich kenne solche Probleme sowohl vom KMU mit 100 MAs als auch vom> Konzern mit 20000 MAs.
Hatte ich Dich gefragt? Kannst Du konkrete Beispiele nennen?
Hugo H. schrieb:> Programmierer schrieb:>> Ich kenne solche Probleme sowohl vom KMU mit 100 MAs als auch vom>> Konzern mit 20000 MAs.>> Hatte ich Dich gefragt? Kannst Du konkrete Beispiele nennen?
Du schreibst in einem öffentlichen Forum. Da sind alle gefragt. Klar,
ich poste anonym um dann konkrete Firmen zu nennen...
Programmierer schrieb:> Klar,> ich poste anonym um dann konkrete Firmen zu nennen...
Dann brauchst Du auch gar nichts zu schreiben - rumschwurbeln kann jeder
(anonym) - der Wahrheitsgehalt ist vermutlich = 0.
Kai schrieb:> Und der Kollege darf> nicht getriggert werden. Das heißt man muss auf alle Fälle seinen Code> mindestens 30% verändern, andere Namensvergebung gelten dabei nicht> sondern die Funktionen und Klassen sind dabei entscheidend.
Na dein Kollege wollte offensichtlich nur ne Kleinigkeit ändern. Um das
zu ermöglichen musste er ja deinen Code durchpflügen, sonst wäre er ja
nie auf die 30% gekommen.
Also ich habe keine Ahnung von euren Arbeitsprozessen oder wer
berechtigt wäre, an meinem Code herumzufummeln bzw. was da für die
Urlaubszeit abgesprochen war.
Im ersten Schritt würde ich meine Backups "anbieten", im zweiten Schritt
dringend darum bitten, ein anderes/neues Projekt zu bekommen und im
dritten Schritt, wenn die ersten beiden nichts werden, kündigen. Ich
hätte keine Lust, den Scheiß da wieder aufzuräumen, den ein anderer
verzapft hat. Meine, man bekommt's bezahlt, aber der Zeitplan ist dann
natürlich im Eimer und das könnte Stress bedeuten, den ich mir nicht
machen möchte.
Ben B. schrieb:> Im ersten Schritt würde ich meine Backups "anbieten", im zweiten Schritt> dringend darum bitten, ein anderes/neues Projekt zu bekommen und im> dritten Schritt, wenn die ersten beiden nichts werden, kündigen. Ich> hätte keine Lust, den Scheiß da wieder aufzuräumen, den ein anderer> verzapft hat.
Würde, hätte - hast Du irgendetwas damit zu tun? Vermutlich nicht -
oder?
Stefan ⛄ F. schrieb:> ein Job-Titel
Oh Mann:
Bedeutungen von Titel:
Ehrenvoller, den Rang, Stand, die Würde seines Trägers kennzeichnender,
erworbener oder verliehener Zusatz zum Namen, der dem Namen
vorangestellt wird.
Hoffürst gehört nicht dazu - andere auch nicht :-/
> Würde, hätte - hast Du irgendetwas damit zu tun?
Mit seinem Code oder seinem Fall habe ich nichts zu tun.
Ansonsten schreibe ich Internetseiten oder kümmere mich um IT-Hardware.
Wenn mir da jemand den Code besonders nachhaltig versaut, dann soll er's
auch wieder in Ordnung bringen oder alleine fertig machen, das ist mir
dann ganz ehrlich egal.
Ich weiß immer nicht, inwieweit das vergleichbar ist, daher kann man auf
so eine Frage auch nicht mit mehr als der persönlichen Meinung
antworten. Bei großen Sachen arbeitet ja sowieso ein Team dran, man
schreibt nie alles alleine, sondern immer wieder einzelne Teile oder
Module. Dabei könnte man auch so planen, daß man mit seinen Teilen vor
dem Urlaub fertig ist bzw. in den Tagen kurz davor nur noch Teile
anfängt, die man auch vorher noch fertig bekommt. Oder wenn etwas
bestehendes geändert werden soll oder eine neue Funktion braucht, ist
man damit meistens auch recht schnell fertig.
Hugo H. schrieb:> An der Zitier-Funktion musst Du aber noch arbeiten
Wieso? Ich habe dich korrekt zitiert.
Dass du den Unterschied zwischen "Titel" und "Job-Titel" trotz der
verlinken Erklärungen nicht akzeptierst, muss ich wohl hin nehmen.
Wie wäre es einfach wortlos den letzten Commit rückgängig zu machen und
die Sache eskalieren zu lassen? Und wenn eine Anfrage kommt warum du das
gemacht hast, ganz offen zu sagen das du nicht seinen Saustall aufräumen
willst und jetzt Arbeit zu machen hast. Dann ist es auch wichtig beim
Chef, der irgendwann antanzen und meckern wird, nicht zurück zu weichen
sondern möglichst allumfassend darzustellen was der Kollege für eine
Pfeife ist und das was dieser in deinem Urlaub fabriziert hat letztlich
Sabotage war und alles außer dem konsequenten Rückdrehen mehr Zeit fürs
Reparieren erfordern wird. Danach kannst du sicher sein, dass nie wieder
jemand es wagt an deinen Code zu gehen und auch dein Chef es nicht
wieder riskieren wird das jemandem tun zu lassen. Falls der Chef aber
uneinsichtig ist, Kündigung einreichen weil der Laden früher oder Später
die Nummer eh vor die Wand fährt.
Pull Requests und verpflichtende Code Reviews. Ausnahmslos. Auch bei
kleinen Commits.
Dazu muss aber auch der Prozess und das Teamgefüge passen. Code Reviews
können, vorallem am Anfang einer Entwicklung, schonmal 20-30% der
Arbeitszeit einnehmen.
Mag bei vielen eine unpopuläre Maßnahme sein ("MEIN CODE IST
PERFEKT!!!!EinsEins WAS SIND DAS FÜR KOMMENTARE!!!!"), aber das sichert
nachhaltig die Qualität des Codes und verteilt das Wissen über Codeteile
im Team.
Kommentare sind wirklich nur der letzte Notnagel wenn man es nicht
geschafft hat den Quelltext für sich sprechen zu lassen und gehören
ansonsten nicht in den Quelltext...
tw schrieb:> Pull Requests und verpflichtende Code Reviews. Ausnahmslos. Auch bei> kleinen Commits.> Dazu muss aber auch der Prozess und das Teamgefüge passen. Code Reviews> können, vorallem am Anfang einer Entwicklung, schonmal 20-30% der> Arbeitszeit einnehmen.
Wesentlich sinnvoller ist es auf Testgetriebene Entwicklung zu setzen,
ist am Anfang schwer gewöhnungsbedürftig, spart am Ende aber unglaublich
viel Zeit bei den Code Reviews.
> Mag bei vielen eine unpopuläre Maßnahme sein ("MEIN CODE IST> PERFEKT!!!!EinsEins WAS SIND DAS FÜR KOMMENTARE!!!!"), aber das sichert> nachhaltig die Qualität des Codes und verteilt das Wissen über Codeteile> im Team.
Tests auch und zwar für alles.
Tim T. schrieb:> Wie wäre es einfach wortlos den letzten Commit rückgängig zu machen und> die Sache eskalieren zu lassen?
Ich denke das ist nur dann OK, wenn man dabei auch alle funktionalen
Änderungen wiederholt, die der Kollegen während des Urlaubs eingebaut
hat.
Problem: Das kostet Zeit (Testen nicht vergessen), die irgendwer
bezahlen muss. Also nicht einfach selbst entscheiden, es sei du hast die
Befugnis dazu.
Tim T. schrieb:> Wie wäre es einfach wortlos den letzten Commit rückgängig zu machen und> die Sache eskalieren zu lassen?
Naja, dabei könnte herauskommen das der 'fast fertige Code, der nur noch
Feinschliff brauchte' eben nicht ganz so fertig war.
Die Geschichte ist irgendwie nicht ganz eindeutig.
Niemand fuhrwerkt ohne Not in der Art im Code eines anderen herum und
niemand hinterlässt dann dieses beschriebene Chaos und wird dann von der
GF abgeschirmt.
Mal eine andere Lesart:
So aus der Ferne betrachtet sieht das so aus also ob der Coding Style
des TO nicht unbedingt auf Gegenliebe gestoßen ist, er aber auch
niemanden da ran läßt und sich der Zusammenarbeit verweigert, weil er
SEINEN Code als eine Art persönliches Eigentum sieht, obwohl der zu 100%
der Fa. gehört, die den eben auch von mehr als einer Person gepflegt
haben will.
Den Urlaub hat man nun genutzt da einen anderen heranzusetzen, der da
eine neue Struktur reinbringen sollte, ohne das das unbedingt fertig
werden muss.
Der wird da auch keinen Bock drauf gehabt haben und mit der GF
ausgehandelt haben das man den dann aber nicht den Wölfen vorwirft, wenn
er sich schon auf die Art unbeliebt macht.
Solche Fälle habe ich erlebt.
Man lässt die Projekte seiner Kollegen tunlichst in Ruhe, weil es da nur
Frust und Schläge zu verdienen gibt und jeder ja voll mit seinen eigenen
Projekten ist.
Also WARUM ist das nun so passiert und WARUM wird der Kollege
abgeschirmt statt getadelt?
Tim T. schrieb:> Wesentlich sinnvoller ist es auf Testgetriebene Entwicklung zu setzen,> ist am Anfang schwer gewöhnungsbedürftig, spart am Ende aber unglaublich> viel Zeit bei den Code Reviews.
Ich habe lange in einem Team gearbeitet, welches beides vorgeschrieben
hat. Bevor man eine Zeile Code geschrieben hatte, musste der Test
geschrieben sein. Zusätzlich verpflichtende Code Reviews.
Und zum Code Review wurde nur zugelassen, was entsprechende formale
Kriterien erfüllt bzegl. Code Coverage usw.
Stefan ⛄ F. schrieb:> Tim T. schrieb:>> Wie wäre es einfach wortlos den letzten Commit rückgängig zu machen und>> die Sache eskalieren zu lassen?>> Ich denke das ist nur dann OK, wenn man dabei auch alle funktionalen> Änderungen wiederholt, die der Kollegen während des Urlaubs eingebaut> hat.
Wichtiger als die Änderungen die Kollege gemacht hat, ist die Form. Wenn
die nicht stimmt, sind die Änderungen wertlos und werden ersetzt.
> Problem: Das kostet Zeit (Testen nicht vergessen), die irgendwer> bezahlen muss. Also nicht einfach selbst entscheiden, es sei du hast die> Befugnis dazu.
Klar, wer soll den Entwickeln und dazu gehört es auch Sabotage von
Dritten zu verhindern also ist die Befugnis automatisch vorhanden.
Tim T. schrieb:> Kommentare sind wirklich nur der letzte Notnagel wenn man es nicht> geschafft hat den Quelltext für sich sprechen zu lassen und gehören> ansonsten nicht in den Quelltext...
Im Idealfall ist für den Leser offensichtlich, was der Code macht.
Aber warum man es programmiert hat ist öfter nicht offensichtlich. Das
sollte man dann dort oder in einem separaten Dokument (z.B. Wiki)
erklären. Das gilt ganz besonders für Sonderlocken und Workarounds, die
man schnell vergisst weil man sie nicht jeden Tag auf dem Schirm hat.
tw schrieb:> Tim T. schrieb:>> Wesentlich sinnvoller ist es auf Testgetriebene Entwicklung zu setzen,>> ist am Anfang schwer gewöhnungsbedürftig, spart am Ende aber unglaublich>> viel Zeit bei den Code Reviews.>> Ich habe lange in einem Team gearbeitet, welches beides vorgeschrieben> hat. Bevor man eine Zeile Code geschrieben hatte, musste der Test> geschrieben sein. Zusätzlich verpflichtende Code Reviews.> Und zum Code Review wurde nur zugelassen, was entsprechende formale> Kriterien erfüllt bzegl. Code Coverage usw.
Und genau so macht man es eben nicht. Du schreibst einen kleinen Teil
des Test, der geht in die Hose. Dann schreibst du den Code das der Test
erfüllt wird, nicht mehr. Dann gehts wieder an den Test und fügst wieder
was hinzu das in die Hose gehen muss. Dann wieder an den Code usw.. Am
Ende hast du automatisch einen Code der alle Tests erfüllt.
Was viele dann aber nicht verstehen ist, dass der Code nicht fertig ist
wenn alles läuft (Tests laufen komplett durch) sondern danach das
Refactoring stattfindet und dafür gibts dann Code Reviews.
Stefan ⛄ F. schrieb:> Tim T. schrieb:>> Kommentare sind wirklich nur der letzte Notnagel wenn man es nicht>> geschafft hat den Quelltext für sich sprechen zu lassen und gehören>> ansonsten nicht in den Quelltext...>> Im Idealfall ist für den Leser offensichtlich, was der Code macht.
Im Normalfall.
> Aber warum man es programmiert hat ist öfter nicht offensichtlich. Das
Doch, genau so soll es geschrieben werden.
> sollte man dann dort oder in einem separaten Dokument (z.B. Wiki)> erklären. Das gilt ganz besonders für Sonderlocken und Workarounds, die> man schnell vergisst weil man sie nicht jeden Tag auf dem Schirm hat.
Was hält dich davon ab solche Sachen in Klassen und Funktionen
auszudrücken?
Tim T. schrieb:> Wichtiger als die Änderungen die Kollege gemacht hat, ist die Form. Wenn> die nicht stimmt, sind die Änderungen wertlos und werden ersetzt.
Bist du sicher, dass Geschäftsführung und Kunde das ebenso sehen?
Stefan ⛄ F. schrieb:> Tim T. schrieb:>> Wichtiger als die Änderungen die Kollege gemacht hat, ist die Form. Wenn>> die nicht stimmt, sind die Änderungen wertlos und werden ersetzt.>> Bist du sicher, dass Geschäftsführung und Kunde das ebenso sehen?
Ja, weil es letztlich zu besserem Code führt der auch noch eher fertig
ist.
Das habe ich auch schon oft gesehen... irgendwelche Programmteile, die
irgendwelche Tests erfüllen, aber für die eigentliche Aufgabe
unbrauchbar sind.
Beispiel ungefähr sowas wie "speichert problemlos n 500kb große
Bilddateien pro Sekunde weg". Kunde kommt und kippt ein unbearbeitetes
Bild direkt aus der Kamera mit 5..6 Megabyte rein. So, was machste?
Schreibste gleich ein Script, was auch mit beliebig großen Inhalten
klarkommt, bzw. stellst einen entsprechend starken Server hin oder
nicht? Meckerst den DAU an "Ey das Bild darf nur 500kb groß sein?" -
darauf der Kunde "Was is'n ein kb?" Oder wenn der Kunde ein Video oben
reinschmeißt? Wenn nicht, erfüllt man zwar weiterhin die Tests, aber der
Kunde wird erstmal rumnörgeln wieso das tolle teure Programm das nicht
kann.
Ben B. schrieb:> Meckerst den DAU an "Ey das Bild darf nur 500kb groß sein?" -> darauf der Kunde "Was is'n ein kb?" Oder wenn der Kunde ein Video oben> reinschmeißt? Wenn nicht, erfüllt man zwar weiterhin die Tests, aber der> Kunde wird erstmal rumnörgeln wieso das tolle teure Programm das nicht> kann.
Wenn du dein Anforderungsmanagement nicht im Griff hast, dann können die
Tests nichts dafür.
IMHO kommt es einfach drauf an was für einen subjektiv besser ist und
logischerweise unterscheiden sich da einfach die Meinungen, ist ja auch
okay, weil beim Programmieren viele Wege zum Ziel führen, meine
Erfahrungen zeigen dass wenn man seine Meinung aufdrückt nach biegen und
brechen, kommt nur Stress um die Ecke und hilft am Ende keinem. Ein
anderer Codestyle zu haben kann unter umständen sogar Vorteile haben,
weil sie ein anderes Mindset haben, und unterschiedliche Ansätze
abdecken können, jedoch wenn man sich nur in die quere kommt ist mit
vorankommen auch nichts mehr. Man muss einfach den gegenüber
respektieren, und wenn man schon an einem fast fertigen Projekt weiter
arbeitet, sollte es zu ende gebracht werden, dass im Anschluss der
Kollege sich nicht ärgert oder unnötig Zeit in den Sand setzt. Wenn man
alleine schon vermutet nicht fertig zu werden, wenn der Kollege im
Urlaub ist, Finger weg vom Projekt. Wir haben hier zB. relativ viel
Legacy Code und einige Kollegen sind schon in Rente, wenn die nicht
anständig Dokumentiert hätten wäre die Hölle los, abgesehen davon ist
das unverantwortlich und teilweise ziemlich egoistisch. Wir sind schon
so weit dass Azubis und die Profis mit Cola und Fast Food & fettige
Chips Finger am Arbeitsplatz ihre eigene Maus und Tastatur bekommen,
nach ihrer Wahl. Bauen die hauptsächlich nur firmeninterne Tools für
mindestens 2 Jahre und müssen diese verwenden. Jeder hat seinen Mentor
und an die Gepflogenheiten herangeführt. Erst dann werden sie auf die
Produktpalette los gelassen.
Theo K. schrieb:> IMHO kommt es einfach drauf an was für einen subjektiv besser ist und> logischerweise unterscheiden sich da einfach die Meinungen, ist ja auch> okay, weil beim Programmieren viele Wege zum Ziel führen, meine
Genau da wird der erste Fehler gemacht, es gibt eben nicht viele Wege
zum Ziel. Es gibt viele Wege lauffähigen Code zu bekommen ja, aber das
ist nicht das (alleinige) Ziel. Wenn der Code (fehlerfrei) läuft, ist
erst die halbe Arbeit getan, aber das verstehen immer noch zuwenige.
> Erfahrungen zeigen dass wenn man seine Meinung aufdrückt nach biegen und> brechen, kommt nur Stress um die Ecke und hilft am Ende keinem. Ein> anderer Codestyle zu haben kann unter umständen sogar Vorteile haben,> weil sie ein anderes Mindset haben, und unterschiedliche Ansätze> abdecken können, jedoch wenn man sich nur in die quere kommt ist mit
Wir sind ja nicht mehr in der Steinzeit und es gibt entsprechende
Methoden, nur müssen diese eben auch angewendet werden, von allen. Also
hat entweder der Mitarbeiter vorher schon Mist gebaut und der Vertreter
es richtig gemacht oder der Vertreter hat Mist gebaut und der Kollege
vorher hat es richtig gemacht, oder beide haben es verbockt. Die
geeigneten Schlüsse sollte jeder selber ziehen können.
> vorankommen auch nichts mehr. Man muss einfach den gegenüber> respektieren, und wenn man schon an einem fast fertigen Projekt weiter> arbeitet, sollte es zu ende gebracht werden, dass im Anschluss der> Kollege sich nicht ärgert oder unnötig Zeit in den Sand setzt. Wenn man> alleine schon vermutet nicht fertig zu werden, wenn der Kollege im
Nimm den Kollegen aus der Gleichung. Guter Code ist was geliefert werden
muss, nichts anderes, da spielen die Befindlichkeiten irgendwelcher
Kollegen keine Rolle.
> Urlaub ist, Finger weg vom Projekt. Wir haben hier zB. relativ viel> Legacy Code und einige Kollegen sind schon in Rente, wenn die nicht
Die Bezeichnung Legacy Code ist eine beschissene Entschuldigung für
schlechten Code.
> anständig Dokumentiert hätten wäre die Hölle los, abgesehen davon ist> das unverantwortlich und teilweise ziemlich egoistisch. Wir sind schon
Beschissener Code wird durch Dokumentation nicht gut, nur halbwegs
nutzbar, besser wäre es gewesen seinerzeit es direkt richtig zu machen,
aber da hat dann wohl jemand gepennt.
> so weit dass Azubis und die Profis mit Cola und Fast Food & fettige> Chips Finger am Arbeitsplatz ihre eigene Maus und Tastatur bekommen,
Jeder wie er mag, das hat nichts mit der Qualität der Software zu tun,
eventuell aber mit der Motivation der Mitarbeiter. Wobei ich mir
Paarprogrammierung dann relativ eklig vorstelle und eventuell auch nicht
wirklich produktiv.
> nach ihrer Wahl. Bauen die hauptsächlich nur firmeninterne Tools für> mindestens 2 Jahre und müssen diese verwenden. Jeder hat seinen Mentor> und an die Gepflogenheiten herangeführt. Erst dann werden sie auf die> Produktpalette los gelassen.
Also trainiert ihr eure neuen Leute mit Leuten die von schlechtem Code
trainiert wurden um es dann besser zu machen?
Kai schrieb:> Der Verlauf von der Versionsverwaltung wird im Prinzip "nur für den> Kunden" verwendet und ausgehändigt um unsere Produktivität darzulegen.> Und im Meeting kommen dann so Weisheiten, da hätten wir 5 Zeilen sparen> können und hier könnte doch noch ne KI rein ist ja "easy"
Das klingt völlig kaputt...
> aber die Vorgabe vom CTO ist linearer> Fortschritt, "muss alles nachvollziehbar sein". Und der Kollege darf> nicht getriggert werden. Das heißt man muss auf alle Fälle seinen Code> mindestens 30% verändern,
Das klingt mehr als völlig kaputt!
Als Software-Entwickler kannst Du Dir Deinen Arbeitgeber frei aussuchen.
Wozu sich mit so einem Blödsinn rum ärgern? Verstehe ich nicht.
Guter Code muss sauber dokumentiert sein!
Ich sehe mir regelmäßig Code von anderen an (man muss ja nicht alles
immer selber machen) und zu 99% ist der Code zwar lauffähig aber
Kommentar Fehlanzeige. Gute Dokumentation scheint heute irgendwie aus
der Mode zu kommen. Fehlt nur noch das die Variablen v1... Vx heißen.
Wenn ich aus dem Urlaub komme und der Code ist nicht mehr zu gebrauchen
ist Party angesagt und wenn mein Chef das nicht kapiert war er mal mein
Chef.
Uli schrieb:> Ich sehe mir regelmäßig Code von anderen an (man muss ja nicht alles> immer selber machen) und zu 99% ist der Code zwar lauffähig aber> Kommentar Fehlanzeige.
Guter Code ist selbsterklärend, sodass man keine Kommentare braucht. Bei
Kommentaren besteht immer die Gefahr, dass sie falsch sind, weil der
Code geändert wurde, der Kommentar aber nicht. Daher gehören Kommentare
nur an schwierige Stellen, und idealerweise dokumentieren sie nur das
"warum", denn das "was" und "wie" ist am Code ersichtlich!
Programmierer schrieb:> Guter Code ist selbsterklärend, sodass man keine Kommentare braucht. Bei> Kommentaren besteht immer die Gefahr, dass sie falsch sind, weil der> Code geändert wurde, der Kommentar aber nicht.
Ja, da zeigt sich dann gleich wie sauber gearbeitet wurde.
Kommentare sollen m.E. zusammenfassen. Man kann nicht erst den ganzen
Code lesen muessen um zu verstehen was wie passiert. Und gute Bezeichner
sind da notwendig aber nicht das Allheilmittel.
Bei ner Bibliothek wuerde man doch auch nicht sagen, wenn sie gut
programmiert ist, braucht man keine Doku.
Programmierer schrieb:> Guter Code ist selbsterklärend, sodass man keine Kommentare braucht.
Schön war's. Wir sind hier aber in einer einfachen Märchenwelt.
Guter Code macht offensichtlich, was darin passiert, aber oft nicht
warum. Ein Beispiel aus meinem Umfeld:
Der Kunde muss für seinen Warenkorb 12,4312€ bezahlen. Paypal liefert in
seiner Response 12,43€ zurück. Also ist die Zahlung im Grunde genommen
fehlgeschlagen.
1
if(bezahlt!=angefordert){
2
throwException;
3
}
Im produktiven Code steht aber sinnvollerweise:
1
// Ticket 43412:
2
// Wir lassen maximal 1 Cent Differenz zu, weil Paypal keine Bruchteile
3
// von Cent unterstützt, diese aber aufgrund der Mehrwertsteuer entstehen.
4
if(abs(bezahlt-angefordert)>0.01){
5
throwException;
6
}
(Das ist kein richtiges C, ist mir klar. Ich wollte es einfach
darstellen.)
Kai schrieb:> man kommt vom Urlaub zurück in die Arbeit, und> möchte an seinem Code weiter arbeiten, welcher fast fertig war und nur> noch feinschliff brauchte
Was sind denn das für Zustände?
Wer geht denn in den Urlaub obwohl er seinen Code "noch nicht fertig
hat"?
Vielleicht auch noch den Branch seit Monaten pflegen..?
Stefan ⛄ F. schrieb:> if (abs(bezahlt-angefordert) > 0.01) {> throw Exception;> }
Hmm.. wie war das nochmal mit vergleichen von Fliesskommazahlen? ;)
Man kann auch sinnvolle Namen vergeben, dass vermeidet unnötige "Doku"
bzw. schlecht lesbaren Code.
Stefan ⛄ F. schrieb:> Im produktiven Code steht aber sinnvollerweise:
Dieser Kommentar erklärt ja das warum, und ist daher sinnvoll. Du
könntest aber noch erklären warum floating-point für Währung benutzt
wird, und warum du mit 0.01 vergleichst, was ja nichtmal darstellbar
ist... :P
So etwas wie
1
// Datei löschen
2
remove(dataFile);
hingegen ist sinnlos, denn es ist offensichtlich, was passiert.
Mladen G. schrieb:> Wer geht denn in den Urlaub obwohl er seinen Code "noch nicht fertig> hat"?
Software ist nie fertig. Sie wird nur irgendwann released.
Programmierer schrieb:> Dieser Kommentar erklärt ja das warum, und ist daher sinnvoll.
Darum ging es mir.
Mladen G. schrieb:> Hmm.. wie war das nochmal mit vergleichen von Fliesskommazahlen? ;)Programmierer schrieb:> Du könntest aber noch erklären warum floating-point> für Währung benutzt wird
Wie gesagt: Ich habe es vereinfacht als Pseudo-Code dargestellt. In
Wirklichkeit nutzen wir an der Stelle Java Objekte mit Attributen vom
Typ BigDecimal. Dort ist auch kommentiert, welche Einheit die Zahl hat.
Stefan ⛄ F. schrieb:> Wie gesagt: Ich habe es vereinfacht als Pseudo-Code dargestellt. In> Wirklichkeit nutzen wir an der Stelle den Java Typ BigDecimal.
Man könnte diese if Abfrage in eine Methode packe die zB.
"hasCentFractions" oder ähnlich heisst, damit erspart man sich den
Kommentar, wenn sich die Ticket Nummern nie ändern, ist die Ticketnummer
nicht verkehrt, würde ich persönlich lieber in den Unittest packen
anstatt in den Produktiv Code.
BigDecimal für Währungen zu nehmen finde ich komisch, man könnte ja auch
eine eigene Abstraktion für Currency haben und solche
Methoden/Konvertierungen da rein packen, würden da ja hingehören.
Programmierer schrieb:> Software ist nie fertig. Sie wird nur irgendwann released.
Klar.
Aber einen vergammelten Branch weiter pflegen der mindestens einen
Urlaub überlebt, ist IMO ein No Go.
Mladen G. schrieb:> BigDecimal für Währungen zu nehmen finde ich komisch
Ich auch. Das haben sich andere Leute ausgedacht, bevor ich in die Firma
kam. Ein "Money" Objekt mit Betrag, Währung und dazu passenden Methoden
wäre wohl sinnvoller.
Stefan ⛄ F. schrieb:> Ein "Money" Objekt mit Betrag, Währung und dazu passenden Methoden wäre> wohl sinnvoller.
Genau.
Und weil niemand bedacht hat, dass money doch ne Zahl ist, hat man neben
den Grundrechenarten auch gleich alle anderen Mathefunktionen nicht
unterstützt.
Für Jahre und Monate hat man auch noch eigenen 'Objekte' und so wird
eine einfache Zinsrechnung oder Beitragsrechnung für eine
Lebensversicherung ein grosser Spass mit stândiger hin und
herkonvertiererei damit man doch wieder normale z.B. double Zahlen zum
Rechnen mit Logarithmus und Exponenten bekommt.
Und der code wird obskurer und obskurer weil man UM die Objekte
drumrumprogrammieren muss statt mit ihnen. Typischer Fall wie man sich
mit übertriebener Objektorientierung ins Knie schiesst.
MaWin schrieb:> Und weil niemand bedacht hat, dass money doch ne Zahl ist, hat man neben> den Grundrechenarten auch gleich alle anderen Mathefunktionen nicht> unterstützt.
Das ist dann wohl schlicht "falsch programmiert".
Nebenbei, das ist ein altes Paradebeispiel für Objektorientierung:
https://martinfowler.com/eaaCatalog/money.html
Statt Fliesskommazahlen nimmt man da besser skalare Typen.
Programmierer schrieb:> Guter Code ist selbsterklärend, sodass man keine Kommentare braucht.
Dieses Ammenmärchen wird durch Wiederholung nicht wahrer.
Hinter der Behauptung stecken häufig triviale Gründe wie dass der
Programmierer einfach keine Lust hat zu kommentieren, allgemein keine
Lust hat Dokumentation zu schreiben und generell lieber mit Computern
denn mit Menschen kommuniziert.
Dazu noch die Grundeinstellung "it was hard to write, it should be hard
to use", also der Wunsch als Genie anerkannt zu werden und sich
unverzichtbar zu machen.
> Bei> Kommentaren besteht immer die Gefahr, dass sie falsch sind,
Bei Code besteht auch immer die Gefahr dass er falsch ist...
Kommentare und Code gehören beide gemeinsam und gleich sorgfältig
gewartet. Code drückt zum Beispiel keine Entscheidungsgründe aus. Wenn
man natürlich keine Lust hat die Kommentare zu warten, dann, ja dann ist
halt Scheiße.
Wenn man im Team keine Kommentare möchte, dann sollte man wenigsten
ehrlich sein und statt dem Ammenmärchen vom selbsterklärenden Code offen
deklarieren dass keine Kommentare geschrieben werden weil man keine
schreiben möchte.
Als irgendwann Ende der 90ern Extreme Programming aufkam waren die
ehrlich. Die behaupteten Code ist zum Wegschmeißen gedacht. Was man
nicht versteht wird neu geschrieben, daher braucht man sowieso keine
Kommentare. Nun ist das erstens eine sich selbst erfüllende Prophezeiung
und zweitens wird heute der Aspekt dass man routinemäßig Code
wegschmeißt gerne vergessen wenn selbsterklärender Code propagiert wird.
Umsch-Win-F schrieb:> Dieses Ammenmärchen wird durch Wiederholung nicht wahrer.
Behauptest du. Vielleicht bist DU nur nicht dazu in der Lage
selbsterklärenden Code zu schreiben? Moderne Programmiersprachen helfen
dabei mit aussagekräftigen Sprachkonstrukten. Wenn man alles in C89
schreibt ist es halt etwas schwieriger.
Umsch-Win-F schrieb:> Dazu noch die Grundeinstellung "it was hard to write, it should be hard> to use", also der Wunsch als Genie anerkannt zu werden und sich> unverzichtbar zu machen.
Das ist das Gegenteil von selbsterklärendem Code.
Umsch-Win-F schrieb:> Bei Code besteht auch immer die Gefahr dass er falsch ist...
Code wird aber debuggt, Fehler fallen früher oder später auf und müssen
repariert werden.
Umsch-Win-F schrieb:> Kommentare und Code gehören beide gemeinsam und gleich sorgfältig> gewartet.
Das ist Wunschdenken.
Programmierer schrieb:> Vielleicht bist DU nur nicht dazu in der Lage> selbsterklärenden Code zu schreiben?
Mache mal für mein Beispiel mit der Paypal Zahlung eine selbsterklärende
Variante. Ich würde gerne mal sehen, wie du dir das im Kopf vorstellst.
1
// Ticket 43412:
2
// Wir lassen maximal 1 Cent Differenz zu, weil Paypal keine Bruchteile
3
// von Cent unterstützt, diese aber aufgrund der Mehrwertsteuer entstehen.
4
if(abs(bezahlt-angefordert)>0.01){
5
throwException;
6
}
Noch einer, schreibe den auch mal um:
1
// Ticket 43413:
2
// In the sandbox the parameter is received in camelCase although
3
// the specification dictates lower case. We support both
Stefan ⛄ F. schrieb:> Mache mal für mein Beispiel mit der Paypal Zahlung eine selbsterklärende> Variante.
Wie gesagt, die Paypal-Sache ist gut so, weil sie das WARUM erklärt,
denn das WAS und WIE sind offensichtlich. Schlecht wäre so etwas (die
Sache mit floating/Decimal erstmal ignoriert):
1
// Frage bezahlten Betrag ab
2
floatbezahlt=queryPaid();
3
4
// Frage geforderten Preis ab
5
floatangefordert=queryPrice();
6
7
// Vergleiche Differenz mit 1ct
8
if(abs(bezahlt-angefordert)>0.01){
9
// Exception werfen
10
throwException;
11
}
Da sind nur offensichtliche Dinge erläutert, aber das Wichtigste,
nämlich der Grund und die Ticket-Nummer, fehlen.
Der Gipfel der Sinnlosigkeit ist so etwas:
Programmierer schrieb:> Der Gipfel der Sinnlosigkeit ist so etwas:int i; // Deklariere> Integer-Variable i
Allerdings. Sowas lösche ich immer ohne Rücksicht.
Stefan ⛄ F. schrieb:> Mache mal für mein Beispiel mit der Paypal Zahlung eine selbsterklärende> Variante. Ich würde gerne mal sehen, wie du dir das im Kopf vorstellst.
Bitte nicht auf Typ oder Namen rumreiten, die habe ich jetzt für das
Snipet geraten. Auch der Ticketkommentar nur als Verknüpfung zum
Ticketsystem, da ist jede Alternative recht.
Der Vorteil der Konstanten hier ist nicht die reine Lehre (da würd ich
im Zweifel nichts drauf geben) sondern dass es für dieses Ticket, diese
Aufgabe ein eindeutiges Token gibt. Sowas ist z.B. automatisiert viel
einfacher aus dem Code zu extrahieren oder zu ändern als über einen
Ticket-Kommentar über einer Funktion.
Die Konstante gefällt mir (könnte auch konfigurierbar sein), aber der
Ticket-Kommentar ist mir zu wenig. Solange man die Absicht in 1-3 Zeilen
beschrieben kann, sehe ich sowas lieber direkt im Quelltext.
Vorausgesetzt, das bliebt die Ausnahme. Nicht dass der Code mit
Kommentaren überflutet wird. Wenn das nötig wäre, kann man lieber auf
einen Wiki Artikel verweisen.
Es gibt auch die Variante, dass man Workarounds in eigene Klassen oder
Funktionen verpackt:
1
PaypalWorkaround17.checkDifference();
2
PaypalWorkaround17.checkCurrency();
Sollte irgendwann die API von Paypal ihre Fehler oder Unzulänglichkeiten
ausbügeln, kann mit einem einfachen Refactoring der Source Code an allen
Stellen von der Spezialbehandlung durch den Workaround getilgt werden.
Wie bei allen Patterns, erst überlegen ob sie im vorliegenden Fall Sinn
machen.
Und zum Thema: Ich habe schon lange aufgehört, hinter dem Code von
anderen aufzuwischen.
Wer nicht hören will, muss fühlen. Da bringt es nichts, 6 Monate vorher
das Orakel zu spielen und als Nestbeschmutzer dazustehen.
Wenn die Kacke dann dampft, und sie dann auf mich hören wollen, helfe
ich gerne. Dafür werde ich dann bezahlt.
Ärgerlich nur, dass die "Problemkinder" durch ihre Unfähigkeit meist
einen Haufen Ressourcen binden, die Top Themen im Projektplan
beherrschen (weil nun dringend oder am Arsch) und ganz viel Facetime mit
den vorgesetzten und allen möglichen Gremien bekommen.
Stefan ⛄ F. schrieb:> Die Konstante gefällt mir (könnte auch konfigurierbar sein), aber der> Ticket-Kommentar ist mir zu wenig. Solange man die Absicht in 1-3 Zeilen> beschrieben kann, sehe ich sowas lieber direkt im Quelltext.
Das ist ja genau der Grund, warum "sauber Dokumentiert" für viele was
unterschiedliches meint.
Wenn das Ticketsystem mehr als 5 Klicks braucht, ja, dann muss man es
vielleicht im Kommentar nochmal hinschreiben. Gut ist das nicht (DRY!).
Wenn die Exception auftritt, dann will ich wissen, wann genau und warum
(>1 Cent. Nicht >=, nicht vorher gerundet, etc.). Nicht wofür das gut
ist, dass sehe im Code (PayPalToleranz), im VCS-Commit-Kommentar (beim
Blame: "Paypal rundet anders als wir) oder im Ticket #4711.
Stefan ⛄ F. schrieb:> Programmierer schrieb:>> Vielleicht bist DU nur nicht dazu in der Lage>> selbsterklärenden Code zu schreiben?>> Mache mal für mein Beispiel mit der Paypal Zahlung eine selbsterklärende> Variante. Ich würde gerne mal sehen, wie du dir das im Kopf vorstellst.> // Ticket 43412:> // Wir lassen maximal 1 Cent Differenz zu, weil Paypal keine Bruchteile> // von Cent unterstützt, diese aber aufgrund der Mehrwertsteuer> entstehen.> if (abs(bezahlt-angefordert) > 0.01) {> throw Exception;> }
Bei solchen Sachen würde ich eine Funktion/Methode schreiben, deren Name
ausdrückt was da passieren soll. Das mache ich gerne, mehrere
Programmschritte in Funktionen zu verpacken und damit zu benennen.
1
/* Löst das Problem, daß PayPal keine Bruchteile von Cents unterstützt die
2
* durch die Märchensteuer zwangsläufig entstehen, siehe Ticket #777999.
3
* Die Methode liefert True zurück, falls die Differenz zwischen bezahltem
4
* und angefordertem Betrag *noch innerhalb der Toleranz von einem Cent
if (isInPayPalRoundingRange(bezahlt, angefordert) {
14
throw Exception;
15
}
Der Ansatz ist jetzt mal nur aus dem Ärmel geschüttelt, ich hab seit ca.
einem Jahr nicht mehr ernsthaft programmiert, aber ich denke du
verstehst was ich meine.
In den Javadoc/Doxygen-Beschreibungen kann man das ja noch beliebig
ausführen und vertiefen.
Umsch-Win-F schrieb:> Programmierer schrieb:>> Guter Code ist selbsterklärend, sodass man keine Kommentare braucht.>> Dieses Ammenmärchen wird durch Wiederholung nicht wahrer.>> Hinter der Behauptung stecken häufig triviale Gründe wie dass der> Programmierer einfach keine Lust hat zu kommentieren, allgemein keine> Lust hat Dokumentation zu schreiben und generell lieber mit Computern> denn mit Menschen kommuniziert.>> Dazu noch die Grundeinstellung "it was hard to write, it should be hard> to use", also der Wunsch als Genie anerkannt zu werden und sich> unverzichtbar zu machen.
Unsinn...einfach nur Unsinn. Das Gegenteil ist der Fall, gut und leicht
lesbarer Quellcode, der ohne Kommentare auskommt, macht weit mehr Arbeit
als Kommentare zu schreiben. Man spart sich dabei etwas Tipparbeit, aber
wer dieses bisschen Tipperei als Umstand bezeichnet hat in der
Programmiererei sowieso nix verloren.
In gut selbstdokumentierendem Code hingegen gehen beide Arbeitsschritte
parallel ein. Das summiert sich nicht, sondern multipliziert sich
vielmehr.
Der Fehler ist schon vorher passiert indem es einen angeforderten Betrag
gibt der keine ganzen Cent enthält. Da ist es unsinnig hinterher
aufzuräumen anstatt den Fehler im Vorfeld anzupacken. Man denke nur
daran wenn später die Summe der Eingänge gegen die Summe der
Anforderungen gestellt wird und es da wieder Abweichungen gibt.
Ansonsten:
Der Vorteil hier ist, man kann beliebig tief in die Systematik
eintauchen und sieht nur soviel wie man sehen will. In erster Näherung
sieht man beim überfliegen nur eine Funktion die sich darum kümmert ob
ein angeforderter Betrag bezahlt wurde oder nicht. Wenn mich
interessiert wie die Funktion das genau macht, schau ich mir die an,
sonst nicht. Wenn ich mir dann die Funktion ansehe, erkenne ich das es
eine Differenz gibt innerhalb deren eine Abweichung zwischen bezahltem
Betrag und angefordertem Betrag zulässig ist und die was mit
Rundungsfehlern bei Paypal zu tun hat. Wenn es mich dann noch
interessiert, sehe ich noch wie groß diese Abweichung maximal sein darf.
Aber wie gesagt, der Fehler passiert schon im Vorfeld das es überhaupt
einen angeforderten Betrag gibt, der Bruchteile von Cent enthält.
Dieser Thread ist lustig... Bzw. er passt in ungeahnter Weise zu seinem
Titel. Anderen Leuten ihren Code zerpflücken, genau das macht ihr gerade
gegenseitig. Es gibt tausend Wege, eine Aufgabe programmtechnisch zu
lösen und alles was eurer Methode entspricht, wird als furchtbar
schlecht lesbar dargestellt. Und wisst ihr was? Genau das ist es auch.
Deswegen braucht man so viel Zeit, sich lästigerweise in fremden Code
einzulesen, vor allem wenn der nicht gut dokumentiert wurde.
Wir mussten übrigens früher(tm) sogar noch Ablaufdiagramme malen bevor
wir mit dem Programm anfangen durfen. Ich kann mich da noch gut an meine
"Lehrerin" erinnern... Da wir dieserzeit unter Strafandrohung kollektiv
gezwungen wurden, solchen Scheiß wie TurboPascal zu benutzen anstatt
einer brauchbaren echten Programmiersprache, bin ich diesen hässlichen
blinkenden DOS-Cursor nicht losgeworden. Ok, stimmt nicht, ich bin ihn
mit einem Bios-Funktionsaufruf per Inline-Assembler losgeworden (man
setzt ihn eine Zeile unterhalb des Bildschirm-Bereichs und weg ist er,
bzw. er ist schon noch da, aber man sieht ihn nicht mehr). Die tolle
Lehrerin hat mir einen großen roten Kringel an meine HideCursor-Funktion
gemacht und behauptet, ich würde den PC kaputtmachen. Super.
Nochwas:
> Der Vorteil hier ist [..]
... daß man dafür alleine zum Lesen deutlich mehr Arbeitszeit
verschwendet als bei anderen Varianten. Oder wenn man mal analysieren
würde, wieviel Zeit für das ständige Tippen so langer Variablennamen
draufgeht, plus die Zeit zum Beheben von Tippfehlern. Mir ist das schon
wieder zu übertrieben, kommt mir vor wie ein Wettbewerb, möglichst viel
Dokumentation in den Code zu implementieren. Kennt man auch von anderen
bloatigen Formaten wie z.B. XML. Da werden auch gerne kilometerlange
Bezeichner verwendet, wozu hat so'n Server schließlich 32 Cores,
irgendwie muß man die ja auslasten damit den CPUs nicht kalt wird.
Mladen G. schrieb:> Nebenbei, das ist ein altes Paradebeispiel für Objektorientierung:
Genau fas
Faher kommt der Schrott.
Und wer glaubt, Money wäre in cent auszudrücken, hat nie getankt ind
verdient kein Geld mit Eiderständen:
int Stueckzahl = 1000;
money ZahlBetrag = Stueckzahl * money(0.0015,CURR_EUR);
1000 x 0 ist leider 0.
MaWin schrieb:>> schreibe den auch mal um:> String paymentType=request.getCaseinsensitiveParameter("paymenttype")
Dieser Funktionsaufruf erklärt nicht, warum man hier ausnahmsweise
case insensitiv arbeitet.
MaWin schrieb:> int Stueckzahl = 1000;> money ZahlBetrag = Stueckzahl * money(0.0015,CURR_EUR);>> 1000 x 0 ist leider 0.
Wie ist ZahlBetrag den deklariert? Und wie sieht money aus? Mit diesem
Beispiel kann man gar nichts anfangen.
Wenn ich ein vernünftiges und aktuelles fachliches Konzept habe kann ich
i.d.R. auch die Umsetzung (mit sparsamen Kommentaren bei vernünftiger
Variablen-Deklarierung) nachvollziehen.
Ich dokumentiere sparsam und verweise an entsprechenden Stellen auf das
Fachkonzept bzw. den dort enthaltenen Anforderungen.
Wühlhase schrieb:> /* Löst das Problem, daß PayPal keine Bruchteile von Cents unterstützt> die> * durch die Märchensteuer zwangsläufig entstehen, siehe Ticket #777999.> * Die Methode liefert True zurück, falls die Differenz zwischen> bezahltem> * und angefordertem Betrag *noch innerhalb der Toleranz von einem Cent> * liegt. Andernfalls false.> */> boolean isInPayPalRoundingRange(bezahlt, angefordert){> return abs(bezahlt-angefordert) > 0.01;> }> //...> if (isInPayPalRoundingRange(bezahlt, angefordert) {> throw Exception;> }
Das solle im Fachkonzept stehen - und ich sehe im Coding dass max. 1
Cent Differenz bei Paypal O.K. ist - warum kommentieren?
Mal abgesehen davon, dass man den 1 Ct. ggf. in eine vom Kunden
parametrierbare Tabelle geben und von dort auslesen sollte.
Hugo H. schrieb:> Wie ist ZahlBetrag den deklariert? Und wie sieht money aus? Mit diesem> Beispiel kann man gar nichts anfangen.
Steht direkt drüber, als Kommentar zum code, offenbar helfen dir
Kommentare nicht weiter weil du sie nicht liest.
Stefan ⛄ F. schrieb:> Dieser Funktionsaufruf erklärt nicht, warum man hier ausnahmsweise case> insensitiv arbeitet.
Ich würde das nicht als ausnahmsweise annehmen, sondern
wannimmermöglich.
Hugo H. schrieb:> Das solle im Fachkonzept stehen - und ich sehe im Coding dass max. 1> Cent Differenz bei Paypal O.K. ist - warum kommentieren?
Der "Kommentar" ist das übliche Javadoc/Doxygen, das eine Methode bei
mir bekommt. Etwas schlampig, weil z.B. die Parameterbeschreibung fehlt,
aber das soll auch nur eine Andeutung sein. Es geht ja nicht um das
Javadoc, sondern um den Code – und der kommt ohne Kommentare aus, das
war ja Sinn und Zweck der Übung.
Javadoc betrachte ich als Dokumentation, aber nicht als (klassischen
Code-) Kommentar.
Oh je da habe ich mal wieder was angefangen, mit dem Kommentar.
selbsterklärenden Code: c=a+b
Und selbst das verlangt eigentlich schon nach einen Kommentar. Auch wenn
ich das dann oft schon übertrieben finde.
Aber das was ich meistens finde sieht so aus als hätte man alles durch
ein Kommentar Entferner geschickt und einen Lizenz Header reinkopiert.
So was habe ich gerade bei freertos gesehen (für welchen Prozessor ist
der Port denn?).
Naja kann ja jeder machen wie er selbst will solange das Projekt keinen
festgeschriebenen Stil fordert. Schließlich ist es sein Code, das muss
man nicht so kommentieren, daß das jeder DAP versteht. Meistens wird ja
vorgschrieben, wie man dokumentieren soll, manchmal ist das auch
komplett vom Code getrennt, dann schreib ich mir in den Code nur kurze
Reminder für mich selbst rein und den Rest in die Dokumentation.
Ansonsten probiere ich bei Funktionsnamen möglichst passende zu finden,
so daß man sich den Kommentar sparen kann.
1
function get_username(int $id) {
2
[imagine some cool sql stuff]
3
return $username
4
}
Wenn man das kommentiert oder großartig dokumentiert, bläst man nur den
Code auf und verbrennt Arbeitszeit.
Manchmal bekommt man bei kleinen Projekten auch direkt gesagt keine
Dokumentation, keine Kommentare, hier ist was es können muß, mach's in
kürzester Zeit fertig, egal wie.
Ben B. schrieb:> Manchmal bekommt man bei kleinen Projekten auch direkt gesagt keine> Dokumentation, keine Kommentare, hier ist was es können muß, mach's in> kürzester Zeit fertig, egal wie.
Nur bei kleinen Projekten? Der war gut!
MaWin schrieb:> Mladen G. schrieb:>> Nebenbei, das ist ein altes Paradebeispiel für Objektorientierung:>> Genau fas> Faher kommt der Schrott.>> Und wer glaubt, Money wäre in cent auszudrücken, hat nie getankt ind> verdient kein Geld mit Eiderständen:>> int Stueckzahl = 1000;> money ZahlBetrag = Stueckzahl * money(0.0015,CURR_EUR);>> 1000 x 0 ist leider 0.
Das habe ich doch schon erklärt, Skalare Typen wären hier richtig.
Solange du da mit floats rangehst, verlierst du Geld.
Wenn man sich zB. ansieht wie zB. Börsenkurse richtig übermittelt
werden, das sind dann Integer ;)
Den Faktor und die Auflösung bekommt man extra.
Ich hätte wohl kein Beispiel mit Geldbeträgen bringen sollen. Jetzt ist
die Diskussion heftig vom Thema weg gelaufen. Es ging doch bei meinem
Beispiel um die Kommentare im Code, nicht um die Datentypen.
Ben B. schrieb:> Wenn man das kommentiert oder großartig dokumentiert, bläst man nur den> Code auf und verbrennt Arbeitszeit.
Zukünftige Nutzer der Funktion würden sich hier über die Information
freuen, was im Fehlerfall passiert („returns string, or null if user is
not found“). Alternativ durch type hinting. Wenn nicht klar ist, führt
das zu Wildwuchs bei der Fehlerbehandlung, oder komplettes Ausbleiben
derselben. Gerade in PHP-Projekten sehr häufig beobachtet.
Mladen G. schrieb:> das sind dann Integer ;)> Den Faktor und die Auflösung bekommt man extra.
Sind Zahlen mit Faktor und Auflösung extra nicht floating-point?
Man muss überall annahmen und Grenzen setzen. Eine Steuer von mehr als 4
Mrd Dollar war halt lange undenkbar.
Ein Shopsystem für Deko Artikel stößt beim Warenkorb bis 4Mrd Cent wohl
kaum an seine Grenzen. Bis die Hyperinflation kommt.
Ben B. schrieb:> Wenn man das kommentiert oder großartig dokumentiert, bläst man nur den> Code auf und verbrennt Arbeitszeit.
Ich finde Kommentare nützlich, die das warum erklären, wenn sie den
Code nicht übermäßig aufblähen. Bei Ein-/Ausgabe Parametern habe ich
auch gerne Angaben ob null Werte erlaubt sind oder sonstige
Einschränkungen gelten, die nicht selbstverständlich sind.
Das Offensichtliche muss man nicht kommentieren. Umfangreiche Doku
platziert man besser woanders außerhalb des Quelltextes.
Da muss man bei PHP halt etwas aufpassen. Ich mag die Flexibilität durch
die lockere Typdeklaration von Variablen, aber man kann sich natürlich
auch Stolpersteine damit bauen (besonders mit der "0") und ich kann auch
verstehen, wenn manche das als unsicher(er) betrachten... ist aber nicht
Thema dieses Threads.
Man kann aber bei meinem Beispiel mit dem Benutzernamen auch ein
"echtes" false zurückgeben wenn was schiefgeht (z.B. ID nicht gefunden)
und darauf mit ===false testen.
Ben B. schrieb:> Ok, stimmt nicht, ich bin ihn> mit einem Bios-Funktionsaufruf per Inline-Assembler losgeworden (man> setzt ihn eine Zeile unterhalb des Bildschirm-Bereichs und weg ist er,> bzw. er ist schon noch da, aber man sieht ihn nicht mehr).
Das ist gräßlichster Hackerstyle at its best. Man kann den Kursor
natürlich per BIOS-Funktion abschalten und BIOS-Aufrufe in Turbopascal
gingen auch ohne Assembler. Gab da früher so Bücher "PC Intern".
Mladen G. schrieb:> Das habe ich doch schon erklärt, Skalare Typen wären hier richtig.
Das habe ich doch gerade gezeigt, skalare Typen taugen nicht bei
Währungen.
Issesdennsoschwer.
> Das ist gräßlichster Hackerstyle at its best.
Danke für das Kompliment.
Aber wenn Du ohne großen Aufwand kannst, zeige doch bitte mal Deine
Lösung für dieses Problem in DOS Turbo Pascal. Das würde mich auch 25
Jahre später noch interessieren, obs da tatsächlich eine "bessere"
Methode gab.
A. S. schrieb:> Mladen G. schrieb:>> das sind dann Integer ;)>> Den Faktor und die Auflösung bekommt man extra.>> Sind Zahlen mit Faktor und Auflösung extra nicht floating-point?
Floats sind halt nicht "abzählbar", deswegen Integers.
Das wird zB. so bei APIs gemacht die Aktien/Index/Future Kurse zu
übermitteln.
Floats gibt es da zwar auch bei einigen billigen sub-standard Providern,
gibt dann immer wieder Probleme..
Ben B. schrieb:> Aber wenn Du ohne großen Aufwand kannst, zeige doch bitte mal Deine> Lösung für dieses Problem in DOS Turbo Pascal.
Turbo-Pascal habe ich nur kurz zu DDR-Zeiten unter CP/M-86 benutzt.
Später habe ich in Turbo-C die UART-Register direkt zugegriffen, da
keine UART-Funktionen verfügbar waren. Der Witz ist, dieses Programm
funktioniert immer noch einwandfrei unter Windows10 in DOSBox an nem
USB-UART Umsetzer. Und bis WINDOWS-XP 32Bit lief es sogar noch direkt.
Erst mit 64Bit braucht man DOSBox.
Thomas Z. schrieb:> Ben B. schrieb:>> Lösung für dieses Problem in DOS Turbo Pascal.>> sowas in der Art (wilkürliches Beispiel um einen 0x2F Interrupt> aufzurufen)>
1
> regs.ah := $16;
2
> regs.al := $0a;
3
> regs.bx := 0;
4
> regs.cx := 0;
5
> regs.dx := 0;
6
> intr($2f, regs);
7
>
Dann doch direkt als richtiges Beispiel:
Cursor aus:
Peter D. schrieb:> Der Witz ist, dieses Programm funktioniert immer noch> einwandfrei unter Windows10 in DOSBox an nem USB-UART Umsetzer.
Erstaunlich, ich hätte nicht erwartet, das DOSBox sogar die UART
Register emuliert.
Stefan ⛄ F. schrieb:> das DOSBox sogar die UART> Register emuliert.
Man muß das in der dsobox-0.74-3.conf entsprechend einstellen, d.h. von
dummy oder disabled auf realport setzen:
serial1=dummy
#serial2=dummy
serial2=directserial realport:COM2
serial3=disabled
serial4=disabled
Thread beobachten
Seitenaufteilung abschalten