Функция и объявление локальной переменной - PullRequest
5 голосов
/ 06 июля 2010

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

Стиль "C" - все переменные в начале функции.Если вы хотите узнать тип данных переменной, просто посмотрите на начало функции.

bool Foo()
{
    PARAM* pParam = NULL;
    bool rc;

    while (true)
    {
       rc = GetParam(pParam);
       ... do something with pParam
    }
}

Стиль "C ++" - объявите переменные как можно более локальными.

bool Foo()
{       
    while (true)
    {
        PARAM* pParam = NULL;

        bool rc = GetParam(pParam);
       ... do something with pParam
    }
}

Что вы предпочитаете?

Обновление Вопрос касается переменных POD.

Ответы [ 6 ]

13 голосов
/ 06 июля 2010

Второй. (Стиль C ++) Для этого есть как минимум две веские причины:

  1. Это позволяет вам применять в коде принцип YAGNI, , поскольку вы объявляете переменные только тогда, когда они нужны, как можно ближе к их использованию. Это облегчает понимание кода, так как вам не нужно переходить туда-сюда в функции, чтобы понять все это. Тип каждой переменной является основной информацией о переменной и не всегда очевиден в имени переменной. Короче говоря: код легче читать .
  2. Это позволяет улучшить оптимизацию компилятора (когда это возможно). Читать: http://www.tantalon.com/pete/cppopt/asyougo.htm#PostponeVariableDeclaration
4 голосов
/ 06 июля 2010

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

Если у вас есть выбор, то имеет смысл объявить переменные там, где они используются. Основное правило, которое я использую: объявлять переменные с наименьшей необходимой областью действия.

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

3 голосов
/ 06 июля 2010

Я предпочитаю "стиль C ++". Главным образом потому, что он допускает RAII , что вы делаете в обоих примерах для переменной bool.

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

1 голос
/ 06 июля 2010

Это, вероятно, немного субъективно.

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

0 голосов
/ 07 июля 2010

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

0 голосов
/ 07 июля 2010

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

Хотя я не придерживаюсь строго стиля: туда помещаются только ключевые переменные, и большинство мелких переменных находятся в блоке, где они необходимы (например, bool rc в вашем примере).

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

...