Основные принципы C++: Правила выражений и операторов
Что ж, мы плавно выходим на старт второго потока группы «Разработчик С++» и разбираем интересные материалы, которые накопились у преподавателя в свободное от работы и преподавания время. Сегодня рассмотрим (а потом и продолжим) серию материалов, где разбираются отдельные пункты С++ Core Guidelines.
В C++ Core Guidelines много правил, посвященных выражениям и операторам. Если быть точным, то более 50 правил посвящено объявлениям, выражениям, операторам и арифметическим выражениям.
*перевод Информативные названия
Оптимальная длина переменных
- Не должны быть слишком длинными (maximimNumberOfPointsInModernOlympics.) или слишком короткими (например, x, x1)
- Длинные названия сложно печатать, короткие названия недостаточно информативны..
- Дебажить программы с названиями от 8 до 20 символов гораздо проще
- Гайдлайны не заставляют вас срочно менять названия переменных на имена из 9-15 или 10-16 символов. Но если вы найдете в своем коде более короткие названия, убедитесь, что они достаточно информативны.
Существует два правила, являющихся общими:
Нет смысла писать сырой цикл для суммирования вектора чисел:
Просто используйте алгоритм std::accumulate из STL.
Это правило напомнило мне слова Шона Парент (Sean Parent) с CppCon 2013: “Если вы хотите улучшить качество кода в организации, замените все принципы кодинга одной целью: никаких сырых циклов!”.
Дословно: если вы пишете сырой цикл, скорее всего вы просто не знаете алгоритмов STL.
Правило 2: Отдайте предпочтение подходящим абстракциям перед непосредственным использованием языковых особенностей Следующее дежавю. На одном из последних семинаров по C++ я долго обсуждал и еще дольше проводил детальный анализ нескольких замысловатых самодельных функций для чтения и записи strstream’ов. Участники были должны поддерживать эти функции, но спустя неделю так и не смогли в них разобраться.
Понять функционал мешали неправильные абстракции, на которых он был построен. К примеру, посмотрим на самодельную функцию для чтения std::istream :
И, в сравнении, насколько проще воспринимается следующая функция:
Правильная абстракция часто означает, что вам не придется думать о владении, как это происходит в функции read1. И это работает в read2. Вызывающий read1 владеет result и должен удалить его.
Объявление вводит имя в область видимости. Но, если честно, я предвзят. С одной стороны, эти правила могут быть скучными, потому что во многом очевидны. С другой стороны, я видел достаточно кода, нарушающего эти правила. Например, однажды я разговаривал с бывшим программистом Fortran, который считал, что каждая переменная должна состоять ровно из трех символов.
В любом случае, я продолжу объяснять правила, потому что хорошие названия помогают делать код более легким для чтения и понимания, поддержки и расширения.
Вот первые шесть правил. (нумерация идёт как в статье. Автор пропустил пункты 3 и 4 т.к. они не соответствуют тематике)
Код будет занимать не больше экрана и хватит одного взгляда, чтобы понять, как он работает. Если область видимости слишком большая, структурируйте код и разделите его на функции и объекты с методами. Определите логические сущности и используйте очевидные названия в процессе рефакторинга. Благодаря этому ваш код станет гораздо проще.
Мы могли объявлять переменную в операторе for еще со времен первого С++ стандарта. А в C++17 мы можем объявлять переменные и в операторах if и switch .
Переменная result (1) действительна только внутри веток if и else оператора if . Поэтому result не будет засорять внешнюю область видимости и автоматически уничтожится (2). Такая особенность есть только в C++17, раньше result нужно было бы объявить во внешней области видимости (3).
Правило может показаться странным, но мы уже привыкли. Присваивая переменным имена i , j и Т , мы сразу даем понять, что i и j — это индексы, а T — тип параметра шаблона.
Для этого правила есть мета-правило. Имя должно было очевидным. Если контекст небольшой, можно быстро понять, что делает переменная. Но в длинном контексте понять сложнее, поэтому нужно использовать названия длиннее.
А вам удастся прочитать этот пример без замешательства?
Если честно, я часто с трудом различаю цифру 0 и заглавную букву O. Из-за шрифта они могут выглядеть почти одинаково. Два года назад мне потребовалось очень много времени, чтобы залогиниться на сервер. Просто потому что автоматически сгенерированный пароль содержал символ O.
Если вы пишете названия ПОЛНОСТЬЮ_КАПСОМ, то будьте готовы столкнуться с заменой на макросы — именно в них он часто используется. В части программы, представленной ниже, есть небольшой сюрприз:
p2 — просто char (1) и c не инициализирован (2).
В C++17 для нас есть одно исключение из этого правила: структурированное связывание. Теперь я могу сделать if выражение с инициализатором из правила 6 еще более удобным для чтения.
THE END (to be continued)
Если есть вопросы, замечания, то ждём их тут или у нас на Дне открытых дверей.