Рекомендации по улучшению вашего кода

https://stackoverflow.com/questions/60673

09-06-2019
|

Вопрос

Каким рекомендациям вы следуете, чтобы улучшить общее качество вашего кода?У многих людей есть правила написания кода на C++, которые (предположительно) затрудняют допущение ошибок.Я видел людей настаивать что каждый if За оператором следует блок скобок ({...}).

Меня интересует, каким принципам следуют другие люди, и причины, стоящие за ними.Меня также интересуют рекомендации, которые вы считаете чушью, но которые широко распространены.Может ли кто-нибудь предложить несколько?

Для начала я упомяну некоторые из них:

Всегда используйте брекеты после каждого if / else заявление (упомянутое выше).Причина этого в том, что не всегда легко определить, является ли один оператор на самом деле одним оператором или макросом препроцессора, который расширяется до более чем одного оператора, поэтому этот код может сломаться:

    // top of file:
    #define statement doSomething(); doSomethingElse

    // in implementation:
    if (somecondition)
        doSomething();

но если вы используете фигурные скобки, все будет работать как положено.

Используйте макросы препроцессора ТОЛЬКО для условной компиляции.Макросы препроцессора могут вызвать настоящий ад, поскольку они не допускают правил области видимости C++.Я много раз садился на мель из-за макросов препроцессора с общими именами в заголовочных файлах.Если вы не будете осторожны, вы можете вызвать всевозможные разрушения!

Теперь дело за вами.

Решение

Несколько моих личных фаворитов:

Стремитесь писать код, который константа правильная.Вы заручитесь поддержкой компилятора, который поможет устранить легко исправляемые, но иногда болезненные ошибки.Ваш код также расскажет историю о том, что вы имели в виду во время его написания, что будет ценно для новичков или сопровождающих, когда вы уйдете.

Уйдите из бизнеса по управлению памятью.Научитесь использовать умные указатели: std::auto_ptr, std::tr1::shared_ptr (или boost::shared_ptr) и boost::scoped_ptr.Узнайте о различиях между ними и о том, когда использовать один, а когда нет.другой.

Вероятно, вы будете использовать стандартную библиотеку шаблонов.Прочтите Книга Джосуттиса.Не останавливайтесь после первых нескольких глав о контейнерах, думая, что вы знаете STL.Переходите к хорошему:алгоритмы и функциональные объекты.

Другие советы

Удалите ненужный код.

Вот и все.

Используйте и соблюдайте общий стиль кодирования и рекомендации. Обоснование: Каждый разработчик в команде или в фирме может читать код, не отвлекаясь на различные стили скобок или что-то подобное.
Регулярно выполняйте полную перестройку всей исходной базы (т.делайте ежедневные сборки или сборки после каждой проверки) и сообщайте о любых ошибках! Обоснование: Исходный код почти всегда находится в пригодном для использования состоянии, а проблемы обнаруживаются вскоре после их «реализации», причем решение проблем обходится дешево.

Включите все возможные предупреждения в своем компиляторе (gcc: -Wall это хорошее начало, но оно не включает в себя все, поэтому проверьте документацию) и сделайте в них ошибки, чтобы вам пришлось их исправлять (gcc: -Werror).

Руководство по стилю Google, упомянутое в одном из этих ответов, довольно солидно.Есть в этом что-то бессмысленное, но это скорее хорошо, чем плохо.

Саттер и Александреску написали на эту тему достойную книгу под названием Стандарты кодирования C++.

Вот несколько общих советов от меня:

