Здесь приводится набор правил, которых вам хорошо бы придерживаться изучая С++. Когда вы станете более опытны, вы можете превратить их в то, что будет подходить для вашего рода деятельности и вашего стиля программирования. Они умышлено сделаны очень простыми, поэтому подробности в них опущены. Не воспринимайте их чересчур буквально. Написание хороших программ требует ума, вкуса и терпения. Вы не собираетесь как следует понять это с самого начала, поэкспериментируйте!

1. Когда вы программируете, вы создаете конкретное представление идей вашего решения некоторой задачи. Пусть структура отражает эти идеи настолько явно, насколько это возможно:

a) Если вы считаете «это» отдельным понятием, сделайте его классом.

b) Если вы считаете «это» отдельным объектом, сделайте его объектом некоторого класса.

c) Если два класса имеют общим нечто существенное, сделайте его базовым классом. Почти все классы в вашей программе будут иметь нечто общее. Заведите (почти) универсальный базовый класс, и разработайте его наиболее тщательно.

2. Когда вы определяете класс, который не реализует некоторый математический объект, вроде матрицы или комплексного числа, или тип низкого уровня, вроде связанного списка, то:

a) Не используйте глобальные данные.

b) Не используйте глобальные функции (не члены).

c) Не используйте открытые данные-члены.

d) Не используйте друзей, кроме как для того, чтобы избежать [a], [b] или [c].

e) Не обращайтесь к данным-членам или другим объектам непосредственно.

f) Не помещайте в класс «поле типа», используйте виртуальные функции.

g) Не используйте inline-функции, кроме как средство существенной оптимизации.

Замечания для программистов на C

Чем лучше кто-нибудь знает C, тем труднее окажется избежать писания на С++ в стиле C, теряя, тем самым, некоторые возможные выгоды С++. Поэтому проглядите, пожалуйста, раздел «Отличия от C» в справочном руководстве (#с.15). Там указываются области, в которых С++ позволяет делать что-то лучше, чем C. Макросы (#define) в С++ почти никогда не бывают необходимы, чтобы определять провозглашаемые константы, используйте const (#2.4.6) или enum (#2.4.7), и inline (#1.12) – чтобы избежать лишних расходов на вызов функции. Старайтесь описывать все функции и типы всех параметров – есть очень мало веских причин этого не делать. Аналогично, практически нет причин описывать локальную переменную не инициализируя ее, поскольку описание может появляться везде, где может стоять оператор, – не описывайте переменную, пока она вам не нужна. Не используйте malloc – операция new (#3.2.6) делает ту же работу лучше. Многие объединения не нуждаются в имени – используйте безымянные объединения (#2.5.2).

Библиографические ссылки

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

[1] A.V. Aho, J.E. Hopcroft, and J.D. Ulman: Data Structures and Algorithms. Addison-Wesley, Reading, Massachusetts. 1983.

[2] O-J. Dahl, B. Myrhaug, and K. Nygaard: SIMULA Common Base Language. Norwegian Computer Center S-22, Oslo, Norsay. 1970

[3] O-J. Dahl and C.A.R. Hoare: Hierarchical Program Construction in «Structured Programming.» Academic Press, New York. 1972. pp 174-220.

[4] A. Goldberg and D. Robson: SMALLTALK-80 The Language and Its Implementation. Addison-Wesley, Reading, Massachusetts. 1983.

[5] R.E. Griswold et.al. The Snobol4 Programming Language. Prentice-Hall, Englewood Cliffs, New Jersey. 1970.

[6] R.E. Griswold and M.T. Griswold: The ICON Programming Language. Prentice-Hall, Englewood Cliffs, New Jersey. 1983.

[7] Brian W. Kernighan and Dennis M. Ritchie: The C Programming Language. Prentice-Hall, Englewood Cliffs, New Jersey. 1978. Русский перевод в: Б.В. Керниган, Д. Ритчи, А. Фьюэр. Язык программирования Си. М.: Финансы и Статитика. 1985.

[8] George Orwell: 1984. Secker and Warburg, London. 1949. Русский перевод: Дж. Оруэлл. 1984.

[9] Martin Richards and Colin Whitby-Strevens: BCPL – The Language and Its Compiler. Cambridge University Press. 1980.

[10] L. Rosler (Chairman, ANSI X3J11 Language Subcommittee): Preliminary Draft Proposed Standard – The C Language. X3 Secretariat: Computer and Busineess Equipment Manufacturers Association, 311 First Street, N.W, Suite 500, Washington, DC 20001, USA.

[11] L.Rosler: The Evolution of C – Past and Future. AT amp;T Bell Laboratories Technical Journal. Vol.63 No.8 Part 2. October 1984. pp 1685-1700.

[12] Ravi Sethi: Uniform Syntax for Type Expressions and Declarations. Software Practice amp; Experience, Vol 11 (1981), pp 623-628.

[13] Bjarne Stroustrup: Adding Classes to C: An Exercise in Language Evolution. Software Practice amp; Experience, 13 (1981), pp 139-61.

[14] P.M. Woodward and S.G. Bond: Algol 68-R Users Guide. Her Majesty's Stationery Office, London. 1974.

[15] UNIX System V Release 2.0 User Reference Manual. AT amp;T Bell Laboratories, Murray Hill, New Jersey. December 1983.