Здравствуйте, Воронков Василий,

Я бы предпочел тот вариант, который короче (в данном случае — со скобками). Т. к. к синтаксису Си не прикипел, то читаемость обоих вариантов одинаковая.

T>>В чём разница?

FR>Сейчас уже ничем вроде, это я просто вспомнил веселый поиск ошибки на питоне кажется версии 2.2,
FR>которая такие вещи не отлавливала и не выдавала ни варнингов ни ошибок.

Какие вещи?

#   = пробел
# … = таб
def foo():
  def bar():
  …print "валидный таб"

  def zar():
  ……print 'валидный "лишний" таб'

Без -t даже варнинга не будет.

Здравствуйте, Temoto, Вы писали:

ВВ>>>А там можно получить неправильную программу просто вставив лишний пробел
FR>>Пробел фигня, вот неправильный таб вообще может до смертоубийства довести
T>В чём разница?

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

ВВ>>>>А там можно получить неправильную программу просто вставив лишний пробел
FR>>>Пробел фигня, вот неправильный таб вообще может до смертоубийства довести
T>>В чём разница?

ВВ>Дополнительная фишка таба в том, что его длина может отличаться в зависимости от настроек редактора.

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

Ох, похоже я стролился на tab-space holy war, там вроде речь шла о том, что "неправильный таб" хуже лишнего пробела. Пытаюсь понять чем именно.

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Ну это все равно функция с одним параметром. Тип параметра — кортеж.
FR>Это да, код аналогичен Немерлевскому,

Не совсем. Все же в Немерле функция вида

def func(x, y) { | 2, _ -> 0 | _ -> ... }

Это функция с несколькими параметрами и для нее возможно частичное применение. Для функции, объявленной через function, — нет.

FR>но в Немерли параметры преобразуются к кортежу, но с несколькими параметрами на OCaml
FR>тоже несложно сделать:

Это понятно. Речь была про сокращенную запись.

Здравствуйте, Temoto, Вы писали:

T>И ширина пробела тоже может отличаться, в зависимости от используемого шрифта. С другой стороны, все редакторы позволяют настроить ширину табов по вкусу. И самое главное: ну и пусть она отличается, что с того?
T>Ох, похоже я стролился на tab-space holy war, там вроде речь шла о том, что "неправильный таб" хуже лишнего пробела. Пытаюсь понять чем именно.

Ширина таба == энное количество пробелов. Если ты форматируешь код пробелами, то он и у меня и у тебя будет выглядеть одинаково, какой бы шрифт ты не использовал. При смеси пробелов и табов у меня, допустим, все будет выглядеть нормально, а у тебя "поедет" форматирование.
Короче, неправильный пробел ты всегда можешь заметить, а неправильный таб — не факт. Только если включать в редакторе отображение табов и пробелов.

T>>И ширина пробела тоже может отличаться, в зависимости от используемого шрифта. С другой стороны, все редакторы позволяют настроить ширину табов по вкусу. И самое главное: ну и пусть она отличается, что с того?
T>>Ох, похоже я стролился на tab-space holy war, там вроде речь шла о том, что "неправильный таб" хуже лишнего пробела. Пытаюсь понять чем именно.

ВВ>Ширина таба == энное количество пробелов.

... в твоём (и моём редакторе). А в другом ширина таба задаётся в пикселях.

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

Текст не может выглядеть одинаково в разных шрифтах, Василий, ты чего. Всё равно что сказать, что веб-страницы будут выглядеть одинаково с разными CSS.

ВВ>При смеси пробелов и табов у меня, допустим, все будет выглядеть нормально, а у тебя "поедет" форматирование.
ВВ>Короче, неправильный пробел ты всегда можешь заметить, а неправильный таб — не факт. Только если включать в редакторе отображение табов и пробелов.

Понял твою позицию.

Питоновский вариант вполне симпатичен

for x in y :
  expr

if x > y :
  expr
else :
  expr

Здравствуйте, Temoto, Вы писали:

ВВ>>Если ты форматируешь код пробелами, то он и у меня и у тебя будет выглядеть одинаково, какой бы шрифт ты не использовал.
T>Текст не может выглядеть одинаково в разных шрифтах, Василий, ты чего. Всё равно что сказать, что веб-страницы будут выглядеть одинаково с разными CSS.

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

