Допустимо ли иметь пробелы перед точкой?

Question

Каково общее мнение о втором методе отступа ниже.

// Normal indentation
a.Value        = "foobar";
ab.Checked     = false;
foo.Value      = "foobar";
foobar.Checked = true;

// Spaces before the dot to align the properties/methods
a     .Value   = "foobar";
ab    .Checked = false;
foo   .Value   = "foobar";
foobar.Checked = true;

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

edit

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

fooA   .PropertyA = true;
foobarB.PropertyA = true;

Изменение свойстваAсо всеми строками было бы намного проще с новой функцией многострочного редактирования в VS2010.

Также есть пробелы и даже разрывы строк перед точкой вообще не редкость в C # (см. LINQ).

Answer 1

Пробелы перед точкой?Дорогой Бог, нет!

Answer 2

Я бы никогда не использовал никого лично. Я бы использовал только традиционное форматирование, например:

a.Value = "foobar";
ab.Checked = false;
foo.Value = "foobar";
foobar.Checked = true;

Я понимаю, что это может показаться не столь приятным для глаз, но чувствую, что другие менее идеальны.
Причины: -

1. Сложнее поддерживать: Иногда у вас могут быть имена переменных большего или меньшего размера или вводить другие переменные в ваш код, что означает, что вам нужно настроить форматирование всех записей.
2. Автоматическое форматирование может запутать это: Если вы используете ReSharper (возможно, со стандартным VS?) При нажатии ;, форматирование все равно вернет его в соответствие, так что вам придется выйти из способ убедиться, что он этого не сделает.
3. Я не могу думать об одном сейчас, но я не могу справиться только с двумя точками.

Редактировать! Мысль о другом пункте . Вовлечены более сложные нажатия клавиш: Например, для меня с ReSharper для достижения последнего форматирования я набрал бы foo, enter/tab (для подтверждения автозаполнения), tab раз X количество требуемых вкладок вверх переменной длины (раздражает), ., Value, tab для подтверждения автоматического завершения, =, затем присвоение данных, затем ; и затем крик в Visual Studio, потому что все мое нестандартное форматирование было отменено Как я уже говорил в пункте 2, наконец, нажатие CTRL + z вернет нам только что отформатированное форматирование. :)

Answer 3

Пробелы перед точками я бы НИКОГДА не делал, просто потому, что когда я читаю код, я перестаю искать точку, как только вижу пробел.Пробелы после точки я делал в прошлом, но вряд ли когда-либо, и я действительно предпочитаю не использовать это.Проблема с использованием такого стиля в том, что даже если он более читабелен для вас, если вы сделаете такой большой скачок (то есть пробелы перед точкой) из того, что можно считать «нормой», вы будете мешать болеелюди, чем помочь.Придерживаться стандарта в вашей команде или на рабочем месте - это самое главное.Даже если это не черно-белый стандарт, если другие 99 разработчиков в вашей компании используют стандарт VS и вы ставите все интервалы перед точками, это ничего не улучшит.

Answer 4

Я пробовал пару раз. Никогда не был доволен, что выглядело после слов.

Я всегда думал, что выравнивание по «точке» может работать в правильном контексте:

// -----------------------
// decimal-style alignment
// -----------------------
     a.Value   = "foobar" ;
    ab.Checked = false    ;
   foo.Value   = "foobar" ;
foobar.Checked = true     ;

Но вы теряете чистую левую границу, которая уводит взгляд вниз по странице и поддерживает ваше чувство отступа. Итак, вы вернулись к сохранению точки с идентификаторами, которые она соединяет. Однако ...

Выравнивание знаков равенства является хорошей практикой, поскольку помогает упорядочить весь набор:

// -----------------------
// tabular coding
// -----------------------
a.Value        = "foobar" ;
ab.Checked     = false    ;
foo.Value      = "foobar" ;
foobar.Checked = true     ;

Чем больше порядок наложен на код, тем больше вероятность заметить вещи, которые не в порядке.

Синтаксическому анализатору нет дела до аккуратного читаемого кода, но компилятор не является целевой аудиторией для вашего кода. Ваша целевая аудитория - это другие люди, которые должны это читать и понимать. В частности, бедняга & mdash; кто может быть вами! & Mdash; он должен спешно подобрать код и исправить его через 3 или 5 лет без документации, помогающей разобраться.

Answer 5

Приемлемо с точки зрения языка C #.

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

Я лично не борюсь с VS IDE. Стиль по умолчанию подходит для меня.

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

Редактировать: использование пробела (+ новая строка) для свободных интерфейсов выглядит хорошо (http://en.wikipedia.org/wiki/Fluent_interface#C.23).

Answer 6

Я бы использовал пробелы перед точкой, только если это все одно и то же свойство / метод.Если это сочетание свойств, как у вас в вашем примере, я бы остановился на «Нормальном».

Однако, я думаю, что это спорный вопрос, потому что автоформатор Visual Studio свернет все, когда в следующий раз кто-то наберет }, чтобы закрыть любой включающий блок.

Answer 7

Я всегда использовал «Нормальный отступ».Другой путь кажется мне менее ясным, потому что я не ожидаю увидеть отступ такого рода.