Было бы плохим тоном ставить фигурные скобки в той же строке, что и оператор для однострочных операторов «if»?

Вместо:

if (something == true)
{   DoSomething(); }

Сделай это:

if (something == true) {   DoSomething(); }

Когда я сталкиваюсь с однострочным оператором if, я обычно пропускаю фигурные скобки и сохраняю все в одной строке:

if (something == true) DoSomething();

Это быстро, легко и экономит место.

Здесь нет проблем ... на самом деле, Visual Studio не поместит этот код в отдельную строку, если вы попытаетесь его автоматически отформатировать. Итак, если вам это удобнее ... вы в порядке.

That way you still take up fewer lines (which IMO increases readability)

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

Если вы действительно хотите сохранить строки кода, вы можете ввести его так:

if (something == true) { DoSomething(); }

или это без скобок

if (something == true) DoSomething(); 

Если вы работаете в команде, вам нужно придумать стандарт.

Лично мне нравится делать:

if (foo)
    DoSomething();

или же

if (foo) DoSomething();

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

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

На фронте наступательного стиля это намного лучше, чем невыразимое:

  if (something== true)   {
      DoSomething();
  }

Но, раз уж мы говорим о стиле, это

  if (something)

и

  if (!something)

Никогда

  if (something== true)  

или же

  if (something== false) 

Я бы порекомендовал вам поступить так, как сказали Стивен и Николас Манкузо.

Использовать:

if (something) {   DoSomething(); }

С кронштейном или без него. Как только вы начнете использовать странную версию оператора if, вы начнете видеть, как ваши коллеги смотрят на ваш код странным образом.

Обычно я использую один лайнер для проверки.

Пример:

if ( param1 == null ) throw new ArgumentNullException("param1");

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

Я столкнулся с этой проблемой вчера, когда работал над кодом, написанным кем-то другим. Исходный код был:

if (something == true) 
    DoSomething();

и я хотел получить отладочную печать перед вызовом DoSomething(). Что бы я сделал инстинктивно

if (something == true) 
    print("debug message");
    DoSomething();

Но это заставит if применяться только к отладочному сообщению, в то время как DoSomething() будет вызываться безоговорочно. Вот почему я бы предпочел фигурные скобки, чтобы инстинктивное редактирование закончилось так:

if (something == true) {
    print("debug message");
    DoSomething();
}

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

Сказав это, нет ничего плохого в том, что вы и ваша команда используете ваш стиль. Пока вы все с этим согласны.

Я обычно помещаю открывающие скобки в отдельную строку следующим образом:

if (condition)
{
   statement;
   statement;
}

Итак, увидев что-то вроде:

if (condition)
   statement;
   statement;

сразу выделяется как неправильный. Если у меня есть только одно утверждение, я просто оставлю его как

if (condition)
   statement;

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

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

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

Некоторые отладчики и IDE могут быть в состоянии перешагнуть через обе части однострочного оператора if и четко показать, истинно ли условие или нет, но многие другие отладчики могут рассматривать его как одну строку, что затрудняет определение того, является ли тело if-заявление было вызвано.

Например, отладчик VS2008 для кода C++ будет перешагивать через это как одну строку, что затрудняет определение того, был ли вызван Foo ().

if (a==b) { Foo(); }

Лично мне нравится, что все мои блоки имеют одинаковый узор. Я всегда использую фигурные скобки для if, и они всегда начинают новую строку. Мне нравится идиома для автоматического определения общедоступных свойств размещения {get; набор; } в той же строке. Я просто чувствую, что если все блоки начинаются с фигурной скобки на отдельной строке, это улучшает читаемость. Как отмечали другие, это также делает более ясным в отладчике, если вы переступаете через строки.

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

Я бы сделал:

if (something)
{
   DoSomething();
}

и

public string MyProperty { get; set; }

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

Просто делайте то, что вам удобнее всего, а затем убедитесь, что все знают, что так делать всегда.

На самом деле я предпочитаю

if (something == true)
if (something == false)

над

if (something)
if (!something)

Мне трудно увидеть восклицательный знак с первого взгляда, поэтому его легко пропустить. Однако обратите внимание, что когда я кодирую на Python, я почти всегда предпочитаю:

if something:
if not something:

Если я не хочу отличать None, например, от пустого списка.

Иногда мне нравится делать

if (obj != null) obj.method();

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

public executeMethodOn(String cmd) {
  CommandObject co;

  if ("CmdObject1".equals(cmd)) co=new CmdObject1();
  if ("CmdObject2".equals(cmd)) co=new CmdObjec21();

  co.executeMethod();
}

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

Тем не менее, если у вас Когда-либо есть такой шаблон, вы, вероятно, делаете это неправильно. Мне приходилось делать это в системе, в которой не было отражения, но я ДЕЙСТВИТЕЛЬНО старался обойти это, и если бы у меня было отражение, это было бы намного круче.

Обычно я делаю это с однострочными if:

if ($something) {
    do_something();
}

Единственное исключение (я использую Perl, не уверен, разрешен ли этот стиль в C#) - это элементы управления циклом, где я использую перевернутый однострочный стиль:

THING:
for my $thing (1 .. 10) {
    next THING if $thing % 3 == 0;
}

С помощью хорошей раскраски синтаксиса можно резко выделить эти строки.

Вы все НЕПРАВИЛЬНО НЕПРАВИЛЬНО НЕПРАВИЛЬНО !!!!! ;-)

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

Пробелы - это стиль. Поскольку у нас разные стили чтения и стили обучения, больше не имеет значения, как вы это делаете. Инструменты позволят нам переключаться вперед и назад. Единственный недостаток, который я когда-либо замечал, - это затраты на отслеживание изменений в системе управления версиями. Когда я переформатирую файл стиля K&R в более разумный формат (мое мнение) и проверяю это изменение обратно в систему управления версиями, он показывает почти каждую строку как измененную. Это боль. Но многие утилиты diff могут игнорировать изменения пробелов (хотя большинство только на одной строке, а не на охватывающих строках). Это проблема. Но не ограничитель шоу.

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

В результате это «было бы плохо» относится только к соглашениям о кодировании. Это зависит от контекста. Если вы работаете в команде, неплохо спросить всех, что они думают, и придумать стандартный стиль форматирования. Если нет, то это действительно ваше дело.

Так что, если вы думаете, что так лучше, продолжайте. Если нет, то не надо. Это действительно так просто (если вы не используете IDE, которая накладывает некоторые соглашения о стилях)

Я предпочитаю ужасающе невыразимый синтаксис:

if (true == something) {
    doSomething1();
}

Да, именно так K&R сделали это ... и да, я возвращаюсь так далеко ... и да, для меня это достаточно веская причина. Это означает, что я получаю общий синтаксис, даже когда делаю что-то вроде этого:

if (-1 == doSomething()) {
   doSomethingElse();
}

Я вставляю фигурные скобки независимо от количества строк кода, которые они содержат. Меня укусила «необходимость добавить строку тестового кода», и я слишком много раз упускал из виду отсутствие фигурных скобок.

Я всегда сравниваю с буквальным слева. Это позволяет избежать ошибки «тестирования присваивания» (например, if (something = true) {...}).

Нет большей опасности для переносимости «(something == true)», чем для перегруженного набора значений, которые означают «истина» и «ложь» в логическом сравнении - но это опасность другого рода. Вы пишете на языке, который считает «пустой» (и / или ноль, и / или NULL, и / или пробел) «истинным» или «ложным»? Я предпочитаю соглашение, безопасное для любого случая ... потому что я ленив.