Как вычислить Сишника, когда вам нужен C++-разработчик

Так уж случилось, что я пишу код для разных железок, связанных с электричеством, типа зарядных станций автомобилей. Поскольку аппаратных ресурсов, как правило, вполне достаточно, то основной фокусом является не экономия каждого байта и такта процессора, а понятный и надежный код. Поэтому в проекте разрабатывают под Embedded Linux и в качестве основного языка используют C++ в его современном варианте - C++17, активно поглядывая на фичи из стандарта 20-го года и новее (интересно, через сколько в комментарии к статье придут любители Rust?).

Иногда запускаются новые проекты на той же платформе, с теми же процессами и с переиспользованием многих уже существующих компонентов, и тогда в эти проекты мы ищем программистов, с учетом вышесказанного - программистов на C++. В embedded, тем не менее, чистый C все еще очень популярен, и нередко собеседоваться на вакансию C++ Developer'а приходят именно сишники. Логика у человека простая: языки, на первый взгляд, довольно близкие и почти обратно-совместимые, базовый синтаксис одинаков, про ООП кандидат что-то слышал, и значит, основная база уже есть и он сможет легко освоить C++ за 21 день в процессе работы, поэтому можно наплести про "с C++ тоже работал", начать писать на "Си с классами" и все получится. В то время как в новой команде таких "бывших сишников" уже и так набралось несколько, и такой вариант нам не подходит, требуемый кандидат на оставшиеся позиции - именно опытный плюсовик-затейник, который будет активно внедрять best practices и наставлять на code review на путь истинный менее опытных коллег.

Не смотря на кажущуюся схожесть языков, чем лучше ты знаешь каждый из них, тем больше ты понимаешь, что они очень разные, и в итоге разработчика на C от разработчика на C++ можно легко отличить на интервью или ревью, и мы даже набросали список пунктов, которые выдают сишников при собеседовании на C++-позицию. Итак, если вы всю жизнь писали на C, а потом перепрыгнули на C++, то скорее всего вы...

1. Пишете в резюме сразу оба языка вместе как "C/C++";

2. Используете <stdint.h>, <string.h>, <stdio.h> вместо <cstdint>, <cstring>, <cstdio>;

3. Используете malloc() и free() кроме явно предназначенных для этого мест (типа кастомных аллокаторов);

4. Используете ручное управление памятью с new и delete, вместо RAII и умных указателей;

5. Используете char*-строки и функции <string.h> вместо std::string и std::string_view. (единственное исключение - строковые константы через constexpr). Используете функции из <time.h> вместо std::chrono. Используете функции из <stdio.h> вместо std::filesystem и потоков ввода-вывода. Используете <pthread.h> вместо std::thread.

6. Когда вам нужно имплементировать алгоритм или контейнер независимый от типа данных, которыми он оперирует, используете #define-макросы или void*-указатели вместо темплейтов;

7. Для объявления констант используете #define вместо const и constexpr;

8. Используете C-style массивы вместо std::array;

9. Используете NULL вместо nullptr;

10. Пишете (int)number вместо static_cast<int>(number);

11. Используете простые указатели на функции вместо std::function;

12. Используете простые enum вместо enum class;

13. Для функций, не изменяющих состояние объектов, не используете const при объявлении. Для функций, не кидающих исключения, не используете noexcept. Для конструкторов забываете explicit. Для деструкторов забываете virtual :)

14. При разработке в ООП-стиле, объявляете все члены класса как public;

15. Если вам нужно вернуть из функции несколько разных значений (например, результат работы и/или код ошибки), то одно из них вы возвращаете через return, а другое - по указателю или по неконстантной ссылки, вместо использования std::optional, std::pair/std::tuple (особенно хорошо в паре со structured binding) или просто возврата struct;

16. Объявляя новую переменную с типом-структурой везде пишете struct в имени типа, или наоборот, при объявлении новой структуры пишете typedef struct вместо просто struct;

17. Не используете неймспейсы при структурировании кода;

18. Используете union вместо std::variant (кстати, для каламбура типизации использовать union тоже нельзя, он нарушает active member rule);

19. Пишете реализации общеиспользуемых алгоритмов (foreach, transform, find_if, sort, lower_bound, и т.д.) вручную даже если они есть в <algoritm>;

20. При простой итерации по элементам контейнера пишете многословные конструкции вместо range-based for. Не используете auto и using в многословных конструкциях типов;

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