[C++] Системный подход. Как Вы подходите к решению задачи?

[alexzk]

Сообщение от Alex11223

Я ничего не предлагаю, просто прошел мимо и увидел странный абзац )

И XP это ж не только TDD. Например единый стиль кода, рефакторинг, Continuous Integration тоже к нему относятся.

..вот кстати, рефакторинг в С++ нудно делать из-за дву-файлов (СРР + Н) и пре-компиляции. Т.е. желательно вообще заводить новые классы/шаблоны прям сразу, как понадобилось. А вдруг еще понадобится? Если не понадобится - не беда, компилятор сделает коротко, без дополнительных накладок.

[Alex11223]

Да

И еще из-за сложности языка для него мало хорошо работающих инструментов для рефакторинга и т.п. Типа как в IDE от JetBrains (Java, Питон и веб) или ReSharper для C# Visual Studio (для С++ ReSharper тоже есть уже, но хуже и сильно тормозит)

[Pavia]

Alex11223
Я согласен что абзац странный. Просто хотелось противопоставить дедукцию и индукцию. А в двух словах описать индукцию не удавалось. Поэтому и упомянул XP, так как этот подход является ярким представителем индукционного ведения разработки.

Например единый стиль кода, рефакторинг

А вот тут несогласен. Вы же сами дали ссылку. Единый стиль кода, рефакторинг и циклическая разработка это всё общие элементы разработки не важно XP или нет.

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

Единый стиль написания он есть везде. Не только в XP.
Применительно к С/С++, наиболее известными стандартами кодирования являются MISRA, HICPP, Google C++ Style Guide. И в первую очередь эти руководства направленны не только на оформление, сколько на избежание шибок и упрощения тестирования и понимания кода.
Тот же MISRA имеет реализацию в виде программы одной из static analyze tools. Не совсем понимаю как им удалось описать все правила, но видимо туда не вошли правила рефакторинга.

[Pavia]

..вот кстати, рефакторинг в С++ нудно делать из-за дву-файлов (СРР + Н) и пре-компиляции. Т.е. желательно вообще заводить новые классы/шаблоны прям сразу, как понадобилось. А вдруг еще понадобится? Если не понадобится - не беда, компилятор сделает коротко, без дополнительных накладок

Да ладно? Возьмите QT Creater и не мучайтесь там при изменяешь функцию появляться лампочка кликаешь по ней и изменения тут же вносятся во втором файле. Если CPP то в H. Если в H то в CPP. И вообще нажимаешь переименовать идентификатор он сразу заменяется везде. А также есть поиск использования и вхождения идентификаторов.

[alexzk]

Сообщение от Pavia

Да ладно? Возьмите QT Creater и не мучайтесь там при изменяешь функцию появляться лампочка кликаешь по ней и изменения тут же вносятся во втором файле. Если CPP то в H. Если в H то в CPP. И вообще нажимаешь переименовать идентификатор он сразу заменяется везде. А также есть поиск использования и вхождения идентификаторов.

Беру и не мучаюсь, но, например, в CPP файлах часто делаю какойто
#define SOME
....using SOME
#undef SOME

(борюсь с копипастой по мере сил), так вот уже этого креатор не найдет (если есть использвание цели рефактора в макросе)

Кстати дарю трюк Бывает, нужно описать громадное число одинаковостей - ну например, прототип виртуальной функции в 20 наследниках. Так вот, сам этот прототип можно задефайнить локальненько и избежать копи-пасты, использовать вроде так

PROT(Class1)
{
}

PROT(Class2)
{
}

и т.д.
С темплейтами может не взлететь, если у вас есть указатели на базу только.
Когда такое бывает? Например - глобальные настройки. Контроллов GUI там разных может быть валом, в зависимости от типа хранимых данных, а хочется настройку задать просто, например массивом чего-то.

[8Observer8]

Сообщение от KAMLS

Да я учусь еще только. Именно ООП С++.
Поэтому сразу систему какую-то хочу "впаять" себе.

Изучайте шаблоны проектирования.

[KAMLS]

Спасибо всем. Буду применять советы.

[jura_k]

От фонаря.
Смотрю, сколько надо переменных. Потом гляжу, объявлены ли они, или требуются дополнительные.
А иногда в конце решения задачи оказывается, что какие-то переменные были не нужны.
http://programmersforum.ru/showpost....3&postcount=68

[alexzk]

Сообщение от jura_k

От фонаря.
Смотрю, сколько надо переменных. Потом гляжу, объявлены ли они, или требуются дополнительные.
А иногда в конце решения задачи оказывается, что какие-то переменные были не нужны.
http://programmersforum.ru/showpost....3&postcount=68

Лично вам стоит изучить "область видимости переменных" Последние лет 25 в С++ (и всех потомках) можно создавать переменные в момент нужды, и ограничивать их существование блоками. Т.е. за раннее ничего выписывать не нужно.
Предварительное описание - это тяжкое наследие первых версий С (70х годов), когда у функции не было параметров, и описание переменных выполняло 2 роли - описать параметры, а что не использовано параметрами - оставить как переменные.

[jura_k]

Насчёт "видимости переменных" в блоках я в курсе, и эта штука прокатывает даже в Turbo C 2.0 (правда, я не пробовал).
Объявление переменных "в момент нужды в них" начинается с C++.

Мне сложно перестроить своё мышление.
Если мне нужны всего пять переменных для решения кучи задач, и я вижу, что все переменные занимают явно меньше 30 килобайт - то я в начале main () и описываю их. Потому что памяти компьютеру явно хватит. - Не так уж много в учебных программах надо.