How to check for functions which have no callers in the whole project?
I have turned these flags on: Unused Functions, Unused Values, Unused Variables in xCode, but it did not work.
Thanks a lot.
My guess is because Xcode doesn't look for Objective-C and Swift methods, Xcode looks for C functions instead.
Actually, there is no an efficient approach to do this with Xcode. You can try to find occurrences of those specific fields and methods using project find tool and comment or change access level of those fields and methods to compile errors. If you try to use one of the last one approaches, the fact of your project build successfully doesn't means you made your clean up correctly, KVC or #selector aren't detected in compile time, because it is accessed dynamically in run time.
I know AppCode have this as default and other useful tools to makes the code better.
Related
I'm trying to use Clang's new objc_direct_members as such:
__attribute__((objc_direct_members))
#implementation ViewController
...
#end
However, the compiler tells me warning: 'objc_direct_members' attribute isn't implemented by this Objective-C runtime. It does this regardless of whether I'm building for arm64 or x86_64. What might be the issue?
And before we get sidetracked by questions like "why would you need objc_direct_members?", I will simply say that there are numerous reasons such as smaller binary size due to less ObjC metadata.
__attribute__((objc_direct_members)) requires both, support in the compiler and support in the runtime. As the error message tells you, the runtime in the SDK of Xcode 11.4 did not have support for that in the runtime, so the compiler cannot use it as it cannot make that happen all by itself. The LLVM devs add features like this to the compiler but they are not the ones managing the Objective-C runtime, this is done by Apple and only by Apple, unless you want to use an alternative Obj-C runtime but LLVM doesn't have an own one. You cannot use Obj-C at all in clang unless your system provides a runtime for it.
I will simply say that there are numerous reasons
such as smaller binary size due to less ObjC metadata.
This is in fact rater neglectable unless your project is tiny. Reasons to use it are rather:
Way smaller call overhead (as low as calling a C function)
No exposed symbols for these methods
No way to accidentally override a "private" method (Obj-C doesn't have private methods, but you can have a method that is not exposed by the interface)
No way to call private methods
Unfortunately the last one however makes testing these methods impossible from within unit tests.
I find that Swift is quick to mark down changes i make as compiler errors in the side panel, and then when i compile, it decides i am right after all. Is Swift just pessimistic about my code?
Can I get the compiler to wait for me to finish the line before declaring it wrong?
There is nothing pessimistic. Xcode uses the same tool - the compiler - to get the errors. However, it usually compiles only one file, using cached compiled objects for the other files. It also doesn't invoke the compiler after every change in your code, so errors that are already fixed can stay there in the side panel.
Building the project fully forces Xcode to refresh the cache and get the current list of errors from the compiler. I do agree that Xcode has many imperfections and this is one of them. When you can't find an error, just rebuild the project.
Note that IDEs for other languages often rebuild the project automatically to solve such problems. This is currently not an option in Swift because it would take too much time.
I was wondering if there is a quick and effective way to remove all the unused variables (local, instance, even properties) in xcode... I am doing a code cleanup on my app and if I knew a quick way for code refactoring it would help me a lot...
Thanks...
It's being a long time since you made your question and maybe you found an answer already, but from an answer to a related question:
For static analysis, I strongly
recommend the Clang Static Analyzer
(which is happily built into Xcode 3.2
on Snow Leopard). Among all its other
virtues, this tool can trace code
paths an identify chunks of code that
cannot possibly be executed, and
should either be removed or the
surrounding code should be fixed so
that it can be called.
For dynamic analysis, I use gcov (with
unit testing) to identify which code
is actually executed. Coverage reports
(read with something like CoverStory)
reveal un-executed code, which —
coupled with manual examination and
testing — can help identify code that
may be dead. You do have to tweak some
setting and run gcov manually on your
binaries. I used this blog post to get
started.
Both methodologies are exactly for what you want, detecting unused code (both variables and methods) and removing them.
Here's a different one from the usual confusion over duplicate symbol errors... :-)
I'm working on some legacy Mac code in an Xcode project that has the same global, "trace", defined in several different source files - for instance:
File1.c: SInt32 trace;
File2.c: Boolean trace;
etc. It's clear the original author meant them to have file-specific scope, but just neglected to prefix any of these lines with "static". That's fine, easy enough to fix.
But I'm kind of shocked the linker isn't flagging these! It looks to me like Xcode's linker (I presume gnu ld) only emits duplicate symbol warnings or errors for functions, that are linked into the code segment - but not global variables that are linked into the data segment. Instead, it silently conflates them, which is causing bugs.
So... how do I convince Xcode to emit link errors for duplicate global variables? Or get this information in some other way that can be a routine part of my build?
Well, I thought I'd answered my own question... :-)
I posted earlier:
So if you're using Xcode with LLVM GCC
4.2, go to the build settings dialog, find the "LLVM GCC 4.2 - Code
Generation" section, and check the "No
Common Blocks" checkbox. This enables
the compiler's "-fno-common" option,
and changes the object file generation
so that ld will choke and emit an
error if you have two globals in
different source files with the same
name.
Unfortunately, that doesn't seem to solve all instances. It seems to work fine if all the globals have the same type.
But the example in the question is taken straight from the code, where a variable named "trace" is defined as a global in two different files with two different types. And that's still not caught by the build system when I check that checkbox.
I'm getting a bit more seasoned with my iPhone development but I still don't know everything. One thing that bugs the hell out of me is having to add properties to a class, because there are four steps involved:
Add a class member to the Header file
Add the property definition to the Header file
Add a synthesize declaration to the implementation file
Add a release statement to the dealloc method in the implementation file
Is there any easier way to do it? A hidden feature of XCode I don't know about? A tool of some kind maybe?
Accessorizer might be what you're looking for. I've never used it personally but many Mac Developer podcasts give it rave reviews.