Dopo aver lavorato a lungo su un applicazione per iPhone, mi sono reso conto che il mio codice è abbastanza sporca, contenente diversi # import e metodi che non vengono chiamati o utili a tutti.Come individuare metodi e #import non utilizzati in Objective-C
Vorrei sapere se c'è qualche direttiva del compilatore o un modo per rilevare quelle linee di codice inutili. Xcode ha qualche strumento per rilevarlo?
Xcode permette di (dis) impostazioni di controllo per specifici avvisi del compilatore in grado di avvertire di alcuni tipi di codice non utilizzato. (Selezionare il progetto nell'elenco sorgente e File> Informazioni, quindi selezionare la scheda Genera.) Ecco alcuni (che mostrano per Clang e GCC 4.2 per me) che ti potrebbero interessare:
non vedo alcuna opzione per il rilevamento di importazioni non utilizzati, ma che è un po 'più semplice - l'approccio low-tech è solo quella di commentare le dichiarazioni di importazione fino a ottenere un errore/avviso di compilazione.
non utilizzati metodi Objective-C sono molto più difficili da rilevare che le funzioni C inutilizzati perché i messaggi vengono inviati in modo dinamico. Un avvertimento o un errore può dirti che hai un potenziale problema, ma la mancanza di uno non garantisce che non si verifichino errori di runtime.
Edit: Un altro buon modo per rilevare (potenzialmente) metodi non utilizzati è quello di esaminare la copertura di codice da esecuzioni effettive. Questo di solito viene fatto in tandem con i test automatici delle unità, ma non deve esserlo.
This blog post è un'introduzione decente per test di unità e di copertura di codice utilizzando Xcode. La sezione su gcov (che funziona solo con il codice generato da GCC, tra l'altro) spiega come ottenere Xcode per creare un codice strumentato in grado di registrare la frequenza con cui è stato eseguito. Se si prende una build strumentata della vostra applicazione per un giro nel simulatore, quindi eseguire gcov su di esso, è possibile vedere ciò che il codice è stato eseguito utilizzando uno strumento come CoverStory (una GUI piuttosto semplicistica) o lcov (script in Perl per creare report HTML).
Io uso gcov e lcov per CHDataStructures.framework e generare automaticamente coverage reports dopo ogni commit SVN. Ancora una volta, ricorda che non è saggio trattare la copertura eseguita come misura definitiva di quale codice è "morto", ma può certamente aiutare a identificare i metodi che è possibile approfondire.
Infine, dal momento che si sta cercando di rimuovere il codice morto, penso che troverete questa domanda SO interessante così:
Recentemente, ho cambiato un grande progetto da Carbonio al cacao. Alla fine di questo, c'erano alcuni file orfani che non erano più usati.Ho scritto uno script per trovare loro che in sostanza ha fatto questo:
Assicurarsi che la fonte è tutto controllato in eversione (cioè pulito) assicurarsi che attualmente costruisce senza errori (vale a dire, xcodebuild restituisce 0 Stato) Poi, per ciascuna sorgente file nella directory, vuoto (cioè, rimuovere il contenuto, troncare la lunghezza) l'origine e il file di intestazione, provare una build, se fallisce, ripristinare i file, altrimenti lasciarli vuoti.
Dopo aver eseguito ciò, ripristinare e quindi eliminare tutti i file svuotati, compilare e quindi rimuovere tutti gli #import errori.
Devo anche aggiungere, è necessario evitare i file referenziati dai file .xib o .sdef, e potrebbero esserci altri casi dinamici di collegamento, ma può comunque dare un buon vantaggio su ciò che può essere cancellato.
La stessa tecnica può essere utilizzata per vedere quali #importazioni possono essere rimosse - invece di troncare il file, rimuovere ogni #import nel file a sua volta e vedere se la compilazione fallisce.
Recentemente ho scritto uno script per trovare inutilizzato (o duplicare) #import dichiarazioni: https://gist.github.com/Orangenhain/7691314
Lo script accetta un file .m objC e inizia commentando ogni riga #import a sua volta e vedere se il progetto compila ancora. Dovrai modificare BUILD_DIR & BUILD_CMD.
Se si utilizza un comando find di lasciare lo script eseguito su più file, assicurarsi di utilizzare un BUILD_CMD che in realtà utilizza tutti quei file (o vedrete un file con un sacco di dichiarazioni di importazione non utilizzati).
Ho scritto questo senza sapere che AppCode ha una funzione simile, tuttavia quando ho provato AppCode non era così approfondito come questo script (ma molto più veloce [per un intero progetto]).
Funziona solo per i duplicati, le importazioni non utilizzate non vengono rimosse. – Rahul
Stiamo usando un po 'di codice Ruby nostrane, ora estratto in una gemma chiamata FUI: https://github.com/dblock/fui
non funziona con Xcode 6.4 e 10.10.5 –
fui trova le classi non utilizzate non importa. Il nome è molto fuorviante .. – Fengson
Come paddydub detto, AppCode farlo molto bene. Ho provato, e mi ci sono voluti solo 10 minuti:
Vai a Code > Optimize Imports..., o ^ + ⌥ + O
Ecco un video che descrive come fare questo: Detection of unused import and methods in AppCode
È possibile utilizzare Xcode Analyzer per scoprire che e altro i problemi.
http://help.apple.com/xcode/mac/8.0/#/devb7babe820
Inoltre si può andare al progetto e di destinazione costruire e aggiungere cambia preferenze avvertenze sotto impostazioni di generazione. Vedere questa guida:
http://oleb.net/blog/2013/04/compiler-warnings-for-objective-c-developers/
http://clang-analyzer.llvm.org/ – slf
Non sono sicuro di che cosa il vostro punto è ...L'analizzatore statico può trovare molti problemi, ma se si invia un messaggio a una variabile digitata come ** 'id' ** o si crea un selettore da chiamare in fase di runtime, l'analizzatore statico non può garantire che il codice sia veramente inutilizzato. Se il codice che è ancora necessario viene rimosso, è lì che si verificano errori di runtime. Mi sto perdendo qualcosa? –
Inoltre, i selettori creati in base alle stringhe in fase di esecuzione sono abbastanza comuni. – dreamlax