Доброго времени суток!
Постараюсь ответить покороче
Не отвечая на конкретные вопросы прозвучавшие здесь, я обобщу все один ответ.
Я не профессиональный программист, но считаю себя опытным программером, это у меня хобби, около 14 лет, но на гуру не претендую. Я писал программы от "Хелло ворда" до Игровых движков с графикой, звуком и тд очень сложные (порядка 20-25 тыс. строк), этим я не хвалюсь, но это говорит о том что мой опыт хоть чего то стоит, коим я решил поделиться с вами.
Сразу скажу для примера что мою последнюю программу состоящую из 4 классов и 1000 строк я написал фактически безошибочно и особо не парился с отладкой, сразу все заработало и вообще пишу программы в принципе без косяков, ну если только я сознательно не иду на них из за лени или прочих соображений
Раньше у меня были такие ситуации когда программа усложнялась так, что наверное Вассерман без 0.5 (а то и 2л
) как говорится не разобрался бы! И приходилось тупо удалять все и кодить заново!
От демагогии к делу! Как это у меня получается?
За все время у меня выработалась четкая система правил как нужно программировать, она лично моя, для меня, вы сами решайте как вам делать!
К любой задаче я подхожу так:
Первым делом ее надо максимально осознать! И даже когда проблема ясна я не тороплюсь набивать код! Необходимо собрать максимум информации о проблеме, особенно будет ли программа совершенствоваться или она конечная, сделали раз и на всегда!
Хорошо допустим все аспекты задачи мы обварили!
Существует шутка у программистов что 70% времени они делают программу лежа на диване и лишь 30% набивая код! И это так и есть у нормальных программеров!
Крайне важно хорошо понять решаемую проблему!
Следующим шагом надо понять что мы хотим от программы! Чтобы она частично решала задачу или полностью и нужна ли она вообще!
Ну допустим нужна
Далее я проектирую "каркас" программы, состоящий из логики и интерфейса.
Я как то отошел от всяких блок схем, они только захламляют мозг!
Надо просто и ясно нарисовать абстрактную схему (без всяких правил для блок схем) КАК ВАМ ПОНЯТНО, как будет действовать программа, и на какие части она будет разделена. Будет ли это несколько программ?
Далее под эту абстрактную схему работы программы ваяем интерфейс на бумаге, прямо рисуем основные окна и тд, не надо разрисовывать досканально, главное создать каркас!
Создание каркаса существенно облегчает дальнейшее написание программы и избавляет от кучи иттераций рефакторинга, переделок и тд!
Далее по принципу разделяй и властвуй я пытаюсь разделить программу на самодостаточные модули, куски, функции. Желательно чтобы они были самодостаточны, чтобы их можно было сделать отдельно и проверить их правильность, а потом использовать.
Когда все это сделано, можно себе представить как будет работать будущая программа, погонять примеры ее использование в голове.
И только когда программа существует в таком виртуальном, А ГЛАВНОЕ КОНЦЕПТУАЛЬНО ЗАКОНЧЕННОМ, виде я приступаю к ее реализации!
Помните: программа появляется из ИДЕИ а не из кода, ударов по клаве и часов просиженных за компом!
Теперь по коду:
Важно выполнять принцип повторного использования кода! Писать так чтобы его можно было потом понять или хотя бы было понятно как его использовать.
Необходимо чтобы интерфейс классов был понятным и классы были конструктивно законченными блоками программы.
Я пишу код с четко сформулированным форматом, пользуюсь нотациями именования переменных и конструирования названий функций.
Например текст в конструкциях подразумевающих под блок (например if, for, while и тд) текста я предваряю табуляцией, чтобы этот под блок выделялся из текста программы и сам текст программы тогда приобретает некую иерархичность. Если переменная находится в классе, она должна начинаться с m_ (member) если это float то m_f, если это переменная скорости m_fSpeed. Так же можно добавлять размерность переменной метры в сек допустим m_fSpeed_ms. Таким образом применение таких нотаций позволяет легко читать код и без комментариев, которые всеже желательны в программе хотябы в ключевых точках! Ненадо его сжимать в одну строку код должен быть читабельным.
В наименованиях я так же придерживаюсь правил.
Основным является установка на первое место более важного (глобального), на последнее менее важного. Например возьмем явлоко и банан, они оба фрукты, так и формируем названия m_FruitApple и m_FruitBanan. В данном примере это излишне, но иллюстрирует подход если нужно сформировать названия для сложных по смыслу объектов. В названия не обязательно должны входить существительные, могут и глаголы и тд.
Таким образом когда я пишу код, я не задумываюсь над операторами, как бы назвать переменную, форматом и прочей шелухой, так так у меня четкая система правил написания кода я сразу мысль перевожу в код не задумываясь!
Так же когда я читаю код, он сразу переводится в мысль!
Даже сложные нагромождения с таким подходом становятся понятными и читаемыми!
Я стараюсь не делать очень длинных функций их логику сложно понимать, все стараюсь разбить на части.
Так же важно знать набор типичных конструкций кода, всякие поиски и тд.
Так как у меня все программы имеют хорошо продуманную структуру они редко нуждаются в отладке я вообще ей редко пользуюсь
Это когда алгоритм криво продуман он не укладывается в голове, тогда и логика кода непонятна и мы прибегаем к отладчику!
Данная микро статья
не претендует на полноту изложения темы.
Надеюсь хоть кому-то помог
И чем мешает выделение ключевых слов (допустим для чистоты, что выделяются только они).
