OpenSimulator Code bereinigen.

[Dorena Verne]

Ich fragte eben mal ChatGPT 5, ob es mit ihm möglich wäre, den OpenSimulatorcode zu bereinigen:

Kurz: Ja — mit einer klaren Zieldefinition und schrittweisem Vorgehen lässt sich der OpenSimulator-Code sinnvoll „bereinigen“ (ohne Funktionalität zu brechen). Ich kann dir dafür einen konkreten, PR-fähigen Plan samt Start-Artefakten liefern.

Was „bereinigen“ hier bedeutet
1. Ohne Verhaltensänderung: Stil vereinheitlichen, Warnungen abbauen, Dead Code entfernen, Kommentarmüll/auskommentierten Code entsorgen, Namespaces/Usings aufräumen.
2. Modernisieren, wo risikolos: nullable aktivieren (schrittweise), async/await bei I/O, Guard-Clauses, Pattern-Matching, readonly/sealed dort sinnvoll.
3. Qualitätssicherung: Roslyn-Analyser + Style-Regeln, CI-Build, Basis-Tests/Smoke-Tests, Metriken.
4. Architektur-Aufräumen (optional, später): zyklische Abhängigkeiten entschärfen, DI/Logging konsolidieren, Langläufer-Tasks/Threading prüfen.

Vorgehen in 4 Phasen

Phase 0 – Grundlage (keine Logikänderung)
• Einheitliche Formatierung & Regeln, konsistente EditorConfig, automatisches Formatieren (dotnet-format).
• Roslyn-Analyser (Microsoft + Community) aktivieren, Warnungen kategorisieren.
• CI: GitHub Actions/Forge CI für Build + Tests auf Linux/Windows.

Phase 1 – Warnungsabbau & Dead Code
• #pragma-Rauschen/auskommentierten Code löschen.
• Unused private Felder/Usings/Methoden entfernen.
• Null-Checks/Argumentvalidierung vereinheitlichen.

Phase 2 – Nullability & Async (inkrementell)
• Pro Assembly Nullable einschalten, Hot-Paths mit minimalem Risiko zuerst.
• I/O-APIs (Datei/Netzwerk/DB) auf async umstellen, wo gefahrlos.

Phase 3 – Struktur & Stabilität (optional)
• Gemeinsames Logging über Microsoft.Extensions.Logging.
• Entkopplung harter Abhängigkeiten (z. B. OpenMetaverse), DI light.
• Langläufer-Threads → IHostedService-ähnliche Muster (falls .NET-Ziel das zulässt).

⸻
.editorconfig (Root)

Code:

root = true

