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

вместо:

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

этого:

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

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

if (condition)
{
   statement;
   statement;
}

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

if (condition)
   statement;
   statement;

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

if (condition)
   statement;

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

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

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

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

if(foo)
    DoSomething();

или

if(foo) DoSomething();

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

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

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

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

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

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

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

Я бы сделал:

if (something)
{
   DoSomething();
}

и

public string MyProperty { get; set; }

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

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

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

но, пока мы говорим о стиле, это

  if (something)

и

  if (!something)

никогда

  if (something== true)  

или

  if (something== false) 

таким образом, вы все еще занимаете меньше строк (что IMO увеличивает читаемость)

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

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

if (something == true) 
    DoSomething();

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

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

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

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

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

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

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

Если вы действительно хотите сохранить строки кода, Вы можете ввести его следующим образом:

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

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

if(something == true) DoSomething(); 

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

использование:

if(something) {   DoSomething(); }

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

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

пример:

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

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

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

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

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

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();
}

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

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

обычно я делаю это с помощью однострочного ifs:

if($something) {
    do_something();
}

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

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

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

вы все ошибаетесь, ошибаетесь!!!!! ;-)

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

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

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

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

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

Я предпочитаю horridly непередаваемые синтаксис:

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

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

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

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

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

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