Ваш стиль отступов и скобок неверен.Как и у всех остальных.Поэтому следуйте стандартам проекта.Проглотите свою гордость и настройте свой редактор так, чтобы все максимально соответствовало остальной кодовой базе.Очень раздражает необходимость читать код с непоследовательными отступами.Тем не менее, кронштейн и отступ не имеют ничего общего с «улучшением вашего кода». Это больше о улучшении вашей способности работать с другими.
Комментируйте хорошо.Это крайне субъективно, но вообще всегда приятно писать комментарии по поводу почему код работает так, как он работает, а не объясняет, что он делает.Конечно, для сложного кода программистам, которые, возможно, не знакомы с алгоритмом или кодом, полезно иметь представление о что у него тоже дела идут.Ссылки на описания используемых алгоритмов приветствуются.
Выражайте логику как можно более прямолинейно.По иронии судьбы, такие предложения, как «помещать константы в левую часть сравнения», я думаю, здесь ошиблись.Они очень популярны, но для носителей английского языка они часто нарушают логическую последовательность программы для тех, кто ее читает.Если вы не можете быть уверены в том, что вы (или ваш компилятор) правильно напишете сравнение на равенство, то обязательно используйте подобные трюки.Но при этом вы жертвуете ясностью.В эту категорию также попадают такие вещи, как...«Есть ли в моей логике три уровня отступов?Может ли быть проще?» и развертывание аналогичного кода в функции.Возможно даже разделение функций.Чтобы написать код, элегантно выражающий основную логику, нужен опыт, но над этим стоит поработать.

Они были довольно общими.Что касается конкретных советов, я не смогу сделать это лучше, чем Саттер и Александреску.

В операторах if константа помещается слева, т.е.

if( 12 == var )

нет

if( var == 12 )

Потому что, если вы пропустите ввод знака «=", он станет присваиванием.В верхней версии компилятор говорит, что это невозможно, во второй он работает, и if всегда истинно.

Я использую фигурные скобки для if, когда они не находятся на одной строке.

if( a == b ) something();
if( b == d )
{
    bigLongStringOfStuffThatWontFitOnASingleLineNeatly();
}

Открывающие и закрывающие скобки всегда получают свои собственные строки.Но это, конечно, личное соглашение.

Комментируйте только тогда, когда необходимо объяснить, что делает код, когда чтение кода не может сказать вам того же.

Не комментируйте код, который вы больше не используете.Если вы хотите восстановить старый код, используйте свою систему контроля версий.Комментирование кода только делает все беспорядочным и заставляет ваши действительно важные комментарии растворяться в фоновом беспорядке закомментированного кода.

Используйте единообразное форматирование.
При работе с устаревшим кодом используйте существующий стиль форматирования, особенно.стиль брекеты.
Получите копию книги Скотта Мейера «Эффективный C++».
Получите копию книги Стива МакКоннелла «Совершенный код».

Также есть приятный Руководство по стилю C++ используется внутри компании Google и включает в себя большинство упомянутых здесь правил.

Начните писать много комментариев, но используйте это как возможность реорганизовать код, чтобы он был понятен.

то есть:

for(int i=0; i<=arr.length; i++) {
  arr[i].conf() //confirm that every username doesn't contain invalid characters
}

Должно было быть что-то больше похожее

for(int i=0; i<=activeusers.length; i++) {
  activeusers[i].UsernameStripInvalidChars()
}

Используйте вкладки для вмешательств, но выравнивайте данные с пробелами, это означает, что люди могут решить, сколько нужно отступить, изменяя размер вкладки, но также и то, что вещи остаются выровненными (например, вы можете захотеть все «=» в вертикальной линии, когда присваивают значения структура)
Всегда используйте константы или встроенные функции вместо макросов, где это возможно.
Никогда не используйте «using» в файлах заголовков, потому что все, что включает в себя этот заголовок, также будет затронуто, даже если человек, включающий ваш заголовок, не хочет, чтобы все std (например) было в его глобальном пространстве имен.

Если что-то длиннее 80 столбцов, разбейте его на несколько строк, например

if(SomeVeryLongVaribleName != LongFunction(AnotherVarible, AString) &&
   BigVaribleIsValid(SomeVeryLongVaribleName))
{
    DoSomething();
}

