Какой инструмент командной строки лучше всего подходит для очистки кода?

Если вы запустите gcc с параметром -Wall, он уловит некоторые из упомянутых вами вещей, например, неиспользуемые переменные (и, возможно, неиспользуемые функции). Что касается оптимизаций, то я этого не делаю, хотя в целом компилятор достаточно умен, чтобы делать те виды оптимизаций, которые имеют значение, так что я бы особо не беспокоился. Только не используйте ужасные алгоритмы. ;-)

Линт - классический инструмент для проверки стиля в программах C. Есть более современное его воплощение под названием Шина.Эта запись в Википедии имеет список инструментов статического анализа кода, некоторые бесплатные, некоторые коммерческие.

Как указал Дэн Фего, GCC может перехватывать неиспользуемые переменные и неиспользуемые статические функции. Обычно он не находит неиспользуемые внешние функции, поскольку обычно работает с одним исходным файлом за раз.

GCC (v4.3.2) имеет сотни, если не тысячи опций. Один, который может помочь, - это «--combine» для объединения исходных файлов (если у вас нет привычки помещать одни и те же имена функций или переменных в разные исходные файлы).

Опция «--help» расскажет вам больше; каждая из опций «--help=optimizers» и «--help=warnings» дает вам пару сотен строк вывода. Предупреждения включают:

-Wunused                    This switch lacks documentation
-Wunused-function           Warn when a function is unused
-Wunused-label              This switch lacks documentation
-Wunused-macros             Warn about macros defined in the main file that
                            are not used
-Wunused-parameter          Warn when a function parameter is unused
-Wunused-value              Warn when an expression value is unused
-Wunused-variable           Warn when a variable is unused

Добавлен: это сценарий под названием glint, который я использую для очистки своего кода. Он довольно старый, поэтому в нем не используется нотация «#!/bin/sh» для первой строки, а вместо «$*» написано «"$@"», оба из которых должны быть исправлены, но ни то, ни другое не требует срочного исправления. Обратите внимание, что хотя GCC 4.x больше не поддерживает параметр «-fwriteable-strings», он по-прежнему поддерживает параметр «-Wwrite-strings» и имеет значение.

Этот скрипт демонстрирует, что вы можете извлечь большую выгоду из существующих инструментов, приложив лишь небольшой объем работы. Вы можете настроить практически все используемые им параметры - хотя в основном через среду, а не из командной строки. Конечно, вы можете добавить в командную строку дополнительные параметры предупреждений; что вы не можете сделать, так это удалить предопределенные параметры, кроме как через среду. Но это нормально; они выбраны по умолчанию по уважительным причинам. В наши дни я бы, наверное, установил «GLINT_ANSI=-std=c99» или исправил скрипт; В последнее время я не использую его много раз, так как я кодирую довольно близко к стандарту, который требует glint. (Обратите внимание, что «-o /dev/null» означает, что вы можете делать только один файл за раз; взломайте, чтобы исправить!)

:   "@(#)$Id: glint.sh,v 1.5 2002/08/09 21:40:52 jleffler Exp jleffler $"
#
#   Use GCC as excruciatingly pedantic lint
#   Not a complete replacement for lint -- it doesn't do inter-file checking.
#   Now configurable via the environment.
#   Use GLINT_EXTRA_FLAGS to set extra flags via the environment.
#   NB: much Solaris code won't work with -undef enabled.

: ${GLINT_GCC:='gcc'}

