Совершенный код Любой дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям. Мартин Фаулер
Стандарт оформления кода — набор правил и соглашений, используемых при написании исходного кода на некотором языке программирования. Стандарт оформления кода обычно принимается и используется некоторой группой разработчиков программного обеспечения для единообразного оформления совместно используемого кода. Целью принятия и использования стандарта является упрощение восприятия программного кода человеком, минимизация нагрузки на память и зрение при чтении программы.
Зачем? Зачем нужны «правила хорошего тона» в программировании 1. Хорошо оформленный код легко читается. Это позволяет существенно сократить затраты компании на ввод в работу новых сотрудников. 2. Для сокращения затрат на поддержку долгоживущих проектов. При чтении хорошо оформленного кода легко вспомнить, что происходит в той или иной его части, даже если им не занимались несколько месяцев. 3. Для сокращения затрат на первичную отладку. Когда программист при написании кода следует определённым несложным правилам его оформления, это позволяет существенно снизить процент допускаемых ошибок. 1. По эстетическим соображениям.
Среда разработки Современные среды разработки умеют форматировать исходный код в соответствии с указанными настройками. Это позволяет не заморачиваться на форматировании, а дать команду IDE самой отформатировать код. Это можно сделать как для небольшого фрагмента, так и для всего файла. Автоформатирование средствами IDE - очень полезная возможность, которой следует пользоваться. При командной работе настройки форматирования должны быть доступны через систему управления исходниками всем членам команды, поэтому и автоформатирование будет давать одинаковый результат.
Фигурные скобки Плохо If (n<0) {alert('Степень ' +n+ ' не поддерживается'); } Допустимо в одну строку без скобок, если строка короткая If (n<0) alert('Степень ' +n+ ' не поддерживается'); Хорошо! If (n<0) { alert('Степень ' +n+ ' не поддерживается'); }
Длина строки Максимальную длину строки согласовывают в команде. Как правило, это либо 80, либо 120 символов, в зависимости от того, какие мониторы у разработчиков. Более длинные строки необходимо разбивать для улучшения читаемости. If (n<0) { alert('Степень ' +n+ ' не поддерживается, введите целую степень больше 0'); } Длина строки не более 80 символов
Почему 80? Такую ширину имели старые мониторы в текстовм режиме. Это ограничение было особенно важно когда мониторы (вместе с видеосистемой) еще не имели графического режима. И поэтому было принято стараться вмещать текст программы в 80, а еще лучше в 78 или даже 76 символов. Меньше 80 было принято использовать потому, что на некоторых не очень качественных мониторах правая и левая сторона или сильно искажались или вообще скрывались за кожух. Помимо мониторов такую ширину имели принтеры. Конечно, были и широкие принтеры. Но наиболее доступные принтеры расчитанные на бумагу формата А 4 или рулон такой же (210 мм) ширины аккуратно пропечатывали на бумаге те же 80 символов. Более того, на перфокарте тоже вмещалось 80 символов.
Пробелы используются для форматирования отступов, пространства вокруг операторов, подписи функций и размещения аргументов функций. Конечно, это не все случая, где используются пробелы, но это должно дать вам представление о местах, где пробелы могут быть использованы для улучшения читабельности. Хорошо! Пытался как лучше… А тут и вовсе не работает…
Отступы нужны двух типов: 1. Горизонтальный отступ, при вложенности — два (или четыре) пробела. 2. Вертикальный отступ, для лучшей разбивки кода — перевод строки. Метки goto должны быть выровнены влево, состоять из заглавных букв и содержать имя программиста, его домашний телефон и номер кредитной карты. Абдул Низар
Начало-конец Хорошо! Плохо
Отступы в Python Блоки кода (функции, инструкций if, for и др. ) определяются отступами. Увеличение отступа обозначает начало блока и уменьшение — его конец. Никакие дополнительные скобки или ключевые слова для этих целей не используются. Таким образом отступы являются значимыми и должны быть согласованными. Плохо
Именование 1. Никакого транслита. Только английский. 2. Использовать короткие имена только для переменных «местного значения» . 3. Для переменных-счетчиков коротких циклов допускаются традиционные односимвольные имена — i, j, k, …. 4. Переменные из нескольких слов пишутся вместе Вот. Так. 5. Имя переменной должно максимально чётко соответствовать хранимым в ней данным. Плохо: x, $fb, f_ar_type_data Хорошо: my. Name, new. Data,
Именование 6. Аббревиатуры и сокращения в именах должны записываться в нижнем регистре. Хорошо: export. Html. Source(); Плохо: export. HTMLSource(); 7. Членам класса с модификатором private следует присваивать суффиксподчёркивание. С++ : 8. Префикс n следует использовать для представления числа объектов. n. Points, n. Lines
Именование 9. Префикс is следует использовать только для булевых (логических) переменных и методов. is. Set, is. Visible, is. Finished, is. Found, is. Open 10. Симметричные имена должны использоваться для соответствующих операций get/set, add/remove, create/destroy, start/stop, insert/delete, increment/decrement, old/new, begin/end, first/last, up/down, min/max, next/previous, old/new, open/close, show/hide, suspend/resume, и т. д. 11. Нельзя давать булевым (логическим) переменным имена, содержащие отрицание. Хорошо: bool is. Found; Плохо: is. Not. Found;
Именование 12. Для функций, как правило, используются глагольные префиксы, обозначающие общий характер действия, после которых следует уточнение. show. Message(. . ) //префикс show, “показать” сообщение get. Result(. . ) //префикс get, “получает” результат create. Table(. . ) //create, “создает” таблицу 13. Функциям (методам, возвращающим какие-либо значения) следует давать имена в зависимости от того, что они возвращают, а процедурам — в зависимости от того, что они выполняют (методы void).
Функции должны быть небольшими. Если функция большая — желательно разбить её на несколько Есть два способа расположить функции, необходимые для выполнения кода. 1. Функции над кодом 2. Сначала код, а функции ниже
Комментарии 1. Архитектурный комментарий. Какие компоненты есть, какие технологии использованы. 2. Справочный комментарий перед функцией. Что именно она делает, какие параметры принимает и что возвращает. Для таких комментариев существует синтаксис JSDoc. @author, @param, @private, @returns… 3. Почему в коде происходит именно это? Особенно это важно в тех случаях, когда используется не первый пришедший в голову способ, а какой-то другой. Комментарии, которые объясняют выбор решения, очень важны. Они помогают понять происходящее и предпринять правильные шаги при развитии кода. Если вам кажется, что нужно добавить комментарий для улучшения понимания, это значит, что ваш код недостаточно прост, и, может, стоит переписать его. Роберт Мартин
Стандарты оформления кода Сейчас, когда есть столько готовых проектов, нет смысла придумывать целиком своё руководство по стилю. Можно взять уже готовое, и которому, по желанию, всегда можно что-то добавить. 1. Стандарты кодирования для PHP (PEAR) http: //pear. php. net/manual/en/standards. php 2. Стандарт кодирования на JAVA http: //www. oracle. com/technetwork/java/codeconvtoc-136057. html 3. Стандарт кодирования на C# us/library/ff 926074. aspx https: //msdn. microsoft. com/en-
Скачать презентацию Совершенный код Любой дурак может написать код понятный
Совершенный код.ppt