void SomeFunction(type param1,
                  type param2,
                  type param3);

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

А вообще я сам при форматировании использую табы

Здравствуйте, Temoto, Вы писали:


T>

T>#   = пробел
T># … = таб
T>def foo():
T>  def bar():
T>  …print "валидный таб"

T>  def zar():
T>  ……print 'валидный "лишний" таб'
T>

T>Без -t даже варнинга не будет.

А тут где ошибка?

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

T>>

T>>#   = пробел
T>># … = таб
T>>def foo():
T>>  def bar():
T>>  …print "валидный таб"

T>>  def zar():
T>>  ……print 'валидный "лишний" таб'
T>>

T>>Без -t даже варнинга не будет.

FR>А тут где ошибка?

Тут нет ошибки.

FR>То что у нас было мне мешает вспомнить склероз, но суть в том
FR>что внешне выглядящий нормально код воспринимался интерпретатором
FR>совсем по другому чем выглядел

Понятно. Это, наверное, потому что табы редактор не выделял.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>А как бы вы отнеслись к сокращению "скобочности" синтаксиса? Хотя бы в выражениях.

StyleCop в C# заставляет расставлять скобки везде. Так как на самом деле все равно ставить или нет в большинстве случаев (когда можно написать и так, и так) — то лучший вариант, который контролируется автоматически.

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

Здравствуйте, Кэр, Вы писали:

Кэр>StyleCop в C# заставляет расставлять скобки везде. Так как на самом деле все равно ставить или нет в большинстве случаев (когда можно написать и так, и так) — то лучший вариант, который контролируется автоматически.
Кэр>То есть в общем случае, правильное решение со скобочками — выбирать вариант, который может быть поддержан автоматически и иметь тулзу, которая не дает коммитить код не соответствующий стандартам. Тем самым поддерживая принцип "наименьшего удивления".

Это ты к чему вообще?

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Это ты к чему вообще?

К тому что этот вопрос про скобочки — это вопрос стиля написания кода. А стиль кода должен быть просто однообразным в проекте. Если есть тулза, которая может это автоматически поддерживать — то нужно выбирать вариант, который эта тулза может поддерживать.

Здравствуйте, Кэр, Вы писали:

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

Не приходило в голову, что "тулзу" можно подправить?

Здравствуйте, VladD2, Вы писали:

VD>Не приходило в голову, что "тулзу" можно подправить?

Конкретно здесь или в общем случае?

В случае с этими скобочками — вообще довольно все равно, как писать. Правило "скобочки должны быть всегда" — легко запомнить, легко применить, легко проверить автоматически.

В общем случае — опять же зачем? Куда эти инвестиции? Кто это будет тестировать и поддерживать в команде?

ВВ>>А как бы вы отнеслись к сокращению "скобочности" синтаксиса? Хотя бы в выражениях.

Кэр>StyleCop в C# заставляет расставлять скобки везде. Так как на самом деле все равно ставить или нет в большинстве случаев (когда можно написать и так, и так) — то лучший вариант, который контролируется автоматически.

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

Любой стиль может быть проверен автоматически.

Здравствуйте, Кэр, Вы писали:

Кэр>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Это ты к чему вообще?
Кэр>К тому что этот вопрос про скобочки — это вопрос стиля написания кода. А стиль кода должен быть просто однообразным в проекте. Если есть тулза, которая может это автоматически поддерживать — то нужно выбирать вариант, который эта тулза может поддерживать.

Только я спрашивал не о стиле, а о грамматике.

Здравствуйте, Кэр, Вы писали:

Кэр>StyleCop

StyleCop это нифига не аргумент. Там много очень странного есть, типа обязательного this.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, _FRED_, Вы писали:

VD>>>Я вот уже двадцать лет не пишу фигурные скобки так где это возможно и ни разу не нарывался на эти "последствия".

_FR>>Во-первых, откуда знаешь про "ни разу", может не все ошибки ещё нашёл

VD>Ну, я как-то думал, что трудно не заметить того, что нарвался на проблемы. Нет?
ты один над программами работаешь? Не приходилось у себя чинить то, что на деле являлось последствием ошибки в чужом модуле? Ошибка есть, но стреляет так, что последствия всплывают в совсем другом коде. Бывало такое.....