История изменений

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

Не надо называть то, что вы написали «Си-культурой». Это ровно наоборот.

1. Кодировать типы в именах программных объектов (переменных, функций) - это жуткий моветон, в 90-х этот подход практиковался и даже один из вариантов (венгерская нотация) стал внутренним стандартом кодирования Microsoft причём как для кода на C, так и для кода на C++. Если вы работали в компании, где насаждаются подобные соглашения о монструозном именовании, то вам просто не повезло, а автор гайда по стилю кодирования, видимо, считает WinAPI венцом творения программистов :) Но в целом он осуждается, почитайте, например, Линуса Торвальдса или Джоэла Спольски. На текущий момент модно читать Макконнелла, Мартина, Фаулера и именовать программные объекты просто и разумно. Единственное, в разработке на C чаще тяготеют к змеиному стилю, тогда как в C++ чаще предпочитают верблюжий. Но даже это не догма.

2. Если функция принимает большое количество параметров, обычно это говорит о плохом дизайне и спагетти-коде (и опять, привет, WinAPI). В хорошо спроектированной программе выполняется закон Деметры, low coupling и high cohesion.

3. Идеи ООП и даже ФП вполне себе симпатично реализуются на C, хотя, конечно, многословнее на уровне реализации. В C++, конечно, сахарок белее.

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

Не надо называть то, что вы написали «Си-культурой». Это ровно наоборот.

1. Кодировать типы в именах программных объектов (переменных, функций) - это жуткий моветон, в 90-х этот подход практиковался и даже один из вариантов (венгерская нотация) стал внутренним стандартом кодирования Microsoft причём как для кода на C, так и для кода на C++. Если вы работали в компании, где насаждаются подобные соглашения о монструозном именовании, то вам просто не повезло, а автор гайда по стилю кодирования, видимо, считает WinAPI венцом творения программистов :)

Но в целом он осуждается, почитайте, например, Линуса Торвальдса или Джоэла Спольски. На текущий момент модно читать Макконнелла, Мартина, Фаулера и именовать программные объекты просто и разумно. Единственное, в разработке на C чаще тяготеют к змеиному стилю, тогда как в C++ чаще предпочитают верблюжий. Но даже это не догма.

2. Если функция принимает большое количество параметров, обычно это говорит о плохом дизайне и спагетти-коде (и опять, привет, WinAPI). В хорошо спроектированной программе выполняется закон Деметры, low coupling и high cohesion.

3. Идеи ООП и даже ФП вполне себе симпатично реализуются на C, хотя, конечно, многословнее на уровне реализации. В C++, конечно, сахарок белее.