Объективные преимущества синтаксиса C-стиля

ИМХО, единственное, что делает синтаксис в стиле C популярно то, что большинство людей это знает. Таким образом, использование стиля C для нового языка позволяет применять старые привычки (например, соглашения об именах). Это хорошая вещь! Хотя я думаю, что синтаксис - наименьшее беспокойство при изучении нового языка. Но хороший синтаксис может помочь избежать ошибок.

Microsoft приложила много усилий, чтобы сделать VB.NET таким же важным, как C # (помните все " null ( Nothing в Visual Basic) "в MSDN, что меня очень раздражает), но все же C # является доминирующим языком для платформы .NET. Похоже, что у VB.NET есть проблема с плохой репутацией его предшественников. И еще, использование стиля C кажется более профессиональным.

В конце концов, одной из целей C было сделать компилятор простым в реализации. Было проще использовать препроцессор, чем определять новую языковую конструкцию для констант. Или семантика [5]. Это не относится к C ++, который очень сложно реализовать, отчасти потому, что он пытается оставаться совместимым с C.

Примеры:

• Чувствительность к регистру, хотя нечувствительность к регистру более естественна для людей (НЕ для компьютеров). Это не означает, что вы должны писать идентификаторы иначе, чем они были объявлены (будьте осторожны!), Но может привести к путанице. Реальный пример (Java): getWhiteSpace () или getWhitespace ()?

РЕДАКТИРОВАТЬ: Еще один хороший пример: Какая самая плохая ошибка в C # или .NET? . Целью разработки было упростить реализацию компилятора. Было проще использовать препроцессор, чем определять новую языковую конструкцию для констант. Или семантика [5]. Это не относится к C ++, который очень сложно реализовать, отчасти потому, что он пытается оставаться совместимым с C.

Примеры:

• Чувствительность к регистру, хотя нечувствительность к регистру более естественна для людей (НЕ для компьютеров). Это не означает, что вы должны писать идентификаторы иначе, чем они были объявлены (будьте осторожны!), Но может привести к путанице. Реальный пример (Java): getWhiteSpace () или getWhitespace ()?

РЕДАКТИРОВАТЬ: Еще один хороший пример: Какая самая плохая ошибка в C # или .NET? . Целью разработки было упростить реализацию компилятора. Было проще использовать препроцессор, чем определять новую языковую конструкцию для констант. Или семантика [5]. Это не относится к C ++, который очень сложно реализовать, отчасти потому, что он пытается оставаться совместимым с C.

Примеры:

• Чувствительность к регистру, хотя нечувствительность к регистру более естественна для людей (НЕ для компьютеров). Это не означает, что вы должны писать идентификаторы иначе, чем они были объявлены (будьте осторожны!), Но может привести к путанице. Реальный пример (Java): getWhiteSpace () или getWhitespace ()?

РЕДАКТИРОВАТЬ: Еще один хороший пример: Какая самая плохая ошибка в C # или .NET? . Это не относится к C ++, который очень сложно реализовать, отчасти потому, что он пытается оставаться совместимым с C.

Примеры:

• Чувствительность к регистру, хотя нечувствительность к регистру более естественна для людей (НЕ для компьютеров). Это не означает, что вы должны писать идентификаторы иначе, чем они были объявлены (будьте осторожны!), Но может привести к путанице. Реальный пример (Java): getWhiteSpace () или getWhitespace ()?

РЕДАКТИРОВАТЬ: Еще один хороший пример: Какая самая плохая ошибка в C # или .NET? . Это не относится к C ++, который очень сложно реализовать, отчасти потому, что он пытается оставаться совместимым с C.

Примеры:

• Чувствительность к регистру, хотя нечувствительность к регистру более естественна для людей (НЕ для компьютеров). Это не означает, что вы должны писать идентификаторы иначе, чем они были объявлены (будьте осторожны!), Но может привести к путанице. Реальный пример (Java): getWhiteSpace () или getWhitespace ()?

РЕДАКТИРОВАТЬ: Еще один хороший пример: Какая самая плохая ошибка в C # или .NET? . но может привести к путанице. Реальный пример (Java): getWhiteSpace () или getWhitespace ()?

РЕДАКТИРОВАТЬ: Еще один хороший пример: Какая самая плохая ошибка в C # или .NET? . но может привести к путанице. Реальный пример (Java): getWhiteSpace () или getWhitespace ()?

РЕДАКТИРОВАТЬ: Еще один хороший пример: Какая самая плохая ошибка в C # или .NET? . Но, конечно, если вы привыкнете к этому и с помощью IDE, это больше не проблема, иногда даже более естественная, потому что это больше похоже на то, как на самом деле работают компьютеры.

• Приоритет оператора

