Я работаю над проэктом, который писали множество программистов уже лет 15 как, и до сих пор вставляем новые возможности, исправляем старые(вносим новые :) ) ошибки.
Глядя на исходные тексты, точнее на их халтурность, я не могу понять: толи некоторые(большинство из них) программисты не владеют языком С++, толи они специально пишут запутанно, чтобы только они и могли там разобраться. Некоторые из этих программистов до сих пор работают на фирме, и стиль их нисколько не поменялся.
Например, копируют куски кода, вместо того чтобы оформить в виде функции и вызывать её. Используют #definы или константы, там где по смыслу надо использовать enum. В качестве битовых масок тоже используют DWORD, long - но только не enum! И частенько встречаешь "волшебные" константы прямо в коде без каких либо комметрариев, типа 0x00200. И попробуй пойми, чего сие значит. (Разобраться конечно можно, но сходу не понятно, и нужно тратить время чтобы понять).
Я сейчас много меняю таких мест, вместо DWORD(и т.п.) ставлю конкретный тип (enum), глядя на который сразу видно какие значения могут быть.
А вы как думаете, нужно ли писать код интуитивно понятный (а стало быть лёгкий в поддержке и для других программистов) или лучше шифровать (чтобы другие попотели пока поймут)?
Дело в том что если ты успеешь написать кучу "зашифрованного" кода, то на фирме ты будешь незаменимый человек, единственный способный делать в нём изменения :).

Быдлокодеры
Увы и ах... Они повсюду...

Может они выросли из asm программистов а привычки остались!?
1. не факт что enum лутше для битовых масок.
2. Тем более если работать например с MAPI. Там все маски в DWORD
ну и при программирование для CE платформ битовая маска например комбинаций дней недели в DWORD/long будет менее ресурсоемкой чем enum. Да и вообще как бы принято что битовые комбинации integer а не enum.
01000101 для меня более предпочтителен чем (Days::Monday | Days::Friday | Days::Sunday)
да и вообще в спецификациях языка ето не оговорено, так что тут все на любителя.

бональный loop разбитый на кучу функций - ето еще куда хуже. не факт что при компилирование оптимизация вызовов будет построена оптимально. так что процессор прыгающий на хз какие интервалы вместо sbs не есть гут.
Так что разбиение на функции или нет должно быть отдельно продумано для каждого проекта и т.д. и т.п.
Ну и само собой чем больше вы напишите код под себя тем дольше будет привязан заказчик к вам, что является весьма не хилым фактором в программирование. :)
P.S.: Все выше сказанное вообще фиолетово при написание калькулятора :)

man встроенные функции(inline)
а за копипасту расстреливать на месте надо.

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

На таком языке как плюсы трудно писать интуитивно понятный код :-)
Проблема в том что пишут на коленке, не продумывая архитектуру .
А константы использовать или перечисления - это мелочи.

про inline речи не было

А что такое " при компилирование оптимизация вызовов будет построена оптимально" ?
компилятор обычно с этим справляется лучше чем программист.
И почему по-твоему копипаста лучше чем встроеннье функции ?

1. не факт что enum лутше для битовых масок.
------
Лучше. Поименованные константы всегда будут лучше... ибо иначе их не вводили бы.
2. Тем более если работать например с MAPI. Там все маски в DWORD
------
Ну и? Проинициализируй заданные enum-константы... работа конечно не из приятных, но делать ее надо однажды...
01000101 для меня более предпочтителен чем
------
Ну и чем он для тебя лучше? Простой вопрос - есть две системы нумерации дней: европейская - с Понедельника... американская - с Воскресения... В принципе есть и еще одна - ирландская, для рабочих дней - со Среды... Как у тебя будет с порядком единичек при переделке?
бональный loop разбитый на кучу функций - ето еще куда хуже
------
Пссс... Была бы функциональность функций правильной и цикл легко читаемым/понимаемым, а куда там управление будет Juvp'ать - пофиг...
Ну и само собой чем больше вы напишите код под себя тем дольше будет привязан заказчик к вам
------
Чем больше ты успеваешь производить кода, тем больше у тебя заказчиков и тем чаще они к тебе возвращаются...
Ну подумай сам - пусть есть задачка объемом этак с 200Мб, под 1000 форм, 4-5 тыс типов объектов...
ты месяц роешься в хитром коде, пытаясь что-то поправить как надо заказчику...
или
за 10 минут делаешь нужную заказчику правку и через 20 минут генерации и компиляции готов передать заказчику требуемое...
Куда он пойдет?

На таком языке как плюсы трудно писать интуитивно понятный код :-)
------
Угу... на VB6 - лЯХко... прямо сейчас ищут писателя для _нового_ проекта...

как-то писал конечный автомат, который чё-та там парсил. На VB. Странное дело - не плевался.

А почему не на хакселе?

