Xcode le permite (des) verificar la configuración de advertencias específicas del compilador que pueden advertirle de algunos tipos de código no utilizado. (Seleccione el proyecto en la lista de fuentes y Archivo> Obtener información, luego seleccione la pestaña Compilar). Aquí hay algunos (que se muestran para Clang y GCC 4.2 para mí) que pueden ser de interés:
- Funciones no utilizadas
- Parámetros no utilizados
- Valores no utilizados
No veo ninguna opción para detectar importaciones no utilizadas, pero eso es un poco más simple: el enfoque de baja tecnología es solo comentar las declaraciones de importación hasta que obtenga un error / advertencia de compilación.
Los métodos Objective-C no utilizados son mucho más difíciles de detectar que las funciones C no utilizadas porque los mensajes se envían dinámicamente. Una advertencia o error puede indicarle que tiene un problema potencial, pero la falta de uno no garantiza que no tendrá errores de tiempo de ejecución.
Editar: Otra buena forma de detectar métodos (potencialmente) no utilizados es examinar la cobertura del código de las ejecuciones reales. Por lo general, esto se hace en conjunto con las pruebas unitarias automatizadas, pero no tiene por qué ser así.
Esta publicación de blog es una introducción decente a las pruebas unitarias y la cobertura de código usando Xcode. La sección sobre gcov
(que solo funciona con código generado por GCC, por cierto) explica cómo hacer que Xcode construya código instrumentado que pueda registrar la frecuencia con la que se ha ejecutado. Si prueba una compilación instrumentada de su aplicación en el simulador, luego ejecuta gcov en ella, puede ver qué código se ejecutó utilizando una herramienta como CoverStory (una GUI bastante simplista) o lcov
(scripts de Perl para crear informes HTML) .
Utilizo gcov
y lcov
para CHDataStructures.framework y genero informes de cobertura automáticamente después de cada confirmación de SVN. Una vez más, recuerde que no es prudente tratar la cobertura ejecutada como una medida definitiva de qué código está "muerto", pero ciertamente puede ayudar a identificar métodos que puede investigar más a fondo.
Por último, dado que está tratando de eliminar el código muerto, creo que también encontrará interesante esta pregunta SO:
id
, o crea un selector para llamar en tiempo de ejecución, el analizador estático no puede garantizar que el código realmente no se utiliza. Si se elimina el código que aún se necesita, ahí es donde obtendría errores de tiempo de ejecución. ¿Me estoy perdiendo de algo?