Deweloper zapisuje if/elsebloki za pomocą instrukcji jednowierszowych, takich jak:
if (condition)
// Do this one-line code
else
// Do this one-line code
Inny używa nawiasów klamrowych dla wszystkich:
if (condition)
{
// Do this one-line code
}
else
{
// Do this one-line code
}
Deweloper najpierw tworzy instancję obiektu, a następnie go używa:
HelperClass helper = new HelperClass();
helper.DoSomething();
Inny programista tworzy instancję i używa obiektu w jednej linii:
new HelperClass().DoSomething();
Deweloper jest łatwiejszy dzięki tablicom i forpętlom:
string[] ordinals = new string[] {'First', 'Second', 'Third'};
for (i = 0; i < ordinals.Length; i++)
{
// Do something
}
Inny pisze:
List<string> ordinals = new List<string>() {'First', 'Second', 'Third'};
foreach (string ordinal in ordinals)
{
// Do something
}
Jestem pewien, że wiesz o czym mówię. Nazywam to stylem kodowania (ponieważ nie wiem, jak się nazywa). Ale jakkolwiek to nazwiemy, czy jest to dobre czy złe? Czy zachęcanie ma wpływ na wyższą produktywność programistów? Czy powinniśmy prosić deweloperów, aby spróbowali napisać kod w sposób, w jaki mówimy, aby cały system stał się spójny ze stylem?
1
Właśnie przyjechałem tutaj, aby zadać bardzo podobne pytanie - kiedy narzędzia automatycznego formatowania kodu są dostępne i wygodne, czy ważniejsze jest, aby te narzędzia nie były uruchamiane (i zachowywały niespójne style osobiste), czy miały mieć egzekwowany styl?
—
puszysty
Spójny styl ułatwia czytanie kodu, dlatego używaj spójnego stylu. W twoich przykładach najłatwiejszy do odczytania jest 2, 1, 2. Chociaż ostatni przypadek jest inny. W aplikacjach krytycznych pod względem wydajności pętla for działa szybciej podczas iteracji po listach. Wydajność jest identyczna jak w przypadku tablic. I we wszystkich przypadkach używaj
—
Stephen
varzamiast w pełni kwalifikowanej nazwy typu.