Хороший стиль программирования
Запись от MrWeep размещена 30.07.2016 в 01:01
Показов 4082
Комментарии 5
|
Хороший стиль программирования Здесь описаны некоторые советы хорошего стиля программирования. Это больше относится к современным компиляторам, но чего можно, того стоит придерживаться и в старых версиях. Так вам будет легче потом. Старайтесь придерживаться одного стиля Главное — корректность, простота и ясность Комментируйте и документируйте код Не допускайте дублирования кода Избегайте длинных функций и глубокой вложенности Компилируйте без замечаний при максимальном уровне предупреждений Не используйте в коде непоименованные числовые константы Избегайте макросов Активно используйте const Объявляйте переменные как можно локальнее, инициализируйте при объявлении Работайте с типами, а не с представлениями в памяти Избегайте применения static_cast (явное статическое преобразование типов) к указателям Не применяйте memcpy или memcmp к объектам Не используйте неизвестные аргументы в функциях (троеточия) Не используйте недействительные объекты и небезопасные функции Различайте указатели и ссылки Не оптимизируйте преждевременно При разработке функций Не пишите код, который зависит от порядка вычислений аргументов функции Текст функции должен умещаться на один экран, а вложенность блоков и операторов должна быть не более трёх Пусть одна функция решает только одну задачу Избегайте вложенных последовательных конструкций if там, где их можно заменить оператором && Избегайте дублирования кода. Нужно завести именованную функцию вместо повтора схожих фрагментов кода. Не нагружайте блок try. Предпочитайте использовать освобождение ресурсов в деструкторах (там где это возможно), а не в try-блоках При перегрузке операторов Сохраняйте естественную семантику перегруженных операторов Отдавайте предпочтение каноническим формам арифметических операторов и операторов присваивания Не перегружайте &&, || и , (запятую) Используйте перегрузку, чтобы избежать неявного преобразования типов При работе с классами Ясно представляйте, какой вид класса вы создаете Предпочитайте минимальные классы монолитным Делайте данные-члены закрытыми Не допускайте вмешательства во внутренние дела класса Предпочитайте функции, которые не являются ни членами, ни друзьями Предпочитайте композицию наследованию Открытое наследование означает заменимость. Наследовать надо не для повторного использования, а чтобы быть повторно использованным Предпочитайте предоставление абстрактных интерфейсов Избегайте возможностей неявного преобразования типов Виртуальные функции стоит делать неоткрытыми, а открытые — невиртуальным При разработке Конструкторов, деструкторов и копировании Определяйте и инициализируйте переменные-члены в одном порядке В конструкторах используйте инициализацию вместо присваивания Делайте деструкторы базовых классов открытыми и виртуальными либо защищенными и невиртуальными Не позволяйте исключениям выйти за пределы деструктора Избегайте вызовов виртуальных функций в конструкторах и деструкторах Деструкторы, функции освобождения ресурсов и обмена не ошибаются Копируйте и ликвидируйте согласованно Явно разрешайте или запрещайте копирование Избегайте срезки. Подумайте об использовании в базовом классе клонирования вместо копирования Предпочитайте канонический вид присваивания Обеспечьте бессбойную функцию обмена При разработке модулей Делайте заголовочные файлы самодостаточными Используйте #pragma once для защиты заголовочных файлов от повторного включения Выделяйте и освобождайте ресурсы в одном и том же модуле Не определяйте в заголовочном файле объекты со связыванием Не позволяйте исключениям пересекать границы модулей Используйте достаточно переносимые типы в интерфейсах модулей Не используйте using для пространств имен в заголовочных файлах или перед директивой #include При разработке шаблонов пишите максимально обобщенный код При обработке ошибок и исключительных ситуациях Широко применяйте ASSERT для документирования внутренних допущений и инвариантов Определите разумную стратегию обработки ошибок и строго ей следуйте Проектируйте и пишите безопасный в отношении ошибок код Для уведомления об ошибках следует использовать исключения Уведомляйте об ошибках, обрабатывайте и преобразовывайте их там, где следует Дополнительные советы Программируйте, заглядывая в будущее Ознакомьтесь со стандартом языка Настраивайте проект таким образом, чтобы он корректно компилировался во всех вариантах сборки Одна голова хорошо, а две лучше |
Размещено в Без категории
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Всего комментариев 5
Комментарии
-
Дъявол в деталях, тут нет деталей, поэтому ....
Лучше прочесть книгу ибо как я понимаю это из книги.Запись от Avazart размещена 30.07.2016 в 14:15 
-
"Используйте #pragma once для защиты заголовочных файлов от повторного включения"
Круть. Даешь всем прагмы )))Запись от Croessmah размещена 31.07.2016 в 03:06
-
Проблемы плюсовиков :)
Запись от nimazzzy размещена 31.07.2016 в 11:31
-
Друзья, для спама есть соц.сети. Если хотите дополнить тему, то пожалуйста.Запись от MrWeep размещена 28.08.2016 в 22:21
-
Хорошие советы, но с некоторыми невозможно согласиться.
Комментарии в основном только захламляют код и врут, больше они ничего не делают. Бывают, конечно, хорошие комментарии, но это не означает, что весь код нужно покрывать комментариями (документировать). Если код требует комментариев, то нужно переписать код)
Вредный совет. Всё зависит от того какой принцип программирования мы используем.Запись от Nikto размещена 28.08.2016 в 23:03
