Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Степанов Е.О. -> "Стиль программирования на С++ " -> 3

Стиль программирования на С++ - Степанов Е.О.

Степанов Е.О., Чириков С.В. Стиль программирования на С++ — Спб.: ГИТМО, 2001. — 48 c.
Скачать (прямая ссылка): stilprogrammivaniya2001.pdf
Предыдущая << 1 .. 2 < 3 > 4 5 6 7 8 9 .. 14 >> Следующая


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

6 1. СТАНДАРТИЗАЦИЯ - ЭТО ВАЖНО

Стандартизация становится неизбежной, когда процесс разработки программного обеспечения принимает промышленный характер. То есть:

• когда в работе над проектом участвует достаточно многочисленный коллектив разработчиков;

• когда проект состоит из нескольких «подпроектов», и отдельные исполнители не знают детально, чем, собственно, они занимаются. Каждый делает свой фрагмент, а целую картину представляет себе лишь руководитель проекта и несколько ведущих специалистов. Такая система работы особенно популярна в «почтовых ящиках» - организациях, работающих по государственным, как правило, оборонным заказам;

• когда в процессе работы происходит ротация персонала, кто-то увольняется, появляются новые сотрудники, которых нужно быстро ввести в курс дела;

• наконец, должны быть некие общие правила поведения, без которых невозможна слаженная работа коллектива разработчиков и их взаимодействие с заказчиками.

Одним словом, если вы занимаетесь разработкой достаточно большого и длительного проекта, вам придется следовать правилам работы того коллектива, в котором вы работаете.

Если проект имеет, например, научный (а не «промышленный») характер, все равно вам следует придерживаться общепринятого стиля, если вы, конечно, ожидаете, что ваша работа заинтересует других, и кто-то захочет разобраться в ваше программе. Чем более «оригинально» вы оформите свой код, тем меньше окажется желающих в нем разобраться.

Наконец, если вы пишете программу «для себя», вам неизбежно придется неоднократно возвращаться к ней для устранения ошибок или развития программы. Нередки случаи, когда, заглянув в свой проект через пару недель, программист уже не помнит, с какой целью он написал тот или иной фрагмент кода. Такого не случится, если программа будет прокомментирована.

2. ИМЕНА

Имя - результат размышлений, в основе которых лежит понимание работы системы в целом. Имя должно соответствовать тому свойству или процессу, который оно обозначает.

7 • Имена должны быть осмысленными и понятными.

• Имена должны быть построены на основе английских слов.

• Избегайте использования имен переменных и функций, составленных целиком из больших букв.

• Имена констант следует задавать только большими буквами.

2.1. Имена классов

• Имя класса должно соответствовать тому объекту, который описывает данный класс.

Пример:

class CInterpolator // интерполятор

class CSummer // сумматор

class CConicInterpolator // конический интерполятор

class ClinearInterpolator // линейный интерполятор

• Имя класса должно начинаться с буквы "C", что означает "class". Это традиция фирмы Microsoft, другие фирмы могут использовать другую литеру. Например, фирма Borland использует букву "T".

• Если имя класса состоит из нескольких слов, каждое слово должно начинаться с заглавной буквы.

Пример:

class CConnectionPointForMyOcx;

• Имена, объединяющие в себе более трех слов, использовать не рекомендуется. Длинные идентификаторы затрудняют чтение программы.

Пример:

class CSemaphorForMyNewPort;//слишком длинно и сложно class CNewPortSemaphor; // уже лучше

• Имена производных классов не должны содержать в себе имен родительских классов, каждый класс должен иметь собственное имя, кем бы он ни порождался.

• Имя класса должно начинаться с заглавной буквы. Если имя класса состоит из нескольких слов, каждое слово должно начинаться с заглавной буквы, которая служит разделителем слов.

8 2.2. Имена библиотек классов

• Чтобы избежать конфликта имен с другими библиотеками классов, используйте для своей библиотеки некоторый уникальный префикс.

• Длина префикса не должна превышать трех символов.

• Классы, производные от стандартных С++ библиотек, должны иметь тот же префикс, который используется этими библиотеками. Например, префикс "C" используется библиотекой MFC (class CWnd), префикс "T" используется библиотекой OWL (class TWindow).

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

Пример:

class ArcNewPortSemaphor // Arc - от "ARCADIA" class NitOldPortSemaphor // Nit - от "NITA"

2.3. Имена методов класса

• Используйте те же правила, что и для имен классов.

• Имя не должно напоминать ругательство. Длинное имя обычно лучше, чем короткая аббревиатура, однако не следует злоупотреблять.

• Обычно каждый метод и функция выполняет некоторое действие, поэтому имя должно описывать это действие:
Предыдущая << 1 .. 2 < 3 > 4 5 6 7 8 9 .. 14 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100