im geschützten Speicher zu lesen oder zu schreiben
Funktioniert der ursprüngliche C/C++-Code wie angedacht ? Wobei ein C oder C++ - Compiler (zumindest zur Kompilierzeit) idR ein liberaleres Verhältnis zum Manipulieren von Speicherinhalten hat.
Längerfristig sollte man (häufige(re)) Änderungen/Erweiterungen/Wartbarkeit/... des Codes einplanen (deswegen auch die bereits genannte Schichtentrennung: um genau diese Aktionen (an einer (zentralen) Stelle) zu erleichtern). Um mehrere Controls anzusprechen gibt es auch einen Artikel: FAQ - Variablennmen zur Laufzeit...
Prinzipiell geht so etwas, Stichwort z.B. "Web Scraping"
Es kann aber (z.B.) sein das die Zielseite Schutzmechanismen gegen zuviele Anfragen (pro Zeiteinheit) aktiviert hat oder Hintergrundinformationen geliefert werden wollen (die _nur_ ein richtiger Browser mitgibt)
Man sollte -auch auf Vorrat- davon ausgehen, dass sich die externen wie internen Laufzeitbedingungen eines Programms (öfter(s)) ändern können (z.B. könnte man das Vorhandensein einer Registry oder bestimmter Äste dort im Vorab abfragen). Ansonsten besteht eine weitere Gefahr von "Pain Driven Development" (Anspielung auf das neuste YT-Video von D. Tielke)
Längerfristig sollte man empfohlene menschliche Verhaltensweisen -die das (häufige(re)) Ändern/Erweitern/Nutzen/Pflegen/... (an zentraler Stelle) der Software erleichtern- wie (z.B.) Namespaces, Namenskonventionen, SOLID-Prinzipien ("encapsulate what varies"), Aufteilung in Schichten, Versionsverwaltung, "pro Klasse eine Aufgabe", Dokumentation, TDD, Architektur,... beachten. Mit zunehmender Menge an Akteur:innen kommen weiterhin Stichworte wie (z.B.) Scrum, Kanban, "Code-Ownership", "mit Leuten reden",... ins Spiel.
Die SOLID-Prinzipien könnte man noch recherchieren. Die bereits genannten Stichwörter stellen bekannte Bearbeitsmöglichkeiten dar, deren Vor- und Nachteile man kennt (oder kennen sollte). Ein Vorteil besteht aus menschlicher Sicht im einfacheren Ändern/Erweitern/Nutzen/... des Codes (an einer Stelle)
In C# ist alles (Methoden, Variablen,...) zwingend innerhalb einer Klasse zu defnieren. Mehrfachvererbung gibt es nicht und vermeidet das "diamond problem".
WIE der damalige Autor auf den Code gekommen ist (trial and error, Doku gelesen,...) wird sich wohl kaum rekonstruieren lassen. Deswegen machen sinnvolle Namensgebungen Sinn: um das Ändern/Erweitern/Nutzen/... eines Codes/ einer API/... zu erleichtern. Eine gute und aktuelle Dokumentation mitzuliefern ("Read the fine manual") ist trotzdem nicht falsch: Twiiter-Thread von RapidAPI
Teil II, um die gröbsten Fehler nach Möglichkeit zu verhindern:
--aus technischer Sicht interessiert den Compiler nur das formell korrekter Code geschrieben wird (zur Not zwingt einen der Compiler mittels Warn- oder Fehlermeldungen zu diesem Verhalten). "Formell korrekt" im Minimalfall: -alle Methoden/Variablen/... sind auf jeden Fall innerhalb einer Klasse zu definieren(*), -eine cs.-Datei des Projekts enthält eine "static void Main"-Methode(*), -Datentypsicherheit ist einzuhalten
(*)neuere .NET Versionen könnten liberaler sein und diese Anforderungen in den Hintergrund rücken lassen
--aus menschlicher Sicht machen diese (empfohlenen) Verhaltensweisen Sinn:
-Code Conventions (erleichtert das Lesen/Schreiben von Code)
-Aufteilung in Schichten, s.a. Drei-Schichten-Architektur (macht effektiv Sinn, wenn die SW an einer (zentralen) Stelle (häufig(er)) geändert oder erweitert werden soll) Generell erleichtert die korrekte Anwendung des "Teile-und-Herrsche"-Prinzips das Erweitern oder Ändern einer Software.
-weitere Stichwörter: Verwendung von SW-Tests / Algorithmen / Datenstrukturen...
Auf Vorrat (da DB-Anbindung): [Artikelserie] SQL-Befehle:... (macht Sinn, wenn man Daten manipulierenden Angreifern/Nutzern/... nicht "Tür und Tor" offen halten will)
Fehlerhafte (i.S. von nicht vertrauenswürdige) Software kann man sich aber auf jedem Weg einhandeln (Anspielung auf Youtube, "thenativeweb", "Achtung! npm ist unsicher (by Design …))
Grundsätzlich gibt es bei jeder Programmiersprache eine formalisierte Menge an Schlüsselwörtern auf die der Compiler / Interpreter / Transpiler (Bspl.: TypeScript) /... in einer vorgesehenen Art und Weise reagiert. Diese Schlüsselworte lassen sich x-beliebig kombinieren, führen aber eben nicht immer zum Erfolg und werden mit Warnungen oder Fehlermeldungen quittiert. Z.B. schlägt die Kombination "abstract class" i.V. mit "final" fehl.
Den Compiler / Interpreter /... selbst interessiert nur die formelle (nicht dessen logische) Korrektheit des Codes.
Auf Vorrat: C# erzwingt die Verwendung von Klassen zum Definieren von Variablen und Methoden. Datentypsicherheit wird auch streng gehandhabt: FAQ - Variablennamen zur Laufzeit...
Zusätzlich: im Endeffekt ist der verwendete C#-Compiler die entscheidende Instanz was formal(*) korrekten Code, Implementierungs-Möglichkeiten oder Magie im Hintergrund betrifft. Verhaltensweisen wie "Clean Code" oder "Aufteilung in Schichten" dienen dem Menschen, erleichtern aber das Ändern oder Erweitern eines Softwareprodukts. Und mit (tendenziell) zunehmender Menge an Code ist der Einsatz einer Versionsverwaltung (Git, (veraltet) Subversion, (veraltet) CVS,... ) anzuraten.
Das sind Methodennamen, und wie jede Methode beinhalten sie eine Teilmenge elementarer Befehle. Wobei "get" und "set" vom Compiler gesondert behandelt werden (im Ggs. zu anderen Bezeichnungen).
{ get; set; }
ist übrigens eine valide Kurzschreibweise, wenn _nur_ Werte gelesen oder gesetzt werden sollen.
Klassen dienen zum Herstellen von Zusammenhängen zwischen Methoden und Objekten (1). Eine statische Methode oder Variable soll diese Eigenschaft aber gerade nicht erfüllen (auch wenn der C#-Compiler eine formelle Definition innerhalb einer Klasse erwartet (2)).
(1)youtube.com, Kanal "thenativeweb", "Warum OOP (objektorientierte Programmierung) überbewertet ist" (ab 3:03) (tendenziell religiöse Ansichten...)
(2)youtube.com, Kanal "thenativeweb", "5 Gründe, warum C# Murks (und nicht mehr so ganz zeitgemäß) ist" (ab 13:14 oder 14:49) (auch tendenziell religiöse Ansichten...)
Zusatz: bei graphischer Programmierung können auch passende Bibliotheken und Möglichkeiten der Grafikkarte (GPU) genutzt werden. Sinn und Zweck der (parallelen) Berechnungen wird der Rechner aber auch nicht kritisieren.
Zusatz:
AntMe verwendet eine mittlerweile veraltete .NET Version inkl. IDE, XNA wird auch nicht mehr weiterentwickelt (Vorteil: es gibt (wohl) keine beachtenswerten Änderungen/Erweiterungen mehr)
Die aktuellste Ausgabe von Schrödinger (Rheinwerk Verlag) stammt von 2019 (C# 8)