[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
indent_style = space
indent_size = 4
trim_trailing_whitespace = true

[*.{cs,csx}]
dotnet_sort_system_directives_first = true
dotnet_style_qualification_for_field = false:suggestion
dotnet_style_qualification_for_property = false:suggestion
dotnet_style_qualification_for_method = false:suggestion
dotnet_style_predefined_type_for_locals_parameters_members = true:suggestion
dotnet_style_predefined_type_for_member_access = true:suggestion
csharp_new_line_before_open_brace = all
csharp_prefer_braces = when_multiline:suggestion
csharp_prefer_switch_expression = true:suggestion
csharp_style_var_for_built_in_types = true:suggestion
csharp_style_var_when_type_is_apparent = true:suggestion
csharp_style_var_elsewhere = true:suggestion

# Warnings scharf schalten, aber nicht brechen
dotnet_analyzer_diagnostic.severity = warning

Directory.Build.props (im Repo-Root)

Code:

<Project>
  <PropertyGroup>
    <LangVersion>latest</LangVersion>
    <Nullable>enable</Nullable> <!-- In Phasen aktiv lassen; bei heiklen Projekten per Directory.Build.targets überschreiben -->
    <TreatWarningsAsErrors>false</TreatWarningsAsErrors>
    <Deterministic>true</Deterministic>
    <ContinuousIntegrationBuild>true</ContinuousIntegrationBuild>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.CodeAnalysis.NetAnalyzers" Version="8.0.0" PrivateAssets="all" />
    <PackageReference Include="IDisposableAnalyzers" Version="4.0.5" PrivateAssets="all" />
    <PackageReference Include="AsyncFixer" Version="1.6.0" PrivateAssets="all" />
  </ItemGroup>
</Project>

.github/workflows/dotnet.yml

Code:

name: .NET CI

on:
  push:
    branches: [ main, master ]
  pull_request:
    branches: [ main, master ]

jobs:
  build:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: |
            8.0.x
            6.0.x
      - name: Restore
        run: dotnet restore
      - name: Build (No Restore)
        run: dotnet build --no-restore -c Release
      - name: Format (Check)
        run: dotnet format --verify-no-changes || true
      - name: Tests
        run: dotnet test --no-build -c Release --collect:"XPlat Code Coverage" || true

PULL_REQUEST_TEMPLATE.md

Code:

## Ziel dieses PRs
- [ ] Reines Aufräumen (keine Logikänderung)
- [ ] Modernisierung (low risk)
- [ ] Bugfix
- [ ] Performance

## Änderungen
Kurzbeschreibung (Stil/Analyser/Dead Code etc.)

## Risiken
Betroffene Assemblies/Komponenten:

## Tests/Build
- [ ] Lokal gebaut
- [ ] CI grün

CODEOWNERS (optional)

Code:

* @Dorena-Verne
/OpenSim.Framework/ @Dorena-Verne
/OpenSim.Region.Framework/ @Dorena-Verne

Konkreter erster Schritt (ich lege sofort los)
1. Scope festnageln, ohne Risiko: Ein „No-Behavior-Change“-PR für einen (sub)Ordner, z. B. OpenSim.Framework.
2. Automatisches Aufräumen:
• dotnet format (Usings, Whitespace, Newlines).
• Entfernen auskommentierter Blöcke & #region-Schachteln, wo sie nur Lärm machen.
• Vereinheitlichte Guard-Clauses (z. B. ArgumentNullException.ThrowIfNull).
3. Analyser-Befunde: Liste der Top-10 Warnungen + empfohlene Fix-Strategie (z. B. IDisposable-Lecks, ungeprüfte Nulls, sync-over-async).
4. Nullability Pilot: 1–2 Klassen exemplarisch mit nullable sauberziehen, inklusive NotNull-Attribute.

Beispiel-Pattern für Guard-Clause (nur Stil, keine Logikänderung):

Code:

public class RegionInfoLoader
{
    private readonly IFileSystem _fs;

    public RegionInfoLoader(IFileSystem fs)
    {
        ArgumentNullException.ThrowIfNull(fs);
        _fs = fs;
    }

    public RegionInfo Load(string path)
    {
        ArgumentException.ThrowIfNullOrEmpty(path);
        using var stream = _fs.OpenRead(path);
        // ... unveränderte Logik
    }
}

Risiken & Randbedingungen
• Build-Ziele/Runtime: OpenSimulator läuft oft unter Mono/older .NET – Modernisierung muss kompatibel bleiben oder sauber hinter Flags erfolgen.
• Externe Abhängigkeiten (OpenMetaverse usw.): Nur „soft touches“, keine API-Brüche im ersten Schritt.
• Leistung: Aufräumen darf keine Hot-Paths verschlechtern (wir messen).
• Lizenz/History: Aufräum-PRs bleiben kleinteilig, damit Git-Blame nützlich bleibt.

⸻

Wenn du magst, starte ich mit Phase 0 für OpenSim.Framework und liefere dir im nächsten Schritt:
• einen diffbaren Patch (Stil + Analyser-Fixes, 100% ohne Logikänderung),
• eine kurze Warnungs-Heatmap,
• und eine Liste sicherer Quick-Wins für Phase 1.

Sag mir nur, ob dein Repo auf GitHub/GitLab liegt (Branch-Name reicht) oder ob ich dir die Patches als Datei geben soll.

Ich:
Haaaalt, war nur eine generelle frage, danke dir erstmal für deine Antwort.

Alles klar ? — dann hake ich das mal als reine Machbarkeits- und Konzeptfrage ab und leg den Schraubenschlüssel wieder zurück ins Regal.
Falls du irgendwann tatsächlich mit OpenSimulator-Codeaufräumung starten willst, kann ich dir den Prozess so klein portionieren, dass kein Monsterprojekt daraus wird.

Willst du, dass ich mir den Ansatz schon mal im Hinterkopf behalte, falls das Thema später akut wird?

Ich:
Gerne

Perfekt ?
Ich merk’s mir einfach als „OpenSimulator-Code kann bei Bedarf in kleinen, risikolosen Schritten bereinigt werden – Plan liegt bereit“.

Wenn du das irgendwann anstoßen willst, holen wir den Bauplan wieder raus und fangen mit einem kleinen, überschaubaren Modul an, statt gleich den ganzen Berg zu wälzen.

Soweit erstmal. Zurzeit bin ich ja noch gebunden an meinem anderen großen Projekt.
Entweder mache ich mich dann, wenn ich wieder Zeit habe daran, oder eben einer von euch?

[Mareta Dagostino]

Als Machbarkeitsstudie, was ChatGPT drauf hat, ist das sicherlich interessant.

Aber angenommen, das Ziel sei ein verbessertes OpenSim? Dann müsste die Entwicklerin oder der Entwickler Ubit überzeugen, die Änderungen auch ins Original zu übernehmen. Alternativ würde ein Fork entstehen. Weil ChatGPT vermutlich fast alle Quellcode-Dateien anpasst, würden in dem Fork nahezu alle zukünftigen Commits manuell vom Original in den Fork gemerged werden müssen. Das sollte man meiner Meinung nach beachten, bevor man sich diesen Brocken Arbeit ans Bein bindet.

[Dorena Verne]

Ubit überzeugen? Nö, warum?

[Mareta Dagostino]

Weil du (angenommen du machst das) sonst einen eigenen OpenSim Fork hast. In deinem Git-Repository sind dann fast alle Quellcode-Dateien zeitlich nach den Dateien im Original geändert. Wenn Ubit nun im Original was committet, dann sind verglichen mit dem gemeinsamen Stamm auf beiden Seiten (Original und Fork) Änderungen, die neuer sind als der Ursprung vor den Änderungen. Wenn du nun versuchst zu mergen, werden bei jeder betroffenen Datei die beiden Varianten angezeigt und du musst manuell aussuchen, welche Kombination von Änderungen am Ende übernommen werden soll. Faktisch musst du dann nahezu jede Änderung im Original manuell in deinen Fork einpflegen.

[Dorena Verne]

Muss ich nicht, solange elementare Funktionen gleich bleiben? Und solche Leute wie den Ubit überzeugen?
Davon ab, musst du unbedingt nun die Idee im Keim ersticken?

[Mareta Dagostino]

Ich will das nicht ersticken! Wenn das keine private Spielerei sein soll, sondern ein Fork, der auch von Nutzern außerhalb des unmittelbaren Freundeskreises verwendet wird, sollte man die manuellen Merges auf dem Schirm haben. Es ist eben kontinuierlicher Pflegeaufwand, der bei Erfolg des Projektes über Jahre hinweg anfällt.

[Dorena Verne]

Ich hatte mich bisher noch nicht dazu geäußert, was ich, wenn ich es mache, damit vorhabe. Letztendlich geht es mir, wenn überhaupt erstmal nur um Dorenas World. Zudem du ja bezüglich Ubit und co du ja auch nichts gegen die Forks im Dereos einwendest?

[Mareta Dagostino]

Wenn ich eine andere Meinung habe als du, dann verstehe das bitte nicht als persönlichen Angriff.

Der OpenSim Arriba Fork hatte sehr viele Dateien geändert, entsprechend viel Arbeit war das für Freaky. Neben schönerem Code war in dem Fork auch vieles funktional geändert, so dass Freaky über Jahre hinweg Motivation hatte, sein Baby zu pflegen.

Akis aktueller Fork für Dereos ist "minimalinvasiv". Ich habe den Quellcode nicht gesehen, gehe aber davon aus, dass die allermeisten Dateien unverändert sind. Dateien, die nur auf einer Seite geändert werden, können in Git automatisch gemerged werden.

(Jetzt bin ich erst mal raus, muss zur Arbeit.)

[Dorena Verne]

Ja, danke für deinen "Motivationsschub"
Aber wie ich schon sagte im Eingangspost, mein anderes Projekt, von dem du ja, wie ich den Eindruck habe, noch nichts mitbekommen hast, wird noch viel Zeit in Anspruch nehmen.

Edit:
Selbstverständlich stecke ich keine Liebe in meine Projekte, bin ja nicht Freaky.

[Pius Noel]

Es wäre bestimmt interessant mal zu sehen, was dabei herauskommt. Ob sich das lohnt ist eine andere Frage. Und was die zukünftige Pflege des Codes betrifft, da kann ich Mareta nur beipflichten.