Разработчик пишет if/elseблоки с однострочными кодами, например:
if (condition)
// Do this one-line code
else
// Do this one-line code
Другой использует фигурные скобки для всех из них:
if (condition)
{
// Do this one-line code
}
else
{
// Do this one-line code
}
Разработчик сначала создает объект, а затем использует его:
HelperClass helper = new HelperClass();
helper.DoSomething();
Другой разработчик создает и использует объект в одной строке:
new HelperClass().DoSomething();
Разработчику проще с массивами и forциклами:
string[] ordinals = new string[] {'First', 'Second', 'Third'};
for (i = 0; i < ordinals.Length; i++)
{
// Do something
}
Другой пишет:
List<string> ordinals = new List<string>() {'First', 'Second', 'Third'};
foreach (string ordinal in ordinals)
{
// Do something
}
Я уверен, что вы знаете, о чем я говорю. Я называю это стилем кодирования (потому что я не знаю, как это называется). Но как бы мы это ни называли, хорошо это или плохо? Влияет ли стимулирование на повышение продуктивности разработчиков? Должны ли мы попросить разработчиков попытаться написать код так, как мы им говорим, чтобы вся система стала согласованной по стилю?
1
На самом деле я пришел сюда, чтобы задать очень похожий вопрос только сейчас - когда инструменты автоматического форматирования кода доступны и удобны, важнее ли, чтобы эти инструменты не запускались (и сохраняли несовместимые личные стили) или чтобы применялся стиль?
—
пушистый
Последовательный стиль облегчает чтение кода, поэтому используйте согласованный стиль. В ваших примерах проще всего читать 2, 1, 2. Хотя последний случай отличается. В приложениях, критичных к производительности, цикл for выполняется быстрее при переборе списков. Производительность идентична итерации по массивам. И во всех случаях используйте
—
Стивен
varвместо полного имени типа.