AlexandrY (07.08.2007 12:02, просмотров: 1) ответил Evgeny_CD на Шесть советов по написанию более понятного программного кода ->
А теперь наш ответ. Шесть альтернативных советов... Приближено к реальным условиям при программировании встраиваемых систем на C.
Очень важный момент - это в каком редакторе все это делается.
Я, например, применяю активный способ работы с исходниками в SlickEdit
1. Главное стиль.
Сразу привожу форматирование текстов к своему стилю.
Отступы, расстановки скобок, выравнивания и т.д. Это позволяют делать сейчас многие редакторы автоматически.
Мы же экономим свое время. Думать о всех невозможно.
2. Не зацикливаться на именованиях.
Если глубоко задумываться каждый раз когда надо понятно назвать переменные или другие составляющие программы, то время действительно утечет как вода. Поэтому при написании именуем как придется.
Позже с помощью инструментов рефакторинга я могу поменять имена хоть десяток раз во всех текстах безболезненно и одновременно.
3. Опасность комментариев.
Комментарии должны отражать только идеи или даже философию. Т.е. почему мы решили написать ту или иную функцию, как она встроена в конструкцию всего приложения. Остальную смысловую нагрузку должны нести именования структурных составляющих программы.
Комментрарии не поддаются рефакторингу. И при активной работе с исходниками быстро становяться неактуальными и даже ошибочными если в них упоминается какая либо конкретика в отношении выполняемых действий.
4. Комментировать только когда нужно.
Комментрование реально занимает время и иногда отвлекает.
Один из способов минимизировать комментированияе это комментировать on-demand. Т.е. вы отлаживаете код и еще его помните, но уже чувствуете, что реализация не очевидна. Тогда обязательно надо прокомментировать.
5. Удобно применять единый стиль интерфейса функций.
Например недавно я принял такой стиль: все более или менее сложные функции по return возвращают код состояния и ничего другого. Все остальное возвращаеться по указателям на аргументы. Коды состояний наследуются как правило от дефайнов применяемой операционки.
Тогда даже через цепочку из 10-и вызовов можно проследить некорректное состояние которое передала самая нижняя функция.
(Некая эмуляция исключений как в C++)
6. Не давать разрастаться библиотеке типов.
Каждые новые сторонние исходники обычно вносят свои дефайны типов.
Задача сохранения их дефайнов нетронутыми приводит к затяжным разборкам с изоляцией новых исходников от основных текстов и написание прокладок.
Проще сразу провести рефакторинг и привести все типы к единым именованиям. Это приведет к несовместимости с последующими апгрейдам сторонних исходников, но апгрейды это только потенциальная угроза, а маразм с типами - реальная.
)
)