Конечный автомат, который парсит там чего-то, в зависимости от того, чего он там парсит
- LR(0), LL(1) или LARL - занимает 10-15 строк... если, конечно, не писать что-то типа
рекурсивного спуска и называть его автоматом...
Я уже описывал один VB6 проект... точнее - одну его форму, весом в ~250Кб... там мешанина
из управления элементами формы, локального пересчета значений и кусков SQL. Там никто
не в состоянии гарантировать, что изменения корректны...
Из того, что Я видел в других проектах и что ваял сам на Аксесе, система программрования
(плюс сроки и область применения) вынуждает лепить именно такой код. Изменить методику
можно, но это совсем не дешево...

мне нравится с++. А на каком языке проще писать понятный код?
А вот константы или перечисления - это совсем не мелочи, если говорить о программах посложнее Хелоуворда, хоть в пару тысяч файлов.
Я предпочитаю использовать конкретный тип(т.е. определённый мной) там где это возможно. DWORD это не конкретный тип, это может быть всё что угодно. Например параметр функции (DWORD dwMode) ни о чем не говорит. Какие значения может принимать dwMode? Может быть все возможные, т.е. от 0 до 0xFFFFFFFF ? Где искать константы или дэфайны которые могут быть использованы в качестве фактического параметра? Попробуй найди в сотне заголовков! Понять параметр можно только анализируя код функции, а если он там не используется(а только передаётся дальше), может придётся полазить в 20 других функций по стеку пока увидишь подстановку конкретной константы (что может быть и не возможным, если напр. она считана из файла), или придётся шагать внутрь 20ти других функций куда передается этот параметр пока не доберёшся до кода зависящего от этого dwMode. Другое дело если это не DWORD, а enum TMode. Глянув на него сразу видишь смысл этого типа, диапазон значений. К тому же мной опредёлённому типу можно присвоить значение только этого типа и никакого другого(если конечно я не разрешу), что есть гарантия от случайной ошибки типа: вместо дня недели подставил месяц.

для большинства задач лучше не думать об оптимизации, лучше думать о понятности кода. Потому что пользователю всё равно: отреагирует программа на нажатие энтера за 1милисекуну или за 10. Только там где это критично стоит думать. Но экономить на функциях (если применение их оправдано большей понятность программы) не стоит никогда. Ведь их можно и inline сделать.
В идеале, если кусочку кода (это может быть и одна строчка) можно присвоить имя (которое учавствует в мышлении программиста при описании алгоритма), то это участок кода должен быть оформлен в виде функции. Даже если вызов её встречается только один раз.
Если напр. 5 строк программы, которые можно было оформить в виде функции, всё же(как зачастую и бывает) являются просто строками некой большой функции, то через год какой нибудь программист вставит внутрь этих строчек свой код, а через год внутрь этих еще и т.д. Тогда каша получается - всё перемешано. А я такие каши вижу частенько.

Я выбираю плюсы если есть выбор только между c и c++.
Последнее время плотно занимаюсь питоном, вот на нем точно проще писать понятный код.
А также до кучи из мэйнстрима : шарп, джава.
Хотя плохому танцору...

А вот такой подход избавляет от случайных ошибок приведения целых чисел к перечислению.
class Month {
public:
static Month Januar() { return Month(1); }
....
static Month December() { return Month(12); }
private:
explicit Month(int);
};

питон никогда еще не пробовал. вот почитал чуть чуть и увидел это:
"Python поддерживает динамическую типизацию, то есть тип переменной определяется только во время исполнения."
что это значит? типа dynamic_cast в c++?
Но мне кажется что компилятор должен как можно больше делать во время компиляции(поменьше оставлять на время выполнения). т.е. выявлять ошибки несоотверствия типов.
Когда пишешь свою программу, во время написания можно всё протестировать. Но когда лазишь в огромной программе, которую не ты писал, и делаешь много изменений - нет возможности всё протестировать. Здесь безопастно полагаться только на компилятор, что он сообщит если что не так. А оставлять выявление проблемы на время выполнения - я бы не рискнул.
В с++ я предпочитаю и dynamic_cast не пользоваться(только за редкими исключениями). А в питоне получается только эта возможность и есть. Что то мне это не нравится...

"Полиморфизм (все функции виртуальные)."
копаясь в проэкте на работе обнаружил бездумное использование virtual функций. Программист 'просто так' сделал кучу функций виртуальными. На самом деле большинство из этих функций не использовались как виртуальные, т.е. наследники их не переопределяли. Дело в том что каждая виртуальная функция увеличивает трудность поддержки кода. Если я хочу изменить аргументы виртуальной функции, то мне нужно быть внимательным чтобы изменить его и у всех переобределённых функций наследников. А если я не замечу у насленика такую функцию - я сделал ошибку, которую компилятор не обнаружит, а вылезет она только во время работы.
Поэтому "все функции виртуальные" считаю недостатком языка.

Ты рассуждаешь о предмете о котором не имеешь ни малейшего представления .
dynamic typing

А зачем менять аргументы ? Просто перегрузи и используй свой вариант.

Еще раз повторяю, ты не имеешь понятия о чем рассуждаешь.