Перегружайте операторы только для того, чтобы они делали то, что ожидает пользователь, например, перегрузка операторов + и - для 2dVector вполне допустима.
Всегда комментируйте свой код, даже если просто хотите сказать, что делает следующий блок (например, «удалить все текстуры, которые не нужны для этого уровня»).Кому-то может понадобиться поработать с ним позже, возможно, после того, как вы уйдете, и они не захотят найти тысячи строк кода без комментариев, указывающих, что и что делает.

настройте соглашение о кодировании и заставьте всех участников следовать этому соглашению (вы не захотите читать код, который требует от вас выяснить, где находится следующий оператор/выражение, потому что он не имеет правильного отступа)
постоянный рефакторинг вашего кода (получите копию «Рефакторинга» Мартина Фаулера, плюсы и минусы подробно описаны в книге)
писать слабосвязанный код (избегайте написания комментариев, написав понятный код, слабосвязанный код, как правило, легче управлять/адаптировать к изменениям)
если возможно, проведите модульное тестирование вашего кода (или, если вы достаточно мачо, TDD.)
выпускать раньше, выпускать часто
избегать преждевременной оптимизации (профилирование помогает в оптимизации)

В том же ключе вы можете найти некоторые полезные предложения здесь: Как сделать так, чтобы неправильный код выглядел неправильно?Какие шаблоны вы используете, чтобы избежать смысловых ошибок?

Там, где это возможно, используйте преинкремент вместо постинкремента.

Я использую PC-Lint в своих проектах на C++, и мне особенно нравится, как он ссылается на существующие публикации, такие как рекомендации MISRA или «Эффективный C++» и «Более эффективный C++» Скотта Мейерса.Даже если вы планируете писать очень подробные обоснования для каждого правила, которое проверяет ваш инструмент статического анализа, хорошей идеей будет указать на авторитетные публикации, которым доверяет ваш пользователь.

Вот самый важный совет, который мне дал гуру C++, и он помог мне в нескольких критических случаях найти ошибки в моем коде:

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

С помощью этих двух правил компилятор бесплатно укажет вам, где в вашем коде логика ошибочна!

Кроме того, для некоторых хороших методов вы можете следовать Блог Google «Тестирование в туалете».

Посмотрите на это спустя шесть месяцев.

убедитесь, что вы делаете отступы правильно

Хм, наверное, мне следовало быть более конкретным.

Я не столько ищу советов для себя — я пишу инструмент статического анализа кода (текущие коммерческие предложения просто недостаточно хороши для того, что я хочу), и ищу идеи для плагинов, которые бы подсветили возможные ошибки в коде.

Несколько человек упомянули такие вещи, как корректность констант и использование интеллектуальных указателей — это то, что я могу проверить.Проверку отступов и комментирования сделать немного сложнее (во всяком случае, с точки зрения программирования).

Умные указатели позволяют очень четко указать право собственности.Если вы класс или функция:

если ты получишь необработанный указатель, тебе ничего не принадлежит.Вам разрешено использовать указку, любезно предоставленную вашим абонентом, который гарантирует, что указка останется в живых дольше, чем вы.
если ты получишь слабый_ptr, вы не являетесь владельцем пуанта, и, кроме того, пуант может исчезнуть в любой момент.
если ты получишь общий_ptr, вы владеете объектом вместе с другими, поэтому вам не о чем беспокоиться.Меньше стресса, но и меньше контроля.
если ты получишь auto_ptr, вы являетесь единственным владельцем объекта.Это твое, ты король.У вас есть право уничтожить этот объект или передать его кому-то другому (тем самым теряя право собственности).

Я считаю аргументы в пользу auto_ptr особенно убедительными:в проекте, если я вижу auto_ptr, я сразу знаю, что этот объект будет «блуждать» из одной части системы в другую.

По крайней мере, именно такую логику я использую в своем любимом проекте.Я не уверен, сколько может быть вариаций на эту тему, но до сих пор этот набор правил сослужил мне хорошую службу.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow