Стиль кодирования в основном для удобства чтения или есть другие факторы? - PullRequest
2 голосов
/ 08 августа 2009

Я помню, как читал в книге Дугласа Крокфорда "Javascript the Good Parts", что существует вероятность ошибки в выражениях без блоков из-за автоматического ввода точки с запятой.

if (condition)
   foo = true;

против

if (condition) 
{
   foo = true;
}

Во втором примере он будет работать согласованно, в первом примере интерпретатор автоматически вставляет точку с запятой и может привести к неоднозначности в коде. Как указывает Дуглас, это потенциально плохо и трудно отлаживать, что я согласен. Но это заставило меня задуматься, есть ли примеры, когда кодирование "стиля" на самом деле имеет синтаксическое значение? Другими словами, примеры, когда несоблюдение определенного отступа или кажущегося стиля фактически приводит к ошибке или ошибке. Я предполагаю, что Python с его значительным пробелом является примером, а YML с требованием отсутствия вкладок - это еще один пример.

Не стесняйтесь отвечать на самых разных языках и идиомах. Мне любопытно услышать о случаях парадигмы. В вашем ответе я хотел бы знать, ЧТО и ПОЧЕМУ стиль кодирования или поведение синтаксиса. Я не хочу начинать какие-либо пламенные войны в стиле кодирования, просто сценарии фактов, когда непосвященных могут споткнуть.

Ответы [ 10 ]

7 голосов
/ 08 августа 2009

Javascript рассматривает эти два случая отдельно. Вы должны использовать первый

return {
   // code
}

return 
{
   // code
}

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

return;
{
   // code
}

Неверный синтаксис.

4 голосов
/ 08 августа 2009

Никто не упоминал об этом раньше, но один из пунктов стиля - написать

if (NULL == p) // ...

вместо

if (p == NULL) // ...

Оба функционально эквивалентны, так что это вопрос стиля. Многие предпочитают стиль вверху, потому что если вы наберете «=» по ошибке вместо «==», то первый не скомпилируется, а второй скомпилирует ошибку, которую трудно найти (хотя некоторые компиляторы теперь дают вы предупреждение для if (p = NULL)).

4 голосов
/ 08 августа 2009

Стиль кодирования не только для удобочитаемости. Есть и другие факторы, такие как

  • Избегайте распространенных языковых ошибок (сбои в режиме без вывода сообщений, исключения во время чтения и т. Д.)
  • Простота обслуживания
  • Повышение четкости кода (например, частные функции, всегда запускающие loweCase и общедоступный beeing PascalCase)
  • Обеспечение соблюдения соглашений (например, не использовать множественное наследование или всегда наследовать public в c ++)

пример простоты сопровождения приведен ниже:

if(x) return true;

против

if(x) 
{
   return true;
}

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

2 голосов
/ 08 августа 2009

Каждый раз, когда я открываю скобки, скобки, одинарные или двойные кавычки, я всегда закрываю их, а затем возвращаюсь, чтобы написать утверждение, условие и т. Д. ... Это спасает меня от некоторых, возможно, больших ошибок!

2 голосов
/ 08 августа 2009

В C ++ есть разница между

vector<pair<int,int>>

и

vector<pair<int,int> >

потому что >> обрабатывается синтаксическим анализатором как один токен.

2 голосов
/ 08 августа 2009

Пробелы не имеют значения ни в одном из языков семейства C, за исключением отдельных языковых токенов. Компоновка исходного кода не влияет на исполняемый файл, созданный компилятором.

2 голосов
/ 08 августа 2009

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

1 голос
/ 08 августа 2009

Заголовок не был специфичен для условных блоков, так что это пришло на ум:

Я пока не упоминал об этом, но одна вещь, на которую стоит обратить внимание: как вы находите вещи с помощью простых инструментов (например, grep и его низших реализаций из windowsland).

Например, рассмотрим этот (правда, немного надуманный) пример

class Foo
// vs.
class
Foo

Вы можете найти первое с помощью регулярного выражения "class \ s + Foo", но для последнего вам понадобится специализированный инструмент, который может анализировать C ++ / C # / java.

Это относится и к Си для прототипов функций, некоторые странные люди предпочитают

void
bar (void)
// to 
void bar(void)

Хотя обычно вы можете предположить, что если перед именем функции находятся символы A-Z, то вполне вероятно, что это определение / объявление.

На самом деле, если речь идет о ifblocks, то размещение фигурной скобки очень сильно влияет на отладочный код в Visual Studio 200x. Когда он входит в функцию / блок, он помещает курсор текста / строки выполнения на открывающую скобку. Таким образом, если скобка окажется в правой стороне, окно кода должно прокрутиться туда, и buggeritall останется там. Чрезвычайно раздражает.

1 голос
/ 08 августа 2009

Это зависит от языка. Например в Java

void someFunction() { }

и

void someFunction() { 
}

и

void someFunction() 
{ 
}

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

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

1 голос
/ 08 августа 2009

Это зависит от языка. В фигурном семействе C / C ++ / Java / C # пробел не является ограничением, если ваши скобки открыты и закрыты должным образом.

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

Private Sub someFunction() End Sub

Но в C, C ++ и других вьющихся языках вы можете иметь

void someFunction() { }

В python, я думаю, это совсем другое дело.

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

...