: ${GLINT_ANSI='-ansi'}
: ${GLINT_FNO_COMMON='-fno-common'}
: ${GLINT_FSHORT_ENUMS='-fshort-enums'}
: ${GLINT_PEDANTIC='-pedantic'}
: ${GLINT_UNDEF='-undef'}
: ${GLINT_W='-W'}
: ${GLINT_WAGGREGATE_RETURN='-Waggregate-return'}
: ${GLINT_WALL='-Wall'}
: ${GLINT_WCAST_ALIGN='-Wcast-align'}
: ${GLINT_WCAST_QUAL='-Wcast-qual'}
: ${GLINT_WCONVERSION='-Wconversion'}
: ${GLINT_WMISSING_DECLARATIONS='-Wmissing-declarations'}
: ${GLINT_WREDUNDANT_DECLS='-Wredundant-decls'}
: ${GLINT_WMISSING_PROTOTYPES='-Wmissing-prototypes'}
: ${GLINT_WNESTED_EXTERNS='-Wnested-externs'}
: ${GLINT_WPOINTER_ARITH='-Wpointer-arith'}
: ${GLINT_WSHADOW='-Wshadow'}
: ${GLINT_WSTRICT_PROTOTYPES='-Wstrict-prototypes'}
: # ${GLINT_WTRADITIONAL='-Wtraditional'}
: ${GLINT_WWRITE_STRINGS='-Wwrite-strings'}

exec ${GLINT_GCC} \
    ${GLINT_ANSI} \
    ${GLINT_FNO_COMMON} \
    ${GLINT_FSHORT_ENUMS} \
    ${GLINT_PEDANTIC} \
    ${GLINT_UNDEF} \
    ${GLINT_WAGGREGATE_RETURN} \
    ${GLINT_WALL} \
    ${GLINT_WCAST_ALIGN} \
    ${GLINT_WCAST_QUAL} \
    ${GLINT_WCONVERSION} \
    ${GLINT_WMISSING_DECLARATIONS} \
    ${GLINT_WREDUNDANT_DECLS} \
    ${GLINT_WMISSING_PROTOTYPES} \
    ${GLINT_WNESTED_EXTERNS} \
    ${GLINT_WPOINTER_ARITH} \
    ${GLINT_WSHADOW} \
    ${GLINT_WSTRICT_PROTOTYPES} \
    ${GLINT_WTRADITIONAL} \
    ${GLINT_WWRITE_STRINGS} \
    ${GLINT_W} \
    ${GLINT_EXTRA_FLAGS} \
    -o /dev/null -O4 -g -c $*

шина (http://www.splint.org/) неплохая; Я использовал его для кодов Megaline, чтобы искать такие вещи,

(Обновлено: каждый хочет быть арт-директором.)

Хотя я уверен, что это не полный список инструментов статический анализ кода, вот мои впечатления от некоторых других, с которыми я работал в прошлом. (Я работаю в основном с C.)

1. Шина: Я часто использую Splint, потому что он доступен для многих дистрибутивов GNU / Linux. С ним относительно легко работать; тем не менее, при работе в самых строгих условиях он имеет тенденцию быть ошеломляющим. Более того, иногда необходимое использование аннотаций может загромождать и затруднять читаемый код. Тем не менее, я предлагаю использовать его.

2. Уно: Uno определенно многообещающий, но он не такой строгий, как Splint (по дизайну). Вместо этого он фокусируется на ясности и полезности предупреждений. Для меня Uno полезен только как дополнение к Splint (чтобы четко указать на предупреждения, скрытые среди сравнительно многих, которые выдает Splint).

3. ПК-линт: Я считаю, что PC-lint громоздок для проприетарной программы. Однажды я использовал его при разработке для MS-DOS, и загадочные имена, которые он использует для своих ошибок, сделали его очень трудным в использовании. Насколько я слышал, есть много лучших продуктов для использования в MS-DOS.

4. Pscan: (Мертвая гиперссылка) Pscan отлично подходит для поиска уязвимостей строки формата! Как и Uno, я предлагаю использовать его как дополнение к Splint.

Если вы не работаете с C, вы также можете проверить: Википедия - Список инструментов для статического анализа кода, Инструменты проверки / обзора, статические анализаторы исходного / двоичного кода и Анализаторы безопасности исходного кода.

Как насчет того, чтобы использовать профилировщик и определить, какой код работает больше всего, и сосредоточиться на этих частях.

Может, gprof выручит?

/ Йохан

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