• = для присвоения и == для сравнения. если (a = b) кто-нибудь? Аналогично, && и & , || и | , (! и ~ ) синтаксически слишком близки, хотя означают разные вещи. Лично я бы предпочел и и или , потому что символы должны просто поддерживать синтаксис, а не быть основной частью.

• ++ и - операторы; Делает некоторые операторы немного короче, но добавляет побочные эффекты к выражениям ( a = b +++ b ++ ). Первоначально компиляторы могли компилировать это более эффективно, чем i = i + 1 .

• for (init; condition; step) loop; Хотя лучше всего использовать его только для увеличения переменной, явного синтаксиса для этого не существует. Вместо этого эта конструкция for избыточна, поскольку она (почти) такая же, как

   init;
  while (условие) {
   заявление;
   шаг;
  }
  

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

• оператор if (condition) . Использование круглых скобок было не лучшим выбором, поскольку их можно использовать в самом выражении условия:

   if (! (Var & 0x02))
  

• Препроцессор

• Фигурные скобки. Это спорно. Я не согласен с аргументами, утверждающими, что они «не занимают много места на экране», являются более краткими или быстрее пишутся. Во-первых, язык должен быть таким, чтобы его было легко читать, а не писать. Во-вторых, в зависимости от вашего стиля фигурные скобки используют столько же места на экране, что и ключевые слова: вы пишете их в одной строке. Разве это не много потраченного впустую места?

  Кроме того, люди критикуют LISP за беспорядок в круглых скобках. С вами никогда не случалось, чтобы вам приходилось считать свои подтяжки, чтобы узнать, где вы их пропустили? Иногда я добавляю комментарий после закрывающей скобки, чтобы указать, что здесь должно заканчиваться. В синтаксисе BASIC это уже включено. И даже не требует эквивалента открывающей скобки. Отчасти я согласен с тем, что брекеты - это хорошо: они почти незаметны, а отступы являются доминирующей визуальной характеристикой. С этой точки зрения следующим шагом будет python.

• Точка с запятой как терминатор или разделитель операторов. Почему единственная точка с запятой является допустимым выражением?

   if (condition);
   Сделай что-нибудь();
  

• Неразличимые последовательности ключевых слов

   общедоступная статическая строка main ()
  

  Это объявление метода? Или объявление переменной? Или прототип функции? Или что-то другое? Некоторая пунктуация (и ключевые слова для каждого типа объявления) могли бы здесь помочь, например, чтобы четко разделить возвращаемый тип. Это то, что затрудняет синтаксический анализ C ++.

• Ортогональность. {} while (условие) подходит для других языковых конструкций, в которых за оператором следует блок. Я думаю, что VB

   делает [while / until condition]
   Заявления
  цикл [пока / до условия]
  

  хорошее решение, потому что у вас есть 4 возможных комбинации с разной семантикой: до / пока после ключевого слова do / loop.

• Странный порядок модификаторов типа переменных.

   int * const & i [];
  

• Тип и имя переменной просто появляются друг за другом, без маркера того, что это объявление локальной переменной. В Scala используются val и var , которые указывают на объявление конечной / изменяемой переменной, а тип разделяется двоеточием. В большинстве других вещей Scala использует синтаксис Java.

• Оператор присваивания, возвращающий значение; Никакого различия между операторами (с эффектами) и выражениями (которые просто возвращают значение)

РЕДАКТИРОВАТЬ: Еще несколько примеров: https://stackoverflow.com/questions/163026/what-is-your -least-Favorite-syntax-gotcha

Вы определенно не согласитесь со многими из этих пунктов, и не все из них обязательно отрицательные (например, точки с запятой), или что я знал решение, которое лучше для всех случаев . Даже если бы я это сделал, полученный язык не был бы идеальным языком. Языки программирования всегда будут развиваться, и мы надеемся, что вновь изобретенные языки будут учиться у своих предшественников. Итак, почему бы не придерживаться известного синтаксиса вместо того, чтобы разрабатывать новый каждые десять лет?

Однако, когда разработчик языка имеет возможность избежать ошибок программирования, которые представляют собой просто опечатки, почему бы не изменить это? Например, это было сделано в операторе switch C #, который делает break (или goto) обязательным. И как только худшие недостатки устранены, преимущество знания остального синтаксиса синтаксиса большинством программистов намного перевешивает преимущества перепроектирования языка с нуля. Но меня до сих пор удивляет, почему так много программистов все еще так страстно защищают C-синтаксис, хотя они привыкли к тому, что прогресс в компьютерных науках требует регулярного пересмотра почти всего.

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

(Может быть, будет комикс о программисте, посетившем Денниса Ричи: «Пожалуйста, не ломайте ] в операторах switch необязательно! ")