В этой статье хочется рассказать об этике
программирования. Опытные программисты,
судя по исходникам, могут определить
уровень знаний непосредственно
программиста. Как? А очень просто. Есть
достаточно много негласных правил, так
называемой этикой программирования. Зачем
нужна эта этика, мы и погорим в данной
статье.
Часть1: Сага о комментариях.
Ну что ж, если вы когда-нибудь видели
исходные тексты программ, а тем более
программировали, вы прекрасно знаете, что
такое комментарии. Но почему же тогда кто-то
использует их несколько чаще других? На
самом деле, при написании программ очень
полезно оставлять комментарии.
- Во-первых, для самого себя. То есть для
удобства навигации по своему же коду.
Чёткие и уместные комментарии способны
сохранить программисту до нескольких часов
времени только лишь из-за того, что он не
будет думать лишний раз, за что отвечает
каждая часть текста.
- Во-вторых, для последователей. Если
человек разрабатывает программу под заказ,
зная, что исходные тексты позднее будут
переданы заказчику. Есть ли гарантия, что
именно вы будете дорабатывать эти
исходники до следующей версии? А сторонний
человек должен будет потерять очень много
времени, чтобы понять, что да как. То ли дело
с комментариями. Читать программу на
русском языке (в крайнем случае на
английском) гораздо проще, чем на языке
программирования. Особенно если программа
использует достаточно сложные
синтаксические конструкции.
Вот вам две немаловажные причины, по
которым комментарии должны писаться.
Отсюда вполне логичный вопрос: как же
писать комментарии правильно? В введении
книги "Экстремальное программирование",
её автор, Кент Бек, частично отвечает на наш
вопрос. Он пишет:
- Если пересмотр кода - это хорошо, значит, мы
будем пересматривать код постоянно
- Если тестирование - это хорошо, значит,
каждый участник проекта будет тестировать
код программы постоянно (тестирование
модулей), даже заказчики (функциональное
тестирование).
- Если комментировать код - это хорошо,
значит, мы будем уделять комментариям
внимания ровно столько, сколько
потребуется, чтобы наш код стал лёгким для
чтения даже ребёнку.
Из данных строк видно, что комментарии
нужны, и их нужно ровно столько, сколько
нужно. Да, красиво это я загнул, но судите
сами. Нельзя сказать: На 10Kb кода должно
приходиться 2Kb комментариев. Это было бы
глупо. Следовательно, остаётся только одно:
писать комментарии "в тему", раскрывая
с их помощью наиболее заковыристые области
программы. Не следует забывать, что
комментарии НИКАК не влияют на работу
компилятора, ровно как и на размер
получившейся программы. Комментарии
игнорируются компилятором, однако очень
помогают нам, людям.
Часть2: Сага о коде.
Если вам приходилось писать программы, вы
наверное знаете, что на данный момент
большинство компиляторов лояльно
относятся к стилю записи программы. То есть
компилятору по боку, будете вы ставить
символ переноса строки или нет. Судя по
всему вышесказанному, к одинаковому
результату приведёт Код[1] и Код[2]:
Код[1]:
begin
WriteLn('Hello, world');
end.
Код[2]:
begin WriteLn('Hello, world'); end.
Если не верите, можете проверить сами. Та же
ситуация с Си - компиляторами. Расскажу одну
историю, происшедшую со мной несколько лет
назад: Один мой знакомый хвастался
написанной им программой (он писал на С). В
ответ на это я сказал ему, что эта программа
пишется на Паскале в три строки. Он был
взбешен, потому как также как и я мог
написать эту программу на Паскале, но не в
три строки - это точно (в 15-20 где-то ).
Пришлось показать человеку всё силу логики,
и программа действительно заняла ровно три
строки. Почему 3, а не одну? Не знаю как в Си,
но в Паскале максимальная длина строки - 256
символов (поправьте меня если я не прав ).
Следовательно, моя программа заняла
примерно 256 * 3 символов (это ровно столько же,
сколько потребовалось бы моему другу для
написания такой же программы). Этот пример я
привел не зря: мой код был АБСОЛЮТНО
нечитабельным. Рассмотрение и правка его в
дальнейшем - это не то чтобы извращение, это
камасутра полная. Если кому приходилось
играть в Quake3 и сохранять из игры свой конфиг
- меня поймут. Квака по умолчанию пишет всё в
одну строчку, а разделителем ставит какой-то
глупый символ. Это никак не может
сравниться с конфигом, написанным вручную,
с комментариями, и т.д. Следует запомнить на
всё жизнь: хочешь добиться уважения со
стороны других - делай свой код более
читабельным. Чем больше свободного места
между строками - тем легче читать код.
Следовательно это - наш выбор. ВСЕГДА пишите
математические знаки ( + - = * / ) через пробел.
То есть примерно так, как написано во врезке
Пр[1], и никогда так, как написано во врезке
Пр[2]. Итак, читаем и запоминаем:
Пр[1]:
iCounter + iChan := iRoute;
Пр[2]
iCounter+iChan:=iRoute;
Если честно, я с трудом набрал Пр[2]: привычка
выработалась настолько, что Space я давил уже
подсознательно. Желаю и вам того же...
Часть3: Сага о переменных.
Что можно сказать о переменных? На самом
деле, очень многое. Например, вы заметили,
что во врезках Пр[1] и Пр[2] я несколько
необычно назвал переменные? Нет, это для вас
необычно. Для меня это вполне нормальные
названия. К примеру, смотря на название
переменной iCounter, я могу смело сказать, что
это не счётчик Интернетов (иначе он
назывался бы iInetCounter или iICounter), а переменная
типа Integer, которая является чьим либо
счётчиком. Первая буква "i" обозначает
тип переменной: i: Integer, s: String, c: Char, b: Boolean и т.д.
и т.п. Таким образом, я делаю код более
понятным для себя. Для удобства навигации
других людей по вашему коду, в начале
программы опишите, по какому принципу вы
называете переменные. Это повысит ваш
профессиональный уровень программирования.
Следующее, что хотелось бы сказать о
переменных - давайте им осмысленные имена.
Именовать переменную "a" или "x"
глупо, не считая тех случаев, когда "a" и
"x" - элементы уравнения. В противном
случае называйте переменные осмысленно,
чтобы их имя примерно отображало принцип
действия переменной. Лучше всего называть
переменную полными либо сокращёнными
словами английского языка. Это позволит
быстрее ориентироваться в вашем коде не
русскоязычному населению планеты. Каждое
слово желательно начинать с заглавной
буквы. Что касается объектно-ориентированных
языков, которые так и норовят назвать
компоненты тупыми именами, я могу сказать
единственное: откажитесь от стандартных
Edit1, Label1 и т.д., поскольку когда число
одинаковых компонентов зашкалит за 5, будет
весьма нелегко держать в голове, что
обозначает номер какого-то компонента.
Называть я советую компоненты также как и
переменный, с той единственной разницей,
что вместо типа переменной, на первое место
ставить сокращённое название класса
компонентов. Так, например, Edit14, в который мы
вводим пароль, будет именоваться edPassEnter или
что-нибудь схожее с этим. Желательно в
комментарии перед текстом программы
описать, что обозначает то или иное
сокращение (ed: Edit; lb: Label).
Часть4: Сага о конце концов.
По моему скромному мнению, все возможные и
невозможные аспекты элементарной этики
программирования в данной статье я
рассмотрел. Я нарочито не стал упоминать о
конкретных особенностях различных языков,
а ограничился лишь описанием внешнего вида
кода, и последствий, которые бывают из-за
неумения или нежелания читать подобные
статьи. О том, как сделать код более
оптимизированным, я напишу отдельную
статью, потому что в этой я решил не
затрагивать столь галантный вопрос. Что ж,
остаётся лишь пожелать удачи тем, кто не
знал всего вышеизложенного, и теперь знает.
Буду надеяться, что кому-то данная статья
показалась интересной.
На этом всё...
Все права принадлежат c0d3x (C).
