to the top
close form

Заполните форму в два простых шага ниже:

Ваши контактные данные:

Шаг 1
Поздравляем! У вас есть промокод!

Тип желаемой лицензии:

Шаг 2
Team license
Enterprise license
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности
close form
Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Бесплатная лицензия PVS-Studio для специалистов Microsoft MVP
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Мне интересно попробовать плагин на:
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
check circle
Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
>
50 вредных советов для С++ программиста

50 вредных советов для С++ программиста

09 Июн 2022

Какую статью по C++ ни возьми, она серьёзна и требует вдумчивого чтения, желательно с кофе. А развлечься тоже хочется. Для этого и написана эта шуточная статья с вредными советами по программированию. Главное – не перепутайте с полезными!

0953_50_terrible_tips_ru/image1.png

Я пишу статьи, посвящённые созданию качественного кода и методологии статического анализа. Но хочется пошалить. Так и появилась эта статья с 50 антисоветами. Впрочем, если в комментариях читатели напишут ещё рекомендаций по созданию говнокода, то есть шанс, что выйдет новая статья, начинающаяся с числа 100 :).

Если вдруг не совсем понятно, почему какой-то совет вредный, то перейдите по {ссылочке}. Ссылка отсутствует? Дайте знать, пополню пояснения.

  • Настоящие программисты программируют только на C++! {1}
  • Если в строковом литерале вам нужен символ табуляции, смело жмите кнопку tab. Оставьте \t для яйцеголовых. Не парьтесь.
  • Всюду используйте вложенные макросы. Так текст программы станет короче, и вы сохраните больше места на жёстком диске. Заодно это развлечёт ваших коллег при отладке. {3}
  • Отключите предупреждения компилятора. Они отвлекают от работы и мешают писать компактный код.
  • Используйте для переменных имена из одной-двух букв. Так в одну строчку, помещающуюся на экране, можно уместить более сложное выражение.
  • Используйте числа в программировании. Так ваша программа будет выглядеть умнее и солиднее. Согласитесь, что такие строки смотрятся хардкорно: qw = ty / 65 - 29 * s; {6}
  • Используйте при написании кода невидимые символы. Пусть ваш код работает магическим образом. Это прикольно.
  • Во всех старых книгах для хранения размеров массивов и для организации циклов использовались переменные типа int. Так и делайте. Не стоит нарушать традиции. {8}
  • Глобальные переменные очень удобны, т.к. к ним можно обращаться отовсюду.
  • Совет для разработчиков библиотек: в любой непонятной ситуации сразу завершай программу, используя функцию abort или terminate. {10}
  • Если что-то не работает, то, скорее всего, глючит компилятор. Попробуйте поменять местами некоторые переменные и строки кода. {11}
  • Не мешкайте и не тормозите. Сразу берите и используйте аргументы командной строки. Например, так: char buf[100]; strcpy(buf, argv[1]);. Проверки делают только параноики, неуверенные в себе и в людях. {12}
  • Undefined behavior – это страшилка на ночь для детей. На самом деле его не существует. Если программа работает, как вы ожидали, значит она правильная. И обсуждать здесь нечего, точка. {13}
  • Смело сравнивайте числа с плавающей точкой с помощью оператора ==. Раз есть такой оператор, значит им нужно пользоваться. {14}
  • memmove — лишняя функция. Всегда и везде используйте memcpy. {15}
  • Размер указателя и int — это всегда 4 байта. Смело используйте это число. Число 4 смотрится намного изящнее, чем корявое выражение с оператором sizeof. {16}
  • Нет смысла проверять, удалось ли выделить память. На современных компьютерах её много. А если не хватило, то и незачем дальше работать. Пусть программа упадёт. Всё равно уже больше ничего сделать нельзя. {17}
  • Добавляйте разные вспомогательные функции и классы в пространства имён std. Ведь для тебя эти функции и классы стандартные и базовые, а раз так, им самое место в std. {18}
  • Коллеги должны знать о вашем богатом опыте с языком C. Не стесняйтесь демонстрировать им в вашем C++ проекте свои умелые навыки ручного управления памятью и longjmp.
  • Используйте как можно меньше фигурных скобок и переносов строк, старайтесь писать условные конструкции в одну строку. Так код будет быстрее компилироваться и занимать меньше места. {20}
  • Никогда не тестируйте. И не пишите тестов. Ваш код идеален, что там тестировать! Ведь не зря вы настоящие C++ программисты. {21}
  • И статические анализаторы не используйте. Это инструменты для студентов и неудачников. {22}
  • Всегда и везде выкатывайте любые изменения сразу на продакшн. Тестовые сервера – лишняя трата денег.
  • Всегда, при любых ситуациях используйте как можно большее количество вложенных друг в друга объектов. Сложность – это солидно!
  • Никогда не используйте платные компоненты. Только ломанные и с как можно более "левых" сайтов. Не за что, в конце концов, платить другим программистам. Тем более, если они вдруг использовали не C++. Фу.
  • Не пользуйтесь стандартной библиотекой языка. Что может быть интереснее, чем написать свои строки и списки с уникальным синтаксисом и семантикой? {26}
  • Смартпоинтеры и прочее RAII от лукавого, всеми ресурсами надо управлять вручную, это делает код простым и понятным.
  • И вообще, выделение памяти — зло. char c[256] хватит всем, а если не хватит, то потом поменяем на 512. В крайнем случае – на 1024.
  • Не пользуйтесь системой контроля версий. Храните исходники прямо на сервере в виртуалке.
  • Выравнивание и единый стиль не дают раскрыться вашей индивидуальности и креативности. Это притеснение свободы личности и самовыражения. Каждый должен оформлять код так, как ему нравится.
  • Побольше кода в заголовочных файлах, ведь так гораздо удобнее, а время компиляции возрастает очень незначительно. {31}
  • Злые языки говорят, что goto считается вредным, но это чушь. Этот оператор очень мощен и способен заменить множество других. Да здравствует goto и аскетизм!
  • Никогда не используйте enum'ы, они все равно неявно приводятся к int. Используйте int напрямую! {33}
  • Используйте как можно больше разных систем сборки и пакетных менеджеров, покажите, что вы в курсе современных тенденций! Разумеется, версии кода в пакетах для разных менеджеров должны быть немного разными, иначе пользователи заскучают.
  • Проявите немного уважения к программистам прошлого – объявляйте все переменные в начале функций. Это традиция! {35}
  • Подключайте как можно больше хидеров, чтобы каждый .cpp файл раскрывался в миллион строк – коллеги скажут спасибо за то, что у них больше времени на перекур во время пересборки! {36}
  • Пишите ваши .h-файлы так, чтобы они зависели от других заголовков, и при этом не включайте их в свой заголовочный файл. Пусть тот, кто инклудит, догадается, какие заголовки нужно заранее заинклудить перед использованием вашего файла. Развлеките коллег квестами!
  • Зачем нужны все эти *_cast, если есть reinterpret_cast, который всегда работает? А ещё лучше и короче старый добрый C-style cast: (Type)(expr).
  • Если решили написать функцию, то она должна быть мощной и универсальной, как швейцарский армейский нож, и должна принимать много аргументов. Для экономии времени можно аргументы не перечислять, а парсить с помощью va_arg.
  • Что может быть плохого в том, чтобы через указатель на переменную посмотреть в соседнюю переменную? Мы же в пределах своей памяти. {40}
  • Слово const только место в коде занимает. Если вы не хотите менять переменную, то просто не будете её менять. {41}
  • А вы знаете, что вместо фигурных скобок можно использовать <% и %>? Диграфы и триграфы могут придать вашему коду визуальную свежесть и необычность, что выделит его на фоне кода коллег. И при этом ничего незаконного, они же есть в стандарте.
  • Зачем инициализировать переменные, если там и так нули? Я вот недавно не инициализировал, и там ноль был. Всё работало.
  • private для параноиков. Кому они нужны, эти поля класса?
  • Заведите как можно больше переменных, которые будут отличаться в названиях только числами: index1, index2. {45}
  • Пишите код так, как будто его будет читать председатель жюри IOCCC, и он знает, где вы живёте (чтоб приехать и вручить вам приз). {46}
  • Если в C++ переносы строк и отступы незначимые, то почему бы не оформить код в виде зайчика или белочки?
  • Все знают, что операторы обращения по индексу к указателю обладают коммутативностью. Так не будьте серыми, как все. Придайте коду оригинальность, используя конструкции вида 1[array] = 0.
  • Перегрузите как можно больше операторов, в том числе и не арифметических, для как можно большего количества типов. Придавая операторам другой смысл, вы приближаетесь к созданию своего диалекта языка. Свой язык – это прикольно. А если ещё и макросы к делу подключить...
  • Универсальный std::string – это неэффективно. Можно ловчее и эффективнее использовать realloc, strlen, strncat и так далее. {50}
  • Раз допустимо ссылаться на следующий элемент за пределами массива, то значит, можно к этому элементу и обращаться. Ой, это же уже 51-й пункт списка, а их должно было быть 50. Сорри, но какая C++ статья без off-by-one error :). {51}

