Después de trabajar durante mucho tiempo en una aplicación de iPhone, me di cuenta de que mi código es bastante sucio y contiene varios importes y métodos que no se llaman ni son útiles en absoluto.Cómo detectar métodos no utilizados y #import en Objective-C
Me gustaría saber si hay alguna directiva de compilación o una 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 de compilación específicas que pueden advertirle de algunos tipos de código no utilizado. (Seleccione el proyecto en la lista de fuentes y Archivo> Obtener información, a continuación, seleccione la pestaña Generar.) Aquí están algunos (que se presenta para Clang y GCC 4.2 para mí) que pueden ser de interés:
que aún no hay opciones para la detección de las importaciones no utilizados, pero que es un poco más simple - el enfoque de baja tecnología es sólo para comentar las declaraciones de importación hasta que se obtener 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 tenga errores de tiempo de ejecución.
Editar: Otra buena manera de detectar (potencialmente) los métodos utilizados es examinar la cobertura de código de ejecuciones reales. Esto generalmente se realiza de forma conjunta con las pruebas unitarias automatizadas, pero no tiene que ser así.
This blog post es una introducción decente a las pruebas unitarias y la cobertura de código con Xcode. La sección de gcov (que solo funciona con el 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 llevas a cabo una compilación instrumentada de tu aplicación en el simulador, ejecuta gcov en ella, puedes ver qué código se ejecutó utilizando una herramienta como CoverStory (una GUI bastante simplista) o lcov (scripts Perl para crear informes HTML))
utilizo gcov y lcov para CHDataStructures.framework y generar automáticamente después de cada coverage reports SVN. Nuevamente, 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 seguir investigando.
Por último, dado que usted está tratando de eliminar el código muerto, creo que se encuentra esta cuestión de forma interesante, así:
Recientemente, he cambiado de un gran proyecto de Carbono al cacao. Al final de esto, había bastantes archivos huérfanos que ya no se usaban.Escribí un guión para encontrar los que hacían esencialmente esto:
Asegúrese de que la fuente es todo lo registramos en la subversión (es decir, limpia) asegurarse de que actualmente construye sin error (es decir, xcodebuild devuelve 0 estado) Entonces, para cada fuente archivo en el directorio, vacío (es decir, eliminar el contenido, truncar la longitud) el origen y el archivo de encabezado, pruebe una compilación, si falla, invierta los archivos, de lo contrario, déjelos vacíos.
Después de ejecutar esto, invierta y luego elimine todos los archivos vacíos, compile y luego elimine todos los errores #imports.
Debo añadir que debe evitar los archivos a los que se hace referencia desde los archivos .xib o .sdef, y puede haber otros casos de vinculación dinámica, pero aún así puede darle una buena pista sobre lo que se puede eliminar.
Se puede usar la misma técnica para ver qué #imports se pueden eliminar: en lugar de truncar el archivo, eliminar cada importación en el archivo y ver si falla la compilación.
Hace poco escribió un guión para encontrar sin usar (o duplicada) #import declaraciones: https://gist.github.com/Orangenhain/7691314
El script toma un archivo .m ObjC y comienza comentando cada línea #import a su vez y ver si el proyecto aún compila. Deberá cambiar BUILD_DIR & BUILD_CMD.
Si está utilizando un comando find dejar que el script se ejecute a través de múltiples archivos, asegúrese de usar un BUILD_CMD que realmente utiliza todos esos archivos (o verá un archivo con una gran cantidad de declaraciones de importación no utilizados).
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 todo un proyecto]).
Funciona solo para duplicados, las importaciones no utilizadas no se eliminan. – Rahul
Hemos estado utilizando un código de Ruby cosecha propia, ahora se extrae en una joya llamada fui: https://github.com/dblock/fui
no funciona con Xcode 6.4 y 10.10.5 –
fui encontrado clases no utilizadas no importadas. El nombre es muy engañoso .. – Fengson
Como paddydub dijo, AppCode hacer esto muy bien. Probé, y me tomó solo 10 minutos:
Va a Code > Optimize Imports... o ^ + ⌥ + O
Aquí hay un video describiendo cómo hacer esto: Detection of unused import and methods in AppCode
Puede usar Xcode Analizador de encontrar eso y otra problemas.
http://help.apple.com/xcode/mac/8.0/#/devb7babe820
También se puede ir con el proyecto y tipo de generación y añadir avisos de cambio de preferencias en la configuración de generación. Ver esta guía:
http://oleb.net/blog/2013/04/compiler-warnings-for-objective-c-developers/
http://clang-analyzer.llvm.org/ – slf
No estoy seguro de cuál es su punto es ...El analizador estático puede encontrar muchos problemas, pero si envía un mensaje a una variable escrita como ** 'id' **, o crea un selector para llamar en tiempo de ejecución, el analizador estático no puede garantizar que el código sea realmente no usado. Si se elimina el código que aún se necesita, es donde obtendría errores de tiempo de ejecución. ¿Me estoy perdiendo de algo? –
Además, los selectores que se crean basados en cadenas en tiempo de ejecución son bastante comunes. – dreamlax