C#
Teilen:
Die Fragen zu C# wurden nur Entwickler*innen gestellt, die C# als eine ihrer drei primären Programmiersprachen angegeben hatten.
50%
–
C# 10 (dateibezogene Namensräume, globales using, Record-Structs, erweiterte Eigenschaftsmuster)
32%
30%
C# 9 (Records, Zieltyp-basiertes new, Top-Level-Anweisungen)
33%
50%
C# 8 (statische lokale Funktionen, Nullable-Referenztypen, Standard-Schnittstellenmethoden)
24%
39%
C# 7 (Pattern-Matching, lokale Funktionen, Ref-Rückgaben und lokale ref-Variablen, Out-Variablen)
16%
27%
C# 6 (die Operatoren ? und nameof, statische Importe, Ausnahmefilter, Roslyn)
5%
27%
C# 5 (async/await, Aufrufer-Informationsattribute)
2%
5%
Eine frühere Version
10%
12%
Ich bin mir nicht sicher
Da der Wechsel vom .NET-Framework zu .NET in der Regel nicht mit einer einfachen Änderung des Kompilierungsziels getan ist, ist es interessant, dass die meisten Entwickler*innen zumindest bei .NET (Core) mit dabei sind. Gleichzeitig ist es erstaunlich, dass ein erheblicher Prozentsatz der Entwickler*innen immer noch Projekte für .NET Framework 4.6 und früher wartet. Ich möchte gerne wissen, was diese Projekte vom Umstieg auf 4.8 abhält.
Dennis Dietrich
Senior-Softwareentwickler, Azure Storage, Microsoft
Ich halte es für gut, dass mehr Entwickler*innen die neueste C#-Version verwenden. Ich frage mich, ob sie alte Anwendungen zunehmend auf die neueste .NET-Version umstellen oder nur neue Anwendungen und Systeme entwickeln und den alten Code einmotten.
Chris Woodruff
Teamleiter, Engineering, Rocket Homes
C#
HTML/CSS
JavaScript
TypeScript
VB.NET
F#
Sonstige
49%
62%
.NET-Framework
47%
–
.NET 6
43%
66%
.NET Core
24%
33%
.NET 5
10%
12%
Mono
5%
–
Ich bin mir nicht sicher
C#-Entwickler*innen nutzen das .NET-Framework und .NET Core deutlich weniger als im vergangenen Jahr (minus 13 bzw. 23 Prozentpunkte).
56%
55%
ASP.NET Core
41%
42%
Entity Framework
25%
20%
Azure
24%
28%
Windows Forms
22%
19%
Unity
54%
62%
65%
Visual Studio
33%
27%
20%
JetBrains Rider
10%
9%
11%
VS Code
2%
2%
2%
Visual Studio für Mac
1%
1%
0%
Sonstige
In den letzten 3 Jahren ist die Verwendung von JetBrains Rider unter C#-Entwickler*innen von 20% auf 33% gestiegen.
Ich bin nicht überrascht über die Verbreitungsgeschwindigkeit von Rider, wenn ich sie mit seinem Siegeszug in meinem Team vergleiche. Anfang des vergangenen Jahres verwendete es die Hälfte des Teams, heute verwendet es das gesamte Team.
Laurent Kempé
Teamleiter und Distinguished Solution Architect, Innoveo
Windows
macOS
Linux
39%
37%
xUnit
38%
37%
NUnit
14%
19%
MSTest/Visual Studio Unit Testing Framework
9%
8%
MSTest V2
Als ehemaliger SDET finde ich den Prozentsatz der C#-Entwickler*innen, die keine Unit-Tests schreiben, enttäuschend. Ich hatte gehofft, dass es inzwischen einen Konsens über die allgemeinen Vorteile von Unit-Tests geben würde. Es wäre interessant, den Grund dafür zu erfahren. Sind die Entwickler*innen nicht vom Nutzen überzeugt? Liegt es an einem Mangel an Ausbildung oder Entwicklungskultur? Gibt es Widerstand im Management gegen die kurzfristigen Investitionen, die Unit-Tests erfordern?
Dennis Dietrich
Senior-Softwareentwickler, Azure Storage, Microsoft
Wenn ich auf meine 20 Jahre in diesem Bereich zurückblicke und meine persönlichen Erfahrungen mit den Zahlen hier vergleiche, komme ich unweigerlich zum Schluss, dass die Leistungsanalyse und -verbesserung heute oft ein blinder Fleck ist, obwohl das eigentlich nicht sein dürfte. In vielerlei Hinsicht hat sich der Kreis geschlossen. Während es früher um begrenzte Arbeitsspeicher- und CPU-Ressourcen ging, schreiben wir heute routinemäßig Code für Mobilgeräte, bei denen die Akkulaufzeit ein Problem ist, sowie Cloud-Lösungen, die skalierbar sein müssen und wo eine ineffiziente Nutzung der Rechenressourcen leicht dazu führt, dass jeden Monat Tausende Dollar an vermeidbaren Mehrkosten entstehen.
Dennis Dietrich
Senior-Softwareentwickler, Azure Storage, Microsoft
74%
77%
Hin und wieder, wenn Probleme auftreten
19%
15%
Regelmäßig – jeden Tag/jede Woche/für jeden Sprint, um Probleme frühzeitig zu erkennen
6%
8%
Ständig – als fortlaufenden Hintergrundprozess
1%
0%
Sonstige
Bei vielen Entwickler*innen hat sich herumgesprochen, dass Profiler eher zur Vermeidung von Leistungsproblemen als zur Behebung ihrer Symptome da sind. Der Anteil dieser Entwickler*innen ist in diesem Jahr gestiegen, aber von einem nachhaltigen Trend können wir noch nicht sprechen.

Ich glaube, dass beim regelmäßigen Profiling die Idee der Zinseszinsen maßgeblich ist. Wie wir das bei der Altersvorsorge kennen: Wir sparen im Zeitverlauf kontinuierlich kleine Beträge an, bis wir schließlich einen Punkt erreichen, an dem wir eine bedeutende Summe besitzen. Dasselbe gilt für das Profiling: Selbst wenn wir nur einen winzigen Teil unserer Zeit in Performance-Auswertungen stecken, führt dies zu großen Verbesserungen auf breiter Front, wenn wir konsequent und beharrlich sind. Ich versuche daher nicht, riesige, massive Verbesserungen auf einmal zu erzielen. Wenn wir Iteration für Iteration vorankommen, ist das Ergebnis hervorragend.
Dylan Moonfire
Senior-Softwareentwickler, @dmoonfire
Ich und einige andere Entwickler*innen
Nur ich
Alle Entwickler*innen in unserem Projekt
Niemand in unserem Projekt
Sonstige
39%
38%
Websites
37%
35%
Hilfsprogramme (kleine Apps für kleine Aufgaben)
28%
20%
Systemsoftware
25%
18%
Datenbanken/Datenspeicherung
JetBrains Rider wird bevorzugt, wenn es um Game-Entwicklung (+18 Prozentpunkte gegenüber Visual Studio), Unterhaltung (+4 Prozentpunkte) oder Augmented/Virtual Reality (+4 Prozentpunkte) geht.
Danke, dass Sie sich die Zeit genommen haben!
Wir hoffen, dass Sie unseren Bericht nützlich fanden. Teilen Sie diesen Bericht im Freundes- und Kollegenkreis.
Wenn Sie Fragen oder Anregungen haben, schreiben Sie uns bitte unter surveys@jetbrains.com.