Возможно, читая статью, вы вспомнили о ком-то из коллег :). Тогда самое время отправить ему этот текст. Пока! До встреч в отладчике!

Популярные статьи по теме
64-битные ошибки: LONG, LONG_PTR и привет из прошлого

Дата: 09 Мар 2023

Автор: Андрей Карпов

В целом, 64-битные ошибки - дело минувших дней. Мало кто сейчас занимается портированием кода с 32-битной на 64-битную систему. Кому это было нужно, уже портировали свои приложения. Кому не нужно, то…
Приключения капитана Блада: потонет ли Арабелла?

Дата: 14 Фев 2023

Автор: Владислав Столяров

Недавно в сети появилась новость о том, что был открыт исходный код игры "Приключения капитана Блада". Мы не смогли пройти мимо и проверили его качество с помощью PVS-Studio. Потонет ли легендарный к…
Тонкости C++: итак, вы объявили класс…

Дата: 07 Фев 2023

Автор: Сергей Ларин

Во время работы наша команда постоянно сталкивается с некоторыми особенностями языка, которые могут быть неизвестны рядовому C++ программисту. В этой статье мы расскажем о том, как работает, казалось…
Под капотом SAST: как инструменты анализа кода ищут дефекты безопасности

Дата: 26 Янв 2023

Автор: Сергей Васильев

Сегодня речь о том, как SAST-решения ищут дефекты безопасности. Расскажу, как разные подходы к поиску потенциальных уязвимостей дополняют друг друга, зачем нужен каждый из них и как теория ложится на…
Ложные представления программистов о неопределённом поведении

Дата: 17 Янв 2023

Автор: Гость

Неопределённое поведение (UB) – непростая концепция в языках программирования и компиляторах. Я слышал много заблуждений в том, что гарантирует компилятор при наличии UB. Это печально, но неудивитель…


Комментарии (0)

Следующие комментарии next comments
close comment form
Unicorn with delicious cookie
Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо