C# стиль кодирования - длина линии/линии обертывания

Question

Помогает ли линия обертывания с читаемостью кода?

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

Почему это:

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

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

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

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

Answer 1

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

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

---

Редактировать в ответ на ваш новый вопрос:

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

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

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

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

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

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

Answer 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); 

Что бы вы предпочли прочитать?

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

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

Answer 6

Несколько лет назад я прочитал «Даймиан Конвей» Perl Best Practices. Вот ссылка ниже

Perl Best Pracices on Google Books

Там целая глава там дело с Code Layout. Все мои чувства относительно макета кода суммируются в его письме. Я очень рекомендую эту главу. Его можно легко применить к C#.

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

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

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

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

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

Adding a guideline to the editor in Visual Studio