Is there anyway to delete the NSLog lines from the app by any trick/tool? I usually use NSLog's in each and every method to understand the flow of control and to know about the values of the app's variables. I also use lots of comment lines to explain the nature of methods and variables.
At some point these NSLogs and comment lines make the program hard to for me to understand. So I need to keep deleting and recreating them. Is there a way to show/hide them by any trick in Xcode?
Use the global research & replace tool (cmd-shift-f, or Edit, find, Find in Workspace)
Clic on Find, select Replace
Style => Regular expression
For the NSLogs, search
NSLog\(.*\).*$
and replace by a space.
For the comments, search
\/\/.*$
and
\/\*.*\*\/
and replace by a space.
And finish by replacing manually those ones
/* fjeizghrij
eopgfjeipgez
*/
because I don't know how to grab them safely?
EDIT :
At last, beware of this global replace because you won't be able to undo ! Copy/paste your project before, for example. You should use the preview fonctionality of the global replace too, and check each entry.
I'm not sure what the exact reason is why you want to remove the NSLog lines and comments.
if you can read the source code hard, to remove the comments, set the comments colour in the Xcode preferences to same as the background or set their font size to 1 and you won't see them when you read the code. :)
I have no idea for the NSLog, but I'm using the following way to avoid the unwanted logging in the final release.
this is a simple macro:
#ifdef DEBUG
#define DebugLog(...) NSLog(__VA_ARGS__)
#else
#define DebugLog(...) { }
#endif
I'm using the DebugLog(...) as I would use the NSLog(...) normally, and the Xcode is logging only in DEBUG mode, I don't need to remove any log when I create the release version of the app.
Related
An open-source project I contribute to uses banner style (also called Ratliff style). It looks like that:
// In C
for (i = 0; i < 10; i++) {
if (i % 2 == 0) {
doSomething(i);
}
else {
doSomethingElse(i);
}
}
Some IDE's like QtCreator have their own configurations for formatting, but others, like Visual Studio Code, require a .clang-format file.
I looked online for existing configurations, and couldn't find any. Then I tried to make one from scratch using this clang-format generator, but I couldn't manage to indent the braces right.
So, is it possible to create a clang-format file for Ratliff/Banner style, or is there some missing configuration that will force us to use some other generator?
This answer is not going to be the "answer" that you were looking for, but it is what I've discovered over the last two days of digging through the code for clang-format. I, too, have been looking for a way to auto-format a variant of banner style with clang-format.
clang-format seems to be missing some capabilities that would enable it to auto-format banner style.
For instance, you need to indent ending (right) braces for code blocks. clang-format does not even appear to track ending braces, but it does track starting (left) braces within its internals.
I started out my studying streak thinking I could understand the way clang-format implements its formatter system, so I could add the features needed to do it. Sadly it was way too complicated for me.
Perhaps someday we will be able to auto-format banner style with clang-format, but not today.
If someone out there knows this answer is inaccurate, please don't hesitate to correct me.
edit: Instead of giving you just a verification of what can't be done with clang-format, perhaps you might find http://astyle.sourceforge.net useful.
I want to have some "god mode" boolean toggles to quickly change functionality inside my app.
The previous developer created #define macros for these in a file that's included (indirectly) in every other file, but there are some disadvantages:
Every change has to be commited in git
Every change forces a build of the entire project
Is an xconfig file suited for this case? I accomplished what I want by:
Creating an .xconfig file
Adding it to the project
Adding HACKS_TEST = YES to it
Adding preprocessor macro HACKS_TEST=${HACKS_TEST} to the project target
Adding static BOOL const IOHacksTest = HACKS_TEST
and upon logging it, the value is printed correctly. But, if I change the HACK_TEST's value in the .xconfig file, it still builds the entire project. Also, adding one 'hack', needs modifications in the .xconfig file, project target's preprocessor macro section and project's global file.
Is it possible to achieve this without the need of an entire project build?
Is there another solution that doesn't require these many modifications on new 'hacks' adding?
Is there another solution that is more appropriated to my needs and/or easier/better?
What is the best way to have them set to NO for the Release configuration?
Edit:
Along the selected solution, I also added this in the Globals.m file:
if #debug
BOOL IOHacksTest = YES;
#else
BOOL IOHacksTest = NO;
#endif
so for Release builds, all the "hacks" are turned off automatically.
Every change has to be commited in git
You can't, or really shouldn't try to, avoid this. If there's some setting that can affect how the whole project works, it should be archived with the project.
As you've discovered, putting the values in an .xcconfig file doesn't have much advantage over having #defines for everything - if you change the xcconfig file, yo have to rebuild everything.
To avoid that, you'll want to split the declaration and definition of the variables between a header and a source file. So, you'd have a goobals.h file that contains "extern" declarations, like this:
extern BOOL IOHacksTest;
And a goobals.m file that has:
BOOL IOHacksTest = YES;
Then you include goobals.h wherever you need the declarations. If you need to change a value, you only need to recompile a single file.
1, Is it possible to achieve this without the need of an entire
project build?
If you want code to be compiled differently, based on those changing values, then there is no way to do it. In fact, you want the project to be recompiled, because the generated code needs to change.
The best way to prevent an entire project build is to put those values into a header file, and selectively include that header file only in files that need to know about the values that could change.
Is there another solution that doesn't require these many modifications on new 'hacks' adding?
There is no way getting around it if you want compile-time detection. If you change the values, then the compiler has to generate new code. How could the compiler generate the right code if it does not know about the custom changes you want to make with your "changes?"
Is there another solution that is more appropriated to my needs and/or easier/better?
That depends on your actual needs, which you didn't state in the original question. If you must have compile-time knowledge of the changes, you can use the header files, or you can add values to .xcconfig files, or just set them in the project. However, you will still have to recompile all the code that is impacted every time the values change.
If you want the settings to be changed at run time, then this is precisely what NSUserDefaults is designed for. Set an initial value in the source code, or in the Info.plist file, and set it to user-defaults on the app's first launch. Thereafter, you can manage the values from user-defaults.
What is the best way to have them set to NO for the Release configuration?
static BOOL builtInDebugMode = !!(DEBUG);
EDIT
Also, what does !!(DEBUG) do? – Iulian Onofrei
That's a logical-not operator, employed twice. It ensures that its operand will always be either 1 or 0. It was there to guide you to how it could be done (i.e., consider DEBUG or NDEBUG at compile time).
By default, your xcode configuration will have DEBUG=1 for debug builds. You could set it to DEBUG=0 for release builds, and use the above code.
As long as your code properly handles DEBUG, this should be fine. Unfortunately, some code incorrectly uses #ifdef DEBUG rather than #if DEBUG which could cause issues.
Thus, you may be better off with something like...
#if DEBUG
static BOOL builtInDebugMode = YES;
#else
static BOOL builtInDebugMode = NO;
#endif
When compiled in debug mode, DEBUG will be defined as 1. When not in debug mode, it will not be defined at all.
Or, you could add a definition to your project file DEBUG_VALUE
You can set some value in NSUserDefault, is very easy to use, I think.
You can add buttons to your app's UI to toggle these values, or you can let app query some website for this value at first launch, depends your needs.
NSUserDefault is fast.
And you can query at launch, and use it util app quit.
In searching for this I could only find info for other languages. I would like to know the best practice for writing conditional statments such as:
if (DEV_MODE){
//do something
}else{
//do the real stuff
}
And then setting DEV_MODE on or off in some global file so I only have to change that to on or off instead of changing code in multiple places. I have some ideas but am looking for advice on the best way to do this.
Try this:
#ifdef DEBUG
// do stuff
#endif
The current version of Xcode automatically sets this macro in new projects. Go to your projects Build Settings to make sure. If it's not there you have to add it yourself:
(This question is not related to Xcode.)
That said, instead of polluting your code with C-style IFs, you can use preprocessor directives to filter out debug and release mode. As far as I know, it's a common practice to define the DEBUG macro to 1 if in testing mode, and not to define it if in release mode. (Also, Xcode may define this for you, I've seen this behavior having been relied upon.) The reason is that the use of the preprocessor is more readable, since it doesn't get into the indentation, it's better separated from the code visually. To sum up, try
#ifdef DEBUG
// do debug stuff here
#else
// do release stuff here
#endif
One extra argument for preprocessor macros is that you can conditionalize the global namespace, which you couldn't within C code. I. e., with preprocessor macros, you can write
#ifdef DEBUG
int functionOne()
{
}
#else
char *functionTwo(int a)
{
}
#endif
You couldn't do this without the preprocessor.
Preprocessor variables are what you want, in your build configurations define a variable (DEV_MODE for example), and then use preprocessor checks like:
#if DEV_MODE
//dev mode code
#else
//non-dev mode code
#endif
In your project settings there is a section called "Preprocessor Macros". In that section you can add a string for your Debug build such as "DEV_MODE" or whatever you want. Then you can do your conditions you listed above and when your app gets built for "Release" or any other setting that does not contain your macro your check should fail.
I'd like to move from NSLogging all over the place to using breakpoints for logging where the performance hit doesn't preclude it.
I know I can just po an object with a Debugger Command action, and I know I can just log any string by choosign the Log Message action.
And I think I should be able to combine both by choosing Log Message and entering something like SomeText giving context for object description: #(const char *)[[anObject description] UTF8String]#. Unfortunately, this doesn't seem to work, and always gives me what I assume to be the pointer to the description string.
What am I doing wrong?
It's kinda tricky but I think that this will work. Set the breakpoint Action as a debugger command. Then use this text as the action:
po (NSString *) [#"Some text describing: " stringByAppendingString:(NSString *)[anObject description]]
You must always be very careful to cast return types when working in the debugger. Both with GDB and LLDB.
I like your idea of using breakpoints to avoid the performance hit, but this also means that your logs will only be printed when connected to a debugger. While NSLogs will buffer their output to the system log, viewable from the Organizer (Devices) in Xcode.
(Edit: I missed the question's point and it's not an answer)
I think it's best to use DebugLog. It's a macro, and you can disable it easily (it's on when you def-ine DEBUG in your debug builds and is off when you don't define it). So, there's no performance degradation (quite the contrary).
Simply replace
NSLog(#"Hello, World!");
with
DebugLog(#"Hello, World!");
And instead of
19/4/12 8:55:52.949 PM Dictionary: Hello, World!
You'll get:
BetterDictionary.m:737 Hello, World!
(it shows which file and even which line has logged it)
Which is infinitely more interesting. undefine DEBUG for your production build and DebugLog won't be called at all.
And don't forget to #import 'DebugLog.h'.
If I added a user-defined setting in my build configuration, how can I read that setting in my Objective-C code?
I have two files in my project, debug.plist and release.plist. I want my MainApp.m file to read one of these files based on which build configuration is running. I set up a user-defined setting named "filename" in both the Debug and Release configurations to point to the appropriate file. But I don't know how my MainApp.m file can read the filename variable from the current running configuration.
Here's what I did, I'm not 100% sure if this is what you're after:
Go into the build Settings panel and choose the gear icon in the bottom left: add User-Defined Setting
Create your user defined setting, for example:
MY_LANG -> en_us
Then, in the Preprocessor Macro's setting, you can reference that value:
LANGCODE="$(MY_LANG)"
Now you can refer to LANGCODE in all your source files, and it will be whatever you filled out in your custom build setting. I realize that there's a level of indirection here, but that is intentional in my case: my XCode project contains a bunch of different targets/configurations with their own preprocessor macro's. I don't want to have to go into all of those, just to change the language code. In fact, I define the language code on the project level. I also use MY_LANG in a couple scripts, so just a preprocessor macro wouldn't do. There may be a smarter way, but this works for me.
You can access your user-defined build setting at run-time (as suggested in a comment by #JWWalker)
Add an entry to your Info.plist file, and set it to your User-defined Build Setting
MySetting -> ${MYSETTING}
Read its value from code
Objective-C
[[NSBundle mainBundle] objectForInfoDictionaryKey:#"MySetting"];
[Edit] Swift
guard let mySetting =
Bundle.main.object(forInfoDictionaryKey: "MySetting") as? String
else { print("MySetting not found") }
Swift 4
Lets say "filename" is the String you need in your app.
Add filename=YOUR_STRING to user-defined setting(for debug and release).
And add filename = $(filename) to info.plist.
Then in Swift code:
if let filename = Bundle.main.infoDictionary?["filename"] as? String {
// do stuff with filename
}
else {
// filename wasn't able to be casted to String
}
Your code can't read arbitrary build settings. You need to use preprocessor macros.
EDIT: For example, in the target settings for the Debug configuration, you could add DEBUGGING=1 in the Preprocessor Macros build setting, and not define DEBUGGING in the Release configuration. Then in your source code you could do things like:
#if DEBUGGING
use this file
#else
use the other one
#endif
I tried zmippie suggestion but it didn't work for me.
I got it working with this:
${MY_LANG}
In case anyone else is still stuck looking for how to do preprocessor macros, look for the Apple LLVM - Preprocessing section in Build Settings. Under it, you will see a section called Preprocessor Macros.
This is where by default, Xcode inserts the DEBUG=1 macro for the debug build configuration.
You can add your own here, and give them different values for debug, release and any custom build configs you may have.
To add one, double-click on the current value list for the config you want, and it'll display a nice little editor with one macro on each line. Just add your own macro name, and give it a value the same way the DEBUG one is done.
These can be checked during the preprocessor build phase using #if, #ifdef etc. to provide conditional code or values.
Hope that helps.