Cómo detectar métodos no utilizados y #importar en Objective-C

Después de trabajar mucho tiempo en una aplicación de iPhone, me di cuenta de que mi código está bastante sucio, contiene varios #import y métodos que no se llaman ni son útiles en absoluto.

Me gustaría saber si hay alguna directiva de compilación o forma de detectar esas líneas de código inútiles. ¿Xcode tiene alguna herramienta para detectar esto?

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 gcovy lcovpara 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:

• Perfilado del tamaño de imagen binaria de Objective-C

Appcode tiene una función de inspección de código que encuentra importaciones y código no utilizados.

Hemos estado usando un código Ruby de cosecha propia, ahora extraído en una gema llamada fui: https://github.com/dblock/fui

Recientemente escribí un script para encontrar #importdeclaraciones no utilizadas (o duplicadas) : https://gist.github.com/Orangenhain/7691314

El script toma un archivo .m de ObjC y comienza a comentar cada #importlínea por turno y ver si el proyecto aún se compila. Tendrá que cambiar BUILD_DIR y BUILD_CMD.

Si está usando un findcomando para permitir que el script se ejecute en varios archivos, asegúrese de usar un BUILD_CMD que realmente use todos esos archivos (o verá un archivo con muchas declaraciones de importación sin usar).

Escribí esto sin saber que AppCode tiene una característica similar, sin embargo, cuando probé AppCode no fue tan completo como este script (pero mucho más rápido [para un proyecto completo]).

Como dijo paddydub , AppCode hace esto muy bien. Lo intenté y me llevó solo 10 minutos:

Ir a Code > Optimize Imports..., o^ + ⌥ + O

Aquí hay un video que describe cómo hacer esto: Detección de importación y métodos no utilizados en AppCode

Puede usar Xcode Analyzer para encontrar ese y otros problemas.

http://help.apple.com/xcode/mac/8.0/#/devb7babe820

También puede ir al proyecto y la compilación de destino y agregar preferencias de advertencias de cambio en la configuración de compilación. Vea esta guía:

http://oleb.net/blog/2013/04/compiler-warnings-for-objective-c-developers/

Recientemente, cambié un gran proyecto de Carbon a Cocoa. Al final de esto, había bastantes archivos huérfanos que ya no se usaban. Escribí un guión para encontrarlos que esencialmente hicieron esto:

Asegúrese de que la fuente esté registrada en subversion (es decir, limpia) Asegúrese de que actualmente se compila sin errores (es decir, xcodebuild devuelve el estado 0) Luego, para cada archivo fuente en el directorio, vacíe (es decir, elimine el contenido, trunque la longitud) el fuente y el archivo de encabezado, intente una compilación, si falla, revertir los archivos, de lo contrario, déjelos vacíos.

Después de ejecutar esto, revierta y luego elimine todos los archivos vacíos, compile y luego elimine todas las #importaciones con errores.

También debo agregar, debe evitar los archivos a los que se hace referencia desde archivos .xib o .sdef, y puede haber otros casos de enlaces dinámicos, pero aún puede brindarle una buena pista sobre lo que se puede eliminar.

Se puede utilizar la misma técnica para ver qué #importaciones se pueden eliminar; en lugar de truncar el archivo, elimine cada #importación del archivo y vea si la compilación falla.