Спецификации кодирования Delphi Автор: Tulipsys Дата обновления: 16 декабря 2003 г. Содержание 1. Общие соглашения (именование – отступы и пробелы – поля – регистр – комментарии) 2. Оператор (начало...конец оператора-если оператор-регистр-оператор-для оператора-в то время как оператор-оператор повторения-с оператором-оператор обработки исключений) 3. Процедуры и функции (именование и формат-формальные параметры-переменные-тип-пользовательские типы) 4. Цель формулирования стандартов кодирования, относящихся к объектно-ориентированному (именование классов и реализация формата-поля-метода-свойства-метода), состоит в том, чтобы дать возможность группе программистов генерировать код одного стиля, чтобы команда могла формировать и поддерживать определенный стиль. Если эта цель будет достигнута, все файлы проекта будут выглядеть так, как будто их написал программист. Добро — это весело, но преимущество в том, что код каждого программиста легко понять другим, что значительно улучшит удобство сопровождения кода и, следовательно, снизит затраты на обслуживание. Это идеальная ситуация для любой команды. Для отдельных лиц выбор или самостоятельное создание нормы кодирования и соблюдение этой нормы также может дать хорошие результаты. Кстати, это очень заманчивая цель, но достичь ее не так уж и сложно. Каждый язык программирования имеет свои собственные стандарты кодирования. Можно сказать, что стандарты кодирования представляют собой обобщение опыта. Конечно, мы также должны учиться на стандартах других языков программирования. Поэтому очень важно учиться у других. Во-вторых, использование стандартов кодирования призвано упростить работу программистов. Смысл «упрощения» заключается не в уменьшении количества кода (наоборот, многократное следование стандартам принесет больше кода), а в сокращении труда программиста. труд по поддержанию количества кода. Программирование — очень сложная работа. Трудно иметь дело с различными отношениями, и между различными отношениями существует неразрывная связь. Программистам следует тратить большую часть своей энергии на взаимодействие и избегать траты времени на слишком подробные вопросы. Если он сможет с первого взгляда понять идею и структуру программы, план обслуживания будет сформирован быстро. Более того, стандарт кодирования должен быть очень удобным для пользователя стандартом, на который можно ссылаться и изменять, но при этом он должен быть простым в использовании. Но в группе убедитесь, что все используют одни и те же стандарты. Программирование — очень гибкая работа. Только при гибком мышлении и гибком применении можно получить хорошие результаты. Кроме того, использование спецификаций в основном направлено на снижение нагрузки на память программистов. Мыслительные способности человека чрезвычайно превосходны, но память очень плохая. Мы целый день сталкиваемся с компьютерами, и самое важное, что он хочет нам помочь, — это память. Поэтому одна из наших целей — максимизировать преимущества мышления программистов. Наконец, инструменты программирования оказывают большое влияние на стандарты кодирования, и это влияние зависит от стиля программирования разработчика. Кроме того, на основе C++ мы не будем использовать одни и те же спецификации кодирования в Microsoft Visual C++ и Borland C++ Builder. У Microsoft и Borland разные и очень разные стили. Как пользователи, мы можем вносить изменения на основе этого, но есть ограничения. Фактически, когда мы делаем выбор в отношении поставщиков и инструментов разработки, мы также определяем наш будущий стиль. 1. Общие соглашения 1.1. Именование Основной принцип именования заключается в том, что имя должно четко выражать функцию данных. Object Pascal поддерживает длинные имена файлов. В именах следует использовать глаголы, существительные или их комбинацию. Вы не должны использовать зарезервированные слова и ключевые слова, определенные в Delphi, и старайтесь не использовать зарезервированные слова и ключевые слова, определенные в других языках. Старайтесь использовать полные слова и избегайте сокращений, префиксов и суффиксов, подчеркиваний и других символов. Венгерская номенклатура не рекомендуется. Соглашения об именах используются для обеспечения читаемости имен. В стандартах именования, представленных венгерской номенклатурой, разработано множество префиксов и суффиксов для обозначения типа, объема или других различных атрибутов данных. В Delphi вы, конечно, можете использовать этот метод, но это не рекомендуемый метод. Одна из причин заключается в том, что этот тип соглашения об именах требует слишком много дополнительных задач памяти, а другая причина определяется характеристиками самого Delphi. Обязательная проверка типов в Delphi автоматически отслеживает использование всех переменных, поэтому нам нужно лишь уделить немного внимания (обращать внимание на написание слов с заглавной буквы) без необходимости кропотливого добавления различных префиксов. Кроме того, рассмотрение данных должно основываться на их значении, а не на типе или объеме, а внимание следует уделять структуре программы, логическим связям и идеям проектирования. Таким образом, в Delphi вам нужно использовать только полную комбинацию слов для названия, не принимая во внимание ничего другого, и, конечно же, вы должны сделать его как можно более кратким. В некоторых операторах (например, в циклах for) нам необходимо использовать несколько целых чисел в качестве счетных переменных. Здесь вы можете просто использовать три буквы i, j и k в качестве имен переменных. Эта привычка была развита и сохранена в языке Фортран, и она оказалась очень полезной и простой для понимания. Конечно, мы получили бы лучшие результаты, если бы использовали более значимое имя, например: MyCounter. Вообще говоря, трех букв i, j и k вполне достаточно, в противном случае следует разделить больше процессов или функций. Вот несколько примеров: 1. SongsList // Указывает, что это список песен. Число песен во множественном числе указывает на то, что существует более одной песни. 2. SetCarColor // Указывает, что это функция для установки цвета. Если определен класс TCar, то SetColor используется в классе как член функции для установки цвета автомобиля. Также обратите внимание на именование логических переменных. Имя логической переменной должно четко указывать значение True и False. Например, для переменной, которая записывает, существует ли файл, лучше использовать IsFileExisted, чем FileExisted. Наконец, никогда не называйте глобальную переменную Temp или Tmp, но это по-прежнему разрешено внутри процедуры или функции. На самом деле, по поводу этого правила существуют некоторые разногласия. Некоторые стандарты кодирования являются более строгими. Такое именование категорически запрещено даже в процедурах или функциях. Однако во многих случаях такое именование действительно удобно, особенно для процедур или функций. Если она используется как глобальная переменная, вполне вероятно, что будет оператор присваивания, не соответствующий типу. Хотя компилятор в этот момент окажет вам большую помощь, избежать возникновения небольших ошибок сложно. . Подводя итог, можно сказать, что следование этому правилу даст лучшие результаты, но при необходимости строго придерживаться ничего не следует. 1.2 Отступы и пробелы Между каждым уровнем следует оставить два пробела. Это сделает программу понятной и хорошо организованной. Никогда не используйте символы табуляции, поскольку ширину символов табуляции трудно поддерживать в соответствии с различными настройками и приложениями, но не ожидайте, что вашу программу будут просматривать только в Delphi. Также обратите внимание на использование редактора. Если вы выбираете только Delphi, то нет проблем; если вы также используете текстовый процессор, такой как Word, обратите внимание на использование соответствующих шрифтов, чтобы обеспечить ширину каждой буквы и символа. то же самое. При печати с помощью текстового процессора, такого как Word, следует также обратить внимание на выбор шрифтов. Использование пробелов также необходимо для поддержания чистоты программы и предоставления программистам возможности быстро понять структуру программы. Ниже приведены некоторые характеристики и соответствующие примеры: 1. Между каждым словом должен быть пробел. Например: для TMyClass = class(TObject)2. Вокруг "=", "<>", ">=" и "<=" должен быть пробел; справа от ":=" и ":", но не слева. Например: если a = b, то a:= b; a: целое число 3. Между зарезервированными словами и ключевыми словами и символом слева должен быть пробел, но между ними и символом справа не должно быть пробела. Например: PROcedure ShowMessage;4. Использование скобок: При определении и вызове процедур и функций не следует оставлять пробелов между скобками и внешними словами и символами; между скобками и внутренними словами не должно быть пробелов; При условном суждении оператора if следует использовать пробелы между зарезервированными словами, такими как и и или. Например: функция Exchange(a: целое число; b: целое число); if (a = b) и ((a = c) или (a = d)) then … end;1.3. Редактор Delphi находится примерно на 81-м месте справа. — это темная линия слева от символа. Фактически, в интерфейсе Delphi по умолчанию при разрешении 800*600 максимальное окно будет отображаться на 4 буквы слева от темной линии. Поэтому не пишите исходный код за пределами темной строки. Это означает, что каждая строка не должна превышать 80 символов, включая начальные и средние пробелы. Если оператор слишком длинный, разрыв строки завершается, и разрыв строки должен быть отступом на два символа. Его также легко распечатать, а части за темной линией не будут напечатаны в Delphi. Если вы используете текстовый редактор, например Word, для печати программы Delphi, лишняя часть будет перенесена в начало следующей строки, что затруднит чтение напечатанной программы. Поэтому старайтесь вносить все корректировки во время написания кода, а не оставляйте подобную работу печати. При переносе строк обращайте внимание на сохранение читабельности программы и старайтесь сохранить целую часть. Например, если функция слишком длинная, оберните полное описание параметра, а не только объявление типа данных. Первые два способа написания ниже верны, а следующие способы записи неверны: function AdditonFiveInputNumber(a: целое число; b: целое число; c: целое число; d: целое число;e: целое число): целое число; //Правильная функция AdditonFiveInputNumber; (a: целое число;b: целое число;c: целое число;d: целое число;e: целое число): целое число //Правильная функция; AdditonFiveInputNumber(a: целое число; b: целое число; c: целое число; d: целое число; e: целое число): целое число; //Функция ошибки AdditonFiveInputNumber(a: целое число; b: целое число; c: целое число; d: целое число;e: целое число ): целое число; // Функция ошибки AdditonFiveInputNumber(a: целое число; b: целое число; c: целое число; d: ineger;e: целое число): целое число; //Ошибка 1.4. Первая буква каждого слова в пользовательском имени должна быть прописной и строчной, а остальные буквы должны быть строчными. Зарезервированные слова и ключевые слова Delphi должны быть написаны строчными буквами. Метод записи предопределенных функций Delphi такой же, как и метод записи пользовательских имен. Базовые типы данных в Delphi должны быть строчными, а первые две буквы расширенных типов классов — заглавными (первая буква типа класса — «T»). Вот несколько примеров: 1. Пользовательское имя: MyFavouriteSong, CarList; 2. Зарезервированные слова: if (a = b) и ((a = c) или (a = d)) then … end 3. Предопределенные функции Delphi :ShowMessage; («Все в порядке»); 4. Тип класса расширения Delphi: MyStrings = TStrings.Create;1.5. Комментарии Delphi поддерживает два типа комментариев: блочные комментарии ({}) и однострочные комментарии (//). Цель комментариев — объяснить идеи дизайна программы и помочь программистам как можно скорее понять идеи программы, написанной два года назад или даже вчера. На самом деле это решение проблемы с памятью. Не следует чрезмерно использовать мозг как память. Никогда не полагайтесь слишком сильно на мозг в программировании, но используйте слова как можно больше. Поэтому комментарии — очень важный аспект в языках программирования, хотя многие люди (особенно новички, среди которых немалое количество программистов) не возражают против этого и редко пишут комментарии. Другое применение комментариев — на этапе отладки программы. Например, если операторов два и вы заранее не знаете, какой из них лучше, нужно протестировать: поставить перед оператором «//» (то есть изменить). оператор для комментария), запустите другой оператор, а затем сделайте обратное, мы легко сможем сделать выбор. Если это группа операторов, используйте блочные комментарии, но обязательно размещайте «{» и «}» на видных позициях, например, в отдельных верхней и нижней строках. Ниже приведены некоторые принципы использования: 1. В большинстве случаев перед пользовательскими переменными и типами необходимо размещать комментарии. 2. В большинстве случаев необходимо разместить комментарий вверху файла модуля. Здесь комментарий должен содержать: имя файла, дату создания, дату модификации, автора, автора модификации и необходимое описание. 3. Комментарии должны быть содержательными, не используйте бесполезные комментарии. Например: while i < 8 dobegin … i:= i + 1; //Добавить один в iend; комментарий «//Добавить один в i» здесь не имеет смысла, конечно, он не означает простого утверждения (аналогично: i : = i + 1) комментарии не нужны. Поскольку простые высказывания часто играют очень важную роль, если это высказывание вызывает у людей вопросы или его трудно понять, то следует отметить функцию этого высказывания. 4. Не пытайтесь создавать монограммы в комментариях, если не считаете это абсолютно необходимым. Потому что очень сложно изменить аннотацию, сохранив при этом рисунок целым и красивым. . 5. Чтобы отличить временные комментарии от постоянных, вы можете использовать свой метод, размещая в комментариях специальные символы. Преимущество этого в том, что его легко найти. 6. Изменения в утверждениях сопоставляются с соответствующими комментариями. 7. Между комментариями и кодом должен быть четкий разрыв, чтобы можно было сразу определить, что является утверждением, а что — комментарием. Вы можете размещать комментарии в строке до или после строки кода или оставлять как минимум два пробела сразу после кода. Однако, если код и комментарии находятся в одной строке, не помещайте код после комментария. не помещайте код после комментария. Комментарии размещаются в середине кода.