Code style. Быть или не быть после if-ов - single line statements-ам
Кстати
Мне кажется, что тем, кто может в этом случае чего-то не заметить, лучше не программировать совсем, а пойти работать в макдональдс. Правда там они будут забывать, что клиент просил колу без льда, а к картошке надо положить уже оплаченный сырный соусЯ не в курсе, как в макдональдсах, а в обычных кафе официанты обычно записывают на специальную бумажку то, что заказывает посетитель. , конечно, отобрал бы у них бумажки, сказав "нормальный человек и так всё запомнит, а идиоты пусть идут улицы подметать; правда, там они будут забывать, что какую-то улицу пропустили, а какую-то подметают уже по третьему разу".
Ничего по поводу моего вопроса ты так и не ответил.Ответил. И в этой теме тоже ответил. Оба стиля имеют право на жизнь. Теперь не еби мне мозг и научись думать.
Стиль "без скобочек" не имеет права на жизнь, потому что у него нет ни одного преимущества перед стилем "со скобочками" (по крайней мере, я их не вижу, и ты их не назвал и имеет много недостатков (хотя ты тут и пытаешься сейчас сказать, что эти недостатки не такие уж и большие, и с ними, если постараться, вполне можно жить).
Стиль "без скобочек" не имеет права на жизнь, потому что у него нет ни одного преимущества перед стилем "со скобочками" (по крайней мере, я их не вижу, и ты их не назвал и имеет много недостатков (хотя ты тут и пытаешься сейчас сказать, что эти недостатки не такие уж и большие, и с ними, если постараться, вполне можно жить).Стиль "без скобочек" имеет право на жизнь, потому что у него нет ни одного недостатка перед стилем "со скобочками" (по крайней мере, я их не вижу, и ты их не назвал и имеет много преимуществ (хотя ты тут и пытаешься сейчас сказать, что эти преимущества не такие уж и большие, и без них, если постараться, вполне можно жить).
а вот здесь я кстати не совсем понял твою позицию чем именно чреваты)Потому что у нас спор не с тобой был, а с . же сказал, что знает, чем чреваты, что это всем очевидно, но он настолько продвинут, что считает, что нормальные люди на эти грабли не наступят.
Речь идёт о том, что, когда кто-то модифицирует код, и хочет, например, вставить дополнительную инструкцию, к коду
if(something)
doSomething;
просто дописывают новую инструкцию, и получается
if(something)
Debugger.Debug("Something is true");
doSomething;
, если этот человек не заметил отсутствие скобок, и код начинает работать совсем не так, как ожидается.
Речь идёт о том, что, когда кто-то модифицирует код, и хочет, например, вставить дополнительную инструкцию, к кодуВ современных IDE (как минимум для C#/Java) это решается тем, что код после вставки строки автоматом(или полуавтоматом) форматируется, и соответственно строка сдвинется, и будет визуально видно, что она вне блока if-а.
соответственно, короткие if-ы можно записывать без скобок (но if и операция на отдельных строках)
если же операция длинная (не влазит в одну строчку то тогда скобки должны быть, чтобы не было путаницы.
плюс в отсутствии скобок - чем код короче(без фанатизма тем он легче читается
В современных IDE (как минимум для C#/Java) это решается тем, что код после вставки строки автоматом(или полуавтоматом) форматируетсяИ?
Проведу аналогию - если есть антивирусы, это значит, что не надо пользоваться файрволом?
C#/Java - это всё-таки не питон.
плюс в отсутствии скобок - чем код короче(без фанатизма тем он легче читаетсяВот в убирании фигурных скобок мне как раз видится фанатизм. Кому-то становится сложнее читать код от того, что там стоят фигурные скобки? Во всяком случае, от такого аргумента не было.
>если этот человек не заметил отсутствие скобок,
Это каким же надо быть оленем, чтобы в серьезном проекте не заметить отсутствие скобок в следующей и предыдщих строках?
Это каким же надо быть оленем, чтобы в серьезном проекте не заметить отсутствие скобок в следующей и предыдщих строках?
Кому-то становится сложнее читать код от того, что там стоят фигурные скобки?для меня сложнее, и читать, и писать. у Майка, afaik, такая же позиция
т.е. моя позиция, что оба варианта имеют права на жизнь даже одновременно в одном и том же коде: и со скобками, и без скобок
потому что да, мне непонятно - зачем перегружать вот такой простой код:
if (x < 0)
return -x;
else
return x;
Ну вот так - взял и проглядел.
Я же не говорю, что это происходит постоянно, чаще всё-таки замечаешь; но когда не замечаешь - то случается пц.
Я же не говорю, что это происходит постоянно, чаще всё-таки замечаешь; но когда не замечаешь - то случается пц.
Это равносильно тому, что проглядел и вместо "<0" написал ">0".
для меня сложнее, и читать, и писать.Если уж говорить про IDE - всё это настраивается, можно сделать, чтобы "писать" надо было ровно столько же.
А при прочтении - не понимаю, в чём сложность. Что в
if(x < 0) {
return -x;
} else {
return x;
}читать сложнее, чем в
if (x < 0)
return -x;
else
return x;
? В первом варианте просто чётко видно отделение блоков.
И ещё один вопрос. Допустим, половина людей - как ты, им удобнее читать и писть без скобок; а другая половина - совершает из-за этого ошибки по описанной мной схеме. Какой code style всего проекта принять, с обязательными фигурными скобками или без них?
Это каким же надо быть оленем, чтобы в серьезном проекте не заметить отсутствие скобок в следующейи предыдщих строках?легко.
могу про себя честно сказать: да, в редких ситуациях, могу на что-то отвлечься и не заметить.
например, в ситуациях, когда сначала добавляю операцию, а потом ставлю скобки - если между этими этапами меня отвлекут, то да - я потом могу и не вспомнить, что скобки я так и не поставил.
но сами по себе эти ошибки не важны.
важно насколько легко потом эти ошибки выявить при беглом просматривании
соответственно, если есть правило, что многострочное действие должно браться в скобки, то тогда вот такой код даже при беглом просмотре вызовет вопросы: это ошибка форматирования, или забыли добавить скобки
if (x < 0)
x = -x;
y = 5;
return x;
Не равносильно.
В твоём примере - написал не то, что хотел.
В моём примере - написал то, что хотел, но не заметил, что кто-то до тебя не поставил фигурные скобки, и не выполнил за него его работу.
И ещё. В коде, по-твоему, будет везде только подход "без фигурных скобок, если тело занимает одну строку", или где как?
Во втором случае - ещё легче допустить ошибку, потому что в однострочных телах скобки иногда есть, а иногда нет.
В первом случае - ошибку допустить немного сложнее (хотя непонятно, почему для однострочных тел правила не такие, как для многострочных, принципиально-то они ничем не отличаются, кроме точки зрения компилятора но тогда надо ещё обязать всех не забывать _удалять_ фигурные скобки при удалении нескольких строк из тела так, что оно становится однострочным.
В твоём примере - написал не то, что хотел.
В моём примере - написал то, что хотел, но не заметил, что кто-то до тебя не поставил фигурные скобки, и не выполнил за него его работу.
И ещё. В коде, по-твоему, будет везде только подход "без фигурных скобок, если тело занимает одну строку", или где как?
Во втором случае - ещё легче допустить ошибку, потому что в однострочных телах скобки иногда есть, а иногда нет.
В первом случае - ошибку допустить немного сложнее (хотя непонятно, почему для однострочных тел правила не такие, как для многострочных, принципиально-то они ничем не отличаются, кроме точки зрения компилятора но тогда надо ещё обязать всех не забывать _удалять_ фигурные скобки при удалении нескольких строк из тела так, что оно становится однострочным.
тогда вот такой код даже при беглом просмотре вызовет вопросы: это ошибка форматирования, или забыли добавить скобкиВо-первых, надо будет сначала потратить некоторое время на то, чтобы добраться до того метода, где проблема.
Во-вторых - как раз любимые нами пустые строки сделают вероятность проглядеть отсутствие закрывающей фигурной скобки выше.
В-третьих, она и без того довольно высока.
важно насколько легко потом эти ошибки выявить при беглом просматриванииБеглом просматривании чего?
Это равносильно тому, что проглядел и вместо "<0" написал ">0".стандартная опечатка, много раз видел в коде, и в чужом, и бывало в своем - возникает обычно, когда идет модификация условий с одних на другие (операнды поменяли, про знаки забыли, или наоборот)
поэтому на это есть хорошее предложение, писать только знаки меньше, т.е. меньшую величину всегда располагать слева
т.е. 0 <= x && x < length, лучше чем length > x && 0 <= x
Беглом просматривании чего?кода, конечно.
> В моём примере - написал то, что хотел, но не заметил, что кто-то до тебя не поставил фигурные скобки, и не выполнил за него его работу.
Почему вдруг ты думаешь, что это _его_ работа, если в вашем коллективе не было четко и однозначно принято ставить скобки?
Можно усердно делать код все более дуракоустойчивым и доходить в этом до абсурда. Просто 99% программеров будут тратить лишние 5% времени на написание и лишние 5% на перепроверки кода ради того, чтобы 1% программеров этот код не запоганил при дальнейшем использовании.
Почему вдруг ты думаешь, что это _его_ работа, если в вашем коллективе не было четко и однозначно принято ставить скобки?
Можно усердно делать код все более дуракоустойчивым и доходить в этом до абсурда. Просто 99% программеров будут тратить лишние 5% времени на написание и лишние 5% на перепроверки кода ради того, чтобы 1% программеров этот код не запоганил при дальнейшем использовании.
кода, конечно.Какого именно кода?
Или всего проекта?
ОМГ.
Вот так:
никто не пишет. Если мы о сишарпе говорим. Там устойчивое соглашение писать фигурные скобки отдельными строчками, типа у всех кодеров нормальные мониторы и всё такое.
Тем не менее, if с двумя условиями я лично всегда пишу со скобками. Ибо нехуй. В тех случаях, когда внутри явно экспрешн, а не стейтмент, я пишу тернарный оператор (если строчки длинные, то разнося на несколько).
А вот
или получающийся из него переносом на следующую строчку в силу длины
мне по нраву.
Вот так:
if(x < 0) {
return -x;
} else {
return x;
} никто не пишет. Если мы о сишарпе говорим. Там устойчивое соглашение писать фигурные скобки отдельными строчками, типа у всех кодеров нормальные мониторы и всё такое.
Тем не менее, if с двумя условиями я лично всегда пишу со скобками. Ибо нехуй. В тех случаях, когда внутри явно экспрешн, а не стейтмент, я пишу тернарный оператор (если строчки длинные, то разнося на несколько).
А вот
if (blablabla) doSomething(bla);
или получающийся из него переносом на следующую строчку в силу длины
if (blablabla)
doSomething(bla, blablabla, bla(bla bla);
мне по нраву.
никто не пишет. Если мы о сишарпе говорим. Там устойчивое соглашение писать фигурные скобки отдельными строчкамиМне казалось, что такие соглашения принимаются в рамках конкретной группы разработчиков, а не всемирно.
В тех случаях, когда внутри явно экспрешн, а не стейтмент, я пишу тернарный операторСогласен.
мне по нраву.Первый вариант нормален, а вот второй - говно. Чем тебе фигурные скобки-то мешают? Не надо своё питонье видение мира переносить на языки со скобками
Я вот думаю, что если так:
if (condition) expression;
то можно. А так:
if (condition)
expression
нельзя именно по тем причинам, что написал пенартур.
Ну и конечно, если возможно, лучше заменять оператором ? :
if (condition) expression;
то можно. А так:
if (condition)
expression
нельзя именно по тем причинам, что написал пенартур.
Ну и конечно, если возможно, лучше заменять оператором ? :
>никто не пишет. Если мы о сишарпе говорим. Там устойчивое соглашение писать фигурные скобки отдельными строчками, типа у всех кодеров нормальные мониторы и всё такое.
В Ява пишут.
В Ява пишут.
легко.Кстати, у меня за много лет практики ни разу не возникло такой ошибки. Да и мои коллеги таких ошибок ни разу не делали. Поэтому мне эта ситуация, честно говоря, кажется раздутым мифом.
могу про себя честно сказать: да, в редких ситуациях, могу на что-то отвлечься и не заметить.
Кстати, у меня за много лет практики ни разу не возникло такой ошибки.а у тебя в работе вообще ошибки бывают?
какие? и почему(что привело к ошибке)?
а у тебя в работе вообще ошибки бывают?Вообще бывают. В основном, связанные с логикой и со, скажем так, распределёнными механизмами (клиент-сервер, поток-поток, событие-состояние). Третьего вопроса я совсем не понял.
какие? и почему?
Третьего вопроса я совсем не понял.что послужило причиной ошибки?
опечатка, не понимание работы чего-либо, не получилось отследить все взаимосвязи и т.д.
что послужило причиной ошибки?Опечатки разве что на Си++ или Lua. А так скорее второе и третье.
опечатка, не понимание работы чего-либо, не получилось отследить все взаимосвязи и т.д.
Кстати, у меня за много лет практики ни разу не возникло такой ошибки. Да и мои коллеги таких ошибок ни разу не делали. Поэтому мне эта ситуация, честно говоря, кажется раздутым мифом.а я вот столкнулся
в интрнет-банке Райфа, главный прогер создававший этот инетбанк случайно такое допустил
бага долгое время там жила пока я не заметил
там был некий парсинг и стояло куча ифов, для читаемости было все отформатировано без автоформата
я в svn логах не лазал но и так было понятно что 2-я и 3-я строчка в ифе появились позже, а скобки добавить забыли
Оставить комментарий
kruzer25
Ты так и не осилил ответить на вопрос из предыдущего треда.В чём преимущество отсутствия фигурных скобок? Ты сейчас пытаешься всех убедить, что без фигурных скобок не так уж плохо, иногда с этим можно жить - отлично, пусть даже случилось чудо и тебе все поверили, согласились, что недостатков не так много, как кажется... но преимущества-то какие?