С-стильпротив шаблонов проектирования.

Поскольку язык С является в некотором роде подклассом языка С++ (подклассом в математическом смысле), у людей знакомых с С, но плохо знакомых с С++ есть большой соблазн писать на С++ в С-стиле. С-стиль - это предпочтение функций классам (в крайнем случае - функциональное программирование), широкое использование указателей и явного приведения типов. Программы, написанные на С, обладают большей переносимостью, быстрее собираются и скомпилированный код оказывается более эффективным. Многие программы до сих пор пишутся в С-стиле. С-программы более читабельны, взаимосвязи между частями кода оказываются более наглядными. Однако при всех плюсах С значительно менее безопасный и значительно более низкоуровневый язык по сравнению с С++.
Противоположный уклон - мощное использование С++ механизмов, в частности механизмов объектно-ориентированного проектирования: наследование, агрегация. Используя, в частности, шаблоны проектирования можно моделировать сложное поведение системы набором стандартных приемов. Такой код будет проще поддерживать и расширять, но только для того, кто уже знаком с системой. Динамические механизмы очень неочевидны и ненаглядны, для их понимания необходимы диаграммы состояний классов, например как в языке UML, без дополнительной информации сложную объектно-ориентированную систему трудно понять.
3.Объемные комментарии против программирования без комментариев.
Значительно повысить ясность кода помогают комментарии. Код без комментариев не является коммерческим кодом. Классическая школа рекомендует подробно комментировать каждый класс и все публичные методы класса, а также переменные, если таковые есть, плюс обязательны комментарии для внутренних методов и переменных, а также внутри функций необходимо комментировать особо сложные и важные моменты. Существует подход, предлагающий прежде чем писать функцию, описывать ее поведение подробно в комментарии. Опять же, современный подход, в частности некоторые аспекты экстремального программирования, советуют избегать комментариев - комментарии подталкивают к тому, чтобы писать более непонятный код (мол, из комментария и так ясно что происходит), кроме того, комментарии быстро устаревают, если код интенсивно развивается, тем самым порождая несоответствие документации коду. Код, с этой точки зрения, должен быть ясен, четок и развернут так, как если бы вы писали не сам код, а комментарий к нему.

4. Использование библиотек против системного программирования.
Корень этого вопроса состоит в том, что часто внешние библиотеки дублируют функциональность системы, создавая обертки к системным классам и функциям. Само по себе это неплохо - обычно в обертки входят дополнительные средства обеспечения безопасности и более удобный интерфейс, например за счет скрытия деталей. Однако это порождает проблему выбора. Обычно в таких случаях советуют использовать библиотеки высокого уровня. Например, если вы под Borland C++ Builder пишете работу с таймером, скорее всего вы будете использовать компоненту TTimer, а не системный таймер.
Дополнительные вопросы возникают при возможности работы со сторонними библиотеками. Если кроме системного и встроенного классов существует дополнительная библиотека утилит, в которой реализованы те же возможности, возникает вопрос производительности и удобства. Пример - использование переменной для строк. Это может быть char*, AnsiString или std::string. Первый вариант не слишком удобен для использования, в том числе и потому что другие два варианта имеют возможность приведения к первому, при этом предоставляя дополнительные возможности. Однако выбор между вторым и третьим вариантом не столь однозначен. Решать какой именно библиотекой пользоваться в таком случае по обстоятельствам. В частности, анализ для каких целей используется класс, и в какой библиотеке поддержка его именно с этой точки зрения выше.
Вывод: главное - единообразие.
Какой-то определенный стиль программирования не является ни панацеей от ошибок, ни признаком высшего мастерства. Вы можете выбрать для себя любой стиль, и твердо следовать ему, совершенствуя приемы и доводя до автоматизма решения простых задач. Однако какой бы стиль вы ни избрали, необходимо учитывать то, что вы работаете в команде, и в ваш код будут вносить изменения другие люди и наоборот, вы вносите изменения в чужой код. Вы пишете в команде с другими людьми, которые также хотят твердо придерживаться своего стиля программирования, которые учатся на своих ошибках и доводят до совершенства свой стиль. Программа, написанная единообразно, будет смотреться гораздо более качественной и красивой, чем программа, в которой куски кода в С-стиле перемежаются с объектно-ориентированными паттернами. Существуют красивые программы в венгерской нотации и системными вызовами без малейшего упоминания библиотек высокого уровня MFC, VCL, .NET. Существуют ужасные программы на платформе .NET 2.0. Какой будет программа, попавшая в ваши руки - решать вам.

Необходимо

Надо выработать один стиль - некий стандарт, особенно если над одним кодом работает команда, чтобы при передаче кода, другой разработчик без проблем мог в нем ориентироваться. В настоящее время наличие развитых методов программирования, достаточный объём информации о программировании, позволяет организовать процесс обучения программистов с "насаждением" определенного стиля программирования (как это делается при изучении "родного" языка — прививаются навыки "грамотного" письма). Это наиболее простой, легкий и проверенный путь избавления от стилевых конфликтов, позволяющий получить программистов, умеющих писать красивые программы и облегчить им в будущем тернистый путь превращения в профессионалов. Крайне желательно для насаждения красивого стиля программирования использовать в качестве примеров программы, разработанные "гуру" программирования. Образцы программ, как правило, поставляются в виде example в составе систем программирования. Для языков Си, С++ очень хорошими примерами являются системные программы среды UNIX, в частности, LINUX.

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

Контрольные вопросы