Подтвердить что ты не робот

Стиль кодирования С# - длина линии/линии упаковки

Помогает ли перенос строк при чтении кода?

Существует ли общепринятый этикет для использования продолжений линии?

Зачем использовать это:

SomeMethod(int someInt, Object someObject,
   String someString, bool someBool)
{
    ...
}

Вместо этого:

SomeMethod(int someInt, Object someObject, String someString, bool someBool)
{
    ...
}

Изменить: переформулировал мой вопрос от продолжения строки до переноса строки

4b9b3361

Ответ 1

Строковые продолжения не используются в С#, так как требуется явный ограничитель строк (;).

Если вы спрашиваете, с точки зрения стиля, будь то это хорошая идея, чтобы разбить строку на несколько строк, что спорно. Правила StyleCop заставляют строку либо задаваться в одной строке, либо для каждого элемента, находящегося на отдельной строке. Я лично считаю, что это хорошая рекомендация, и я обычно предпочитаю разбивать линию полностью на ее части, если она слишком длинная, чтобы вписаться в хороший редактор шириной 80-90 символов.


Изменить в ответ на новый вопрос:

В этом случае я буду следовать приведенным выше рекомендациям. Лично в вашем конкретном случае я оставил бы это на одной строке:

SomeMethod(int someInt, Object someObject, String someString, bool someBool) 
{ 
    ... 
} 

Это хорошая короткая декларация о методе, и я не вижу причин ее разделить. Я бы разделил его только на то, что количество аргументов и длины типов стали длинными для одной строки текста.

Если вы разделите его, я разделил бы его на отдельные строки для каждого аргумента:

SomeMethod(
    int someInt, 
    Object someObject, 
    String someString, 
    bool someBool) 
{ 
    ... 
} 

Таким образом, по крайней мере, это очевидно, как и почему он разделяется, и разработчик не будет случайно пропустить один аргумент, поскольку два находятся в одной строке.

Ответ 2

Теперь, когда мы выяснили, что это не связано с фактическими символами продолжения строки и просто с оберткой - скажите мне. Это:

IEnumerable<int> orderIDs = context.Customers.Where(c => c.CustomerID >= 1 && c.CustomerID <= 10).Select(c => c.Orders).SelectMany(o => o).OrderBy(o => o.OrderDate).Select(o => o.OrderID);

Или это?

IEnumerable<int> orderIDs = context
    .Customers
    .Where(c => c.CustomerID >= 1 && c.CustomerID <= 10)
    .Select(c => c.Orders)
    .SelectMany(o => o)
    .OrderBy(o => o.OrderDate)
    .Select(o => o.OrderID);

Что бы вы лучше прочитали?

Ответ 3

Я думаю, что предел длины линии постепенно увеличивался (или исчезал) за последние несколько лет, так как каждый получает широкоэкранные мониторы hi-res и редко печатает код. Ни один из проектов, над которыми я работал, не имеет официального руководства, мы просто используем здравый смысл и линейную разметку примерно на ширине окна редактора (каждый использует один и тот же базовый макет окна Eclipse примерно с таким же разрешением). Я не вижу проблем с этим методом.

Ответ 4

Я предпочитаю разбивать строки в логических точках. Причина заключается в том, чтобы помочь с использованием функций дифференцирования и слияния исходного кода. Я обнаружил, что понимание изменений в такой среде намного проще, если выражения с множеством элементов разбиты на несколько строк.

Мониторы большие. Но вы можете найти себя на ноутбуке и выполнить слияние, в котором у вас есть базовые, исходные и целевые ветки в отдельных окнах по экрану. Подсчитайте символы: каждое из этих окон на 17-дюймовом ноутбуке шириной всего около 55 символов.

Если вы работаете удаленно, вы обнаружите, что горизонтальная прокрутка не очень оптимизирована, и вы можете подумать несколько укоризненных мыслей о программистах, которые пишут функции с 15 параметрами в одной строке.

Итак, подумайте обо всех способах работы с исходным кодом и сломайте линии в местах, которые обслуживают ВСЕ ваши потребности.

Ответ 5

Несколько лет назад я прочитал лучшие практики Дамиана Конвей Перла. Здесь ссылка ниже

Perl Best Pracices в Google Книгах

Здесь есть целая глава, посвященная Макету кода. Все мои чувства относительно макета кода суммируются в его письме. Я очень рекомендую эту главу. Его можно легко применить к С#.

Я пытаюсь придерживаться его правил для любого языка, который я мог бы использовать: С#, Java, Perl, JavaScript, VBScript, VB, PHP,...

В этой книге Конвей предлагает использовать 78-столбцовые строки. Я должен признать, что я нарушил правило и придерживался 80, но я думаю, что все в порядке.

Я включил это правило в каждый редактор, который я использую (Notepad ++, Komodo, Vi, Vim, Visual Studio 2005), чтобы иметь визуальный ориентир, показывающий этот предел.

Некоторые из вас могут задаться вопросом, как показать руководство VS, а?

Ну, я нашел, что это не так очевидно. Фактически, вы должны фактически создать строковый параметр в реестре. Вот сообщение, которое я нашел на SO об этом. Надеюсь, что это поможет.

Добавление руководства к редактору в Visual Studio

Ответ 6

Лично мне нравится "видеть" все. Опять же, у меня довольно приличный монитор. Но серьезно, мне нравятся приятные и маленькие функции против гигантских функций с вложенными "if" состояниями. То же самое с строками кода.

В конце концов, это сводится к личным предпочтениям и независимо от того, что вы и члены вашей команды решаете. Быть последовательным. И способствуйте читабельности для следующего парня, который смотрит на ваш код.