[Programmiererstammtisch] "Zum ächzenden Compiler"

[Mongke Khan]

Der heilige Gral sind Tests aber auch nicht. Das Programm ist dann nur so gut, wie die Tests, man hat aber mehr Code, der maintainet und bei Änderungen adaptiert werden muss.

Vor Jahren hatte ich mich mal mit Papern zu "modernen" SE-Praktiken (TDD, PP, Reviews, ...) beschäftigt. Das Ergebnis ließ sich runterbrechen auf: sobald in irgendeiner Weise zweimal über den Code geguckt wird (zwei Programmierer gleichzeitig beim PP, nacheinander bei Reviews, durch einen selbst beim Vorher-/Nachher-Testen oder Prototypen), nimmt die Qualität signifikant zu. Mehr als zwei lohnt sich idR finanziell für den Auftraggeber nicht. Weniger als zwei führt zu schlecht wartbarem Code. Das Schöne an der Erkenntnis ist, dass man sich selbst aussuchen kann, welche Methode man bevorzugt (ich kann TDD und PP nicht viel abgewinnen, aber prototype gerne)

[slowcar]

Ist ganz normal, dass man direkt mit Code schreiben anfangen will. An der Uni lernt man dann, dass die Plaung und Modellierung üblicherweise länger dauern als das Code schreiben.
Bis zu einer gewissen Komplexität kann man sich das auch im Kopf zusammenbauen, dann braucht man irgendwann Notizen, und später dann Modellierungs-Tools.
Wenn man auf halbem Weg merkt, dass das ganze Konzept doch nicht passt, muss man viel wegwerfen. Und noch schlimmer wird es, wenn man sich ergebene Anforderungen in die ursprünglich ausgedachte Lösung ranfrickelt.

Ich bin z.B. Fan des comment-driven development: Man schreibt (bei komplexeren Methoden) zuerst Kommentare, dann erst den Code. Da fällt einem zwischendurch oft schon auf, wenn man falsch abbiegt. Und ist deutlich einfacher als Modellierung.

Unittests braucht es nicht immer, aber sie erhöhen die Wartbarkeit und verringern die Fehlerhäufigkeit. Je komplexer das Projekt wird, desto größer wird der gesparte Aufwand. Und test-driven development spart einem das nachträgliche (und nervige) erstellen von Tests.

Statische Analysetools sind auch hilfreich. Wir setzen z.B. Sonarqube ein, das ist in das Buildmanagement via Gitlab integriert. Bei Stilfragen ist das so ne Sache, aber potentielle Sicherheitslücken erkennt es sehr zuverlässig.
Es kommt auch immer mal wieder ein Kunde, der irgendwelche anderen Analysetools auf unsere Software losgelassen hat, und für bestimmte Szenarien müssen wir auch durch eine Veracode-Zertifizierung.

[Schlumpf]

In dem zentralen Codegerüst von dem Projekt in das ich mich einarbeiten muss, wurde nicht eine Zeile Kommentar oder auch nur ein Wort Dokumentation geschrieben!
Was ist das für ein Müll!

[Harleen]

Das ist selbstkommentierender Code. Der ist so einfach geschrieben, dass man den auch ohne Doku versteht. Mach ich auch so.

[Snup]

Das ist selbstkommentierender Code. Der ist so einfach geschrieben, dass man den auch ohne Doku versteht. Mach ich auch so.

[alpha civ]

In dem zentralen Codegerüst von dem Projekt in das ich mich einarbeiten muss, wurde nicht eine Zeile Kommentar oder auch nur ein Wort Dokumentation geschrieben!
Was ist das für ein Müll!

Ich frage mal ganz naiv, gibt es denn wenistens Tests?

[Schlumpf]

Das ist selbstkommentierender Code. Der ist so einfach geschrieben, dass man den auch ohne Doku versteht. Mach ich auch so.

Ich frage mal ganz naiv, gibt es denn wenistens Tests?

Es gibt ein Beispielskript das ein Ergebnis erzeugt.
Von Namen her würde ich annehmen dass ein Spaziergänger getrackt wird (geht um Radare).
Wie man das Ergebnis interpretieren soll bleibt wohl dem Anweder wohl als Übung überlassen.

[nordstern]

Wie kann ich in Excel eine Zeitangabe von hundertstel Sekunden so formatieren das er mir nur noch Sekunden anzeigt. Da er nur alle 2sec die Daten erhoben hat, ist diese genaue Angabe nicht erforderlich und schadet bei Diagrammen nur der Übersicht.

Zudem hat Excel die Daten von CSV zu xlsx automatisch als Datum formatiert statt %. Wie kann ich das Rückgängig machen? Manuell kommen dann absurd hohe Zahlen raus, geht also nicht. Da er nicht z.b. 17.5 als 17,5% umrechnet sondern 17.5.21 zurückrechnet auf 1.1.1900 und das als Zahl ausgibt mit %.


Ich will anfangen Programmieren zu können. In erster linie erstmal Makros für Excel, später dann mehr. Also dachte ich mit VBA anzufangen, also VB ist ne gute Idee. Wie fange ich da am besten an? Später wollte ich Richtung C++ gehen oder so. Da ich so n paar Ideen hätte was ich mir gerne schreiben würde um Prozesse zu vereinfachen.

[Flunky]

Excel kann nur entweder . (Englische Version) oder , als Dezimaltrennzeichen. Du solltest also in deiner csv-Datei mit einem anderen Editor die Punkte durch Kommas ersetzen.

Zum Programmieren lernen ist Excel aber zumindest schräg.

[Snup]

Hab hier kein Excel, um genau nachzugucken, aber beim 1. gibts doch bestimmt ein Format, dass das schon macht. Ansonsten bilde ich mir ein, dass man auch Formate bearbeiten kann.

[nordstern]

Ich habe Excel so umgestellt das es im englischen Format öffnet. Kann man einstellen. Hat aber irgendwie das Problem nicht gelöst. Er rechnet die prozente immer noch falsch um, diesmal um den Faktor 10. Er macht aus 17.5 nun 175 statt den 17.Mai

[El Cattivo]

Als was ist die Zelle denn überhaupt formatiert?
Screenshots und Excel-Version könnten helfen.

Zumal Datumsangaben ohne Jahreszahl eh nicht alle Möglichkeiten einer korrekten Datumsfunktion haben.

[Gullix]

...also, hachja, Excel und die "alles ist ein Datum"-Krankheit.

[Ausgetreten]

...also, hachja, Excel und die "alles ist ein Datum"-Krankheit.

Dafür mussten selbst schon Gene umbenannt werden

[Gullix]

...also, ja, das war schon geil. Ich bin ja auch ein Fan von Pragmatismus, wenn man mit einer Maßnahme ein Problem wegmachen kann und mit einer anderen nicht, dann ist die eine besser. Aber das wird schon auf eine harte Probe gestellt, vor allem wenn man sich die "Argumente" der Pro-Excel-Fraktion anhört. Man muss doch nur (dreiseitige Anleitung) und schon wird das korrekt erkannt, und überhaupt ist Excel nicht dafür verantwortlich wenn Leute es falsch benutzen.