90 рекомендаций

for (vector<MyClass>::iterator i = list.begin(); i != list.end(); i++)

нда

стилей вообще миллион, и каждый уверен в своём.

Ну там помимо стилей много забавных вещей.

for (vector<MyClass>::iterator i = list.begin(); i != list.end(); i++)

for(auto i: list)

Читаю новый стандарт — там много приятных плюшек и есть даже огроменные плюшищи.
Жаль только на работе пока нет возможности использовать новый gcc...

А 2012 студия разве не поддерживает уже с++11?

И да тут фишка не в длине записи, а в том, что афтар предлагает использовать i,j,k вместо нормальных имен у бегунков.

студия

Мы кроссплатформенный код пишем, так что gcc

бегунков

Ну вот. Я теперь буду целый день хихикать как дибил.

Не ходите туда! Там от гото отговаривают!

Аааа, я думал вообще gcc нельзя использовать. Ну от чего ж, мы на работе под студией вполне себе кроссплатформенный код писали...

Там от брейков отговаривают.

Не ну вообще тут итератор да, но там советы даются и на случай массивов обычных. Ну я и придумал такое нехорошее слово,да=)

Допускаются любые нарушения рекомендаций, если это улучшает читаемость.

Вот оно!!!! Причем в первом пункте! Дальше читать не стал, ибо, все правильно.

использовать i,j,k вместо нормальных имен у бегунков

А нормальные это какие? ijk в ходу еще со времен фортрана.

Так от ситуации зависит же. Однозначно запрещать осмысленые имена итераторов - глупость.

MySuperIterator

чем тебе i, j, k не угодили?

Я и не говорил, что не угодил, но запрещать другие варианты - это глупость. В любом случае варианты там и почище есть. Которые вообще мозгом рака пахнут.

58. Следует избегать использования break и continue в циклах.

что, goto вместо них писать? или наделать переменных и проверять их все в for(;;)?

Следует избегать использования break и continue в циклах

Совет конечно спорный, но вообще да, break читаемости не добавляет т.к. в сложных случаях бывает неочевидно, к чему он относится:

while(something()) {
    ...
    switch(value) {
    case 1:
       if (ok) {
           ...
           break; // что брякнется? цикл или кейс?
       }
       ...
       break; // а здесь?
    }
}

Заставит джуниора гуглить - так делать нехорошо.

что, goto вместо них писать?

Нет. Делать декомпозицию кода на функции.

запрещать другие варианты - это глупость.

Там же в первом правиле написано про это.

Нееее Первое правило это типо, если у вас есть другой вариант... А тут прямым текстом сказано «такой вариант говно».

Нет. Делать декомпозицию кода на функции.

в _любом_ случае? или только в случае вложенных в цикл switch'ей? вкладывать преключатель в цикл конечно неудобно, но и декомпозиция - тоже не панацея.

Разумеется оба выйдут из свича.

Вообще ++i оптимальнее.

Подобные косяки всплывают при первом прогоне. Если не писать портянки на несколько экранов,то таких ошибок вообще не будет. Имхо, надуманная проблема с читабельностью.

С чего вдруг?

ijk у меня лично ассоциируются с целочисленными счетчиками. Для итераторов я, например, чаще использую it.

Подробностей не помню, но вроде как для префиксного инкремента не создается дополнительного временного объекта => он быстрее.

Это итератор. О каком временном объекте идет речь?

http://www.viva64.com/ru/d/0165/

V803. Decreased performance. It is more effective to use the prefix form of ++it. Replace iterator++ with ++iterator

хм и правда. Буду иметь в виду.

Там есть ссылка на книжку и на обзор от человека (внизу список).

Дочитал до этого:

  int getMaxIterations() // НЕЛЬЗЯ: MAX_ITERATIONS = 25
  {
    return 25;
  }

а поясните пункт 56 (не могу скопипастить, звиняйте)

constexpr

с константами своё ок, это какая-то НЁХ

Они имели ввиду что если константа используется только внутри класса ,то ее лучше ,прости господи, сделать членом. А если в стопятьсот тысяч классов, то лучше через дефайн, иначе искать, где эти «25» по коду разбросаны, жизни не хватит.

Именно.

Я и не говорю, что магические числа — это хорошо. Но есть же препроцессор, дефайны и всяческие удобные штуки. А эта конструкция с return 25 — жуткая.

префиксный инкремент нельзя использовать при итерации объектов

Например, класс обрабатывает сетевой пакет, если длину пакета забить define LEN_PACKET 25, то возможно другому программисту с другим пакетом такая же идея придёт и они подерутся. А так они эту длину в класс прячут.

Я не понимаю только зачем делать метод? К тому же, судя по другим советам, не инлайный. Чем константный член класса не угодил?

Но почему не так?

int LEN_PACKET = 25;

  int getPacketLength()
  {
    return 25;
  }

Видимо, чтобы был геттер, для единообразия API. Странное решение.

Чтобы скрыть детали реализации. Может это не константа, может максимальный размер пакета высчитывается сложным образом на основе положения зодиакальных созвездий и планет.

Пример, почему?

У метода больше возможностей,например подсчитать количество обращений, «битые» пакеты сформировать, просто длину вычислить и т.д.

Мы кроссплатформенный код пишем, так что Apple clang 4.0 

fixed

fixed

Разфиксь и последуй совету со совей аватарки.:)
Нам бы ехать, а шашечки — дело десятое.
Этот LLVM позавчера только себя собирать научился, а ты его уже рекламируешь как компилятор.

для скалярных типов 4.2. для объектов - согласен.

Вызов метода стоит дороже, не? На красивость, ооп-головного мозга не всчет :-D