Алекс Jenter - Программирование на Visual C++. Архив рассылки

Старый файл AtlControls.h был включен из ATL в WTL, и содержит несколько новых классов для элементов управления W2K, наряду с некоторыми классами для элементов управления, не относящихся к Win32, таких как клон панели команд (command bar clone), кнопка с изображением (bitmap button), гиперссылка (hyperlink) и курсор "песочные часы" (wait cursor). […]

И, наконец, в библиотеке имеются служебные классы, самым значимым из которых является CString. Да, это клон класса CString из MFC, который реализует (насколько я знаю) все его методы. Еще есть класс-оболочка для поиска файлов (find file API) и классы-аналоги CRect, CSize и CPoint.

Если вы собираетесь писать Win32-приложение с пользовательским интерфейсом, я рекомендую вам попробовать WTL прежде чем думать об MFC. Если вы пишете код в WTL, он будет меньше в объеме и более эффективен, и вы будете иметь все преимущества поддержки COM в ATL, которая, увы, отсутствует в MFC.

Итак, WTL – очень перспективная библиотека на основе ATL, которая, однако, НЕ ИЗБАВЛЯЕТ вас, как программиста, от необходимости знания WinAPI. И я могу привести кучу доводов в пользу такой архитектуры, многие из которых достаточно очевидны. Но, как всегда, есть и аргументы contra. MFC намного мощнее, и имеет намного больше возможностей. Из них, в частности, модель "документ/представление", поддержка документов OLE, автоматизированный обмен данными, пристыковывающиеся панели/диалоги и многое другое.

Объем кода, который вам приходится писать самому, в WTL больше.

Не думайте также, что в WTL нет ошибок: как показывает практика, их там тоже полным-полно (я видел список известных на данный момент багов). Библиотека еще сыровата. Так что не следует переоценивать WTL, но и спускать со счетов тоже не стоит. Конечно, она пока не стала стандартом и официально Microsoft не поддерживается. Но, как говорят на западе, things can change. В нашей профессии всегда приходится держать ухо востро на все инновации, т.к. они имеют неприятную особенность становиться стандартами.

А что касается рассмотрения WTL в рассылке: в принципе я не против, если вы не против. Смущает меня только одно: тем для рассылки становиться настолькомного, что впору было бы создавать несколько рассылок, – одну про WinAPI, другую про MFC, третью про WTL, и т.д. Знаю, многие сочтут это просто отличной идеей, т.к. смогут подписаться именно на то, что их интересует. Но, к сожалению, я один, и физически не смогу все эти рассылки готовить, а помощников нет. Конечно, я буду стараться осветить самое важное и интересное. Как кто-то сказал, "нельзя объять необъятное… а если и можно, то только по частям и не сразу" ;) Так что давайте договоримся: пока будем придерживаться общепринятого стандарта – C++, WinAPI и MFC. А WTL (или C#, или чем-то другим) займемся, когда ее название будет фигурировать в объявлениях типа "требуется программист" чаще, чем MFC.

Читайте в следующем выпуске рассылки:

• Как правильно писать программы на C++: некоторые правила, которые помогут вам писать легко читаемый код.

• Рубрики "Вопрос-ответ" и "В поисках истины".

Также планируется в последующих выпусках:

• CPropertySheet: создание окон свойств и мастеров.

• Массивы, списки и ассоциативные списки. Общие положения и реализация в MFC.

• Решение проблемы с OnIdle в dialog-based приложениях.

• Работа с панелью инструментов. Задание вида кнопок и размещение отличных от кнопок элементов.

• Постоянные рубрики "Вопрос-ответ", "В поисках истины" и "Обратная связь".

До встречи!

Доброе время суток!

Сегодня мы с вами поговорим о такой вещи, как стиль программирования.

Если вам когда-нибудь приходилось разбираться в чужой программе, или даже в своей собственной, но написанной несколько лет назад, да еще когда поджимает время, вы скорее всего знаете, какая это неприятная и сложная задача. Порой бывает легче весь код написать заново (а многие так и делают). Конечно, существует поговорка "настоящие программисты не пишут комментарии: если программу было трудно написать, в ней должно быть трудно что-то понять и еще труднее что-либо изменить". О комментариях мы еще поговорим, печально то, что очень многие следуют этому принципу в самой программе. "Неважно", думают они, "как это написано, главное побыстрее проверить, работает ли это вообще". Самые прилежные из них впоследствии переписывают отдельные куски кода, но таких единицы. Большинство же, убедившись в работоспособности алгоритма, оставляют все как есть и переходят к новым задачам.

Как показывает многолетняя практика, это большая ошибка. Усилия, потраченные на "причесывание" кода, окупаются с лихвой. Но по-настоящему ценится умение писать сразу такой код, который не нуждается в причесывании. Это умение не приходит само по себе, а вырабатывается постепенно, в нем надо постоянно практиковаться. И когда вы говорите себе "а, это ведь просто небольшая утилитка для удобства, вот когда получу настоящий заказ – буду писать красиво", вы тем самым приучаете себя к неправильному стилю написания программ.

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

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

1. Обязательно соблюдайте отступы. Хотя Visual C++ и делает отступы автоматически, иногда они все же нарушаются. С их помощью сразу видна структура программы.

Кстати, многие знают, что для того, чтобы подвинуть блок текста вправо, нужно выделить его и нажать Tab, но почему-то даже не догадываются, что если нажать Shift-Tab, текст сдвинется влево! Попробуйте, это очень удобно. Лучше вместо символа табуляции использовать пробелы (Tools|Options|Tabs|Insert Spaces). Тогда ваши программы в любом редакторе будут с корректными отступами.

2. Про комментарии в коде я ничего говорить не буду… ну, почти ничего. Все, что можно было сказать, уже сказано до меня. Все равно лень людям их писать. Одно только вам посоветую: если уж сильно неохота сочинять комментарии 50/50 с кодом – все-таки постарайтесь самые ключевые и/или неочевидные моменты отмечать.

И запомните: неряшливый и запутанный код нужно не комментировать, а переписывать!

3. Именованные константы пишите в верхнем регистре, чтобы можно было мгновенно отличить их от переменных. Например, MAX_ELEMENTS и BORDER_WIDTH, а не Max_Elements и border_width.

4. Имена переменных начинайте с маленькой буквы, названия типов – с заглавной.