Proszę o odpowiedzi na pytania, skierowane do osób, które używają już .NET 8 i C# 12 w projektach.
1. Czy używacie Primary Constructors w swoich klasach?
public sealed class Foo(Bar bar) { ... } 2. Czy dotyczy to również klas ze wstrzykiwanymi zależnościami?
public sealed class Foo { private ILogger<Foo> logger; public Foo(ILogger<Foo> logger) { this.logger = logger; } }
do:
public sealed class Foo(ILogger<Foo> logger) { } 3. Czy oznaczacie pola (fields) modyfikatorem 'readonly' w klasach z DI? 4. Jeżeli odpowiedzieliście TAK na pytanie 2 i 3, czy zachowujecie ten modyfikator również w przypadkach klas z Primary Constructorem?
public sealed class Foo { private readonly ILogger<Foo> logger; public Foo(ILogger<Foo> logger) { this.logger = logger; } }
do:
public sealed class Foo(ILogger<Foo> logger) { private readonly ILogger<Foo> logger = logger; } 5. Czy używacie w ogóle polskich nazw w Polskich firmach w odniesieniu do konceptów w C#/.NET, czy po prostu: DI, readonly, fields, property, primary constructor, service container?
Kiedyś mnie bardzo irytował kod z tymi nudnym konstruktora mi i listą pół. Ale to przeszkadza tylko na samym początku istnienia projektu, czyli niedługo.
Uważam, że ten ficzer przynosi więcej szkody, niż pożytku.
@Hektorrr: 1. Generalnie nie, chociaż głównie po prostu dlatego, że nie lubię tego feature'a w przypadku klas, poza tym nie widzę sensu wprowadzania niespójności do kodu. Jeden czy dwa primary constructory mogły się gdzieś pojawić, ale to jedynie w rzadkich przypadkach klas, które pełnią bardzo konkretną funkcję. Zresztą wszystkie z tego co pamiętam są też opatrzone modyfikatorem file. 2. Tak, powiem więcej, jeżeli miałbym użyć gdzieś primary constructora to klasa
@obieq: Stosowanie prefiksów this i '_' jest tak naprawdę kwestią gustu i konwencji przyjętej w zespole. Dotnet używa . Ale nie jest to w żaden sposób sugerowane jako 'najlepsza' praktyka we wszystkich C#-owych projektach. Często domyślny prefiks będzie wynikał z domyślnych ustawień IDE. Ważne żeby było spójnie w projekcie/projektach.
@Hektorrr: ważne żeby było spójnie zgadzam się. Nie.narzucam.ale bardziej jako dobrą praktyka sugerowane jest unikanie this a to prowadzi właśnie do tego. (No i _ jednak krócej niż this.)
1. Czy używacie Primary Constructors w swoich klasach?
public sealed class Foo(Bar bar) { ... }2. Czy dotyczy to również klas ze wstrzykiwanymi zależnościami?
public sealed class Foo
{
private ILogger<Foo> logger;
public Foo(ILogger<Foo> logger)
{
this.logger = logger;
}
}
do:
public sealed class Foo(ILogger<Foo> logger)
{
}
3. Czy oznaczacie pola (fields) modyfikatorem 'readonly' w klasach z DI?
4. Jeżeli odpowiedzieliście TAK na pytanie 2 i 3, czy zachowujecie ten modyfikator również w przypadkach klas z Primary Constructorem?
public sealed class Foo
{
private readonly ILogger<Foo> logger;
public Foo(ILogger<Foo> logger)
{
this.logger = logger;
}
}
do:
public sealed class Foo(ILogger<Foo> logger)
{
private readonly ILogger<Foo> logger = logger;
}
5. Czy używacie w ogóle polskich nazw w Polskich firmach w odniesieniu do konceptów w C#/.NET, czy po prostu: DI, readonly, fields, property, primary constructor, service container?
#dotnet #csharp #ankieta #programowanie
Kiedyś mnie bardzo irytował kod z tymi nudnym konstruktora mi i listą pół. Ale to przeszkadza tylko na samym początku istnienia projektu, czyli niedługo.
Uważam, że ten ficzer przynosi więcej szkody, niż pożytku.
file.2. Tak, powiem więcej, jeżeli miałbym użyć gdzieś primary constructora to klasa
1 tak i to chyba nawet we wczesniejszych
2 this. kluje w oczy chyba lepiej _logger = logger
3. tak
4. wtf
5 nie
Ważne żeby było spójnie w projekcie/projektach.