When I first opened Xcode, I was frustrated to find that it didn't work like other IDE's that I had used in the past. Thankfully, after playing around with the preferences, I was able to create a more comfortable environment for programming. The following tips are some things that you can try to make your coding a little more enjoyable:
Code Completion
- Open Preferences > Code Sense. Ensure that "Show arguments in pop-up list" is checked.
- Click on Key Bindings. You must check to make sure you have hotkeys assigned to the "Completion List". This is found under the "Edit" subheading. By default, you can show the Completion list by striking the escape key. Unfortunately, there is currently no option to show the completion list automatically.
Jumping between placeholders
When using the code completion functionality, Xcode will put in placeholder tags, which look like little blue ovals with the name of the data to be entered. You can use the shortcut ⌃/ to jump to the next placeholder, and ⌃⇧/ to jump to the previous one.
Embedded Editor
Depending on your personal preferences, you may find it easier to open a separate window for each file you edit. However, if you would like to edit each file inside of the main Xcode pane, simply click the Editor button in the top bar of your project window. You may now switch to different files by simply navigating the tree in the left pane.
Switching Between .h and .m Files
It is very common to switch between the header (.h) and implementation (.m) files for a class as you work on a project. Instead of browsing for the complementary file, you can press ⌥⌘↑. This will open the corresponding file in a new window (if it isn't already open), unless you've selected the "Open counterparts in same editor" option in the General preferences.
Adding credits to your About window
Add an RTF (Rich Text Format, editable in TextEdit) file called "Credits.rtf" to a *.lproj directory in your project. If you use the standard Cocoa 'About' window, the RTF file's contents will be shown in it, in a scrolling text field, if necessary. (Note: This hint is not unique to Xcode 3.)
Keyboard Shortcut List
PDF/PNG available on Cocoa Samurai
Editing Identifier Names
Names of classes, methods, functions, variables, etc. are often composed of several words that have been squashed together. To avoid confusion, the first letter of each word (except the first word in many instances) is capitalized. However, this make the identifier appear as a single word, so ⌥← and ⌥→ skip over the entire thing. However, ⌃← and ⌃→ will skip by "word" within the identifier. Handy, and it works in other applications besides Xcode!
Jump to Declaration and Documentation
Classes and variables are everywhere in Cocoa! It's easy to lose track of where they're declared. However, you can ⌘ + double click on any variable or constant and jump instantly to where it's declared, even if it's in a system .h file. Likewise, you can ⌥ + double click on any class name to be taken to its documentation in the Xcode Docs.
Setting Breakpoints for Cocoa Methods
You can set a breakpoint for a Foundation or Application Kit method by specifying the class and selector. Show the Breakpoints window (Run ▸ Show ▸ Breakpoints, or ⌥⌘B), double-click the title of the item at the bottom of the list and type the name, like -[NSException raise] or +[NSObject allocWithZone:]. (When debugging, execution will halt at these breakpoints; although you'll see assembly instead of source code, you can get a stack trace.) To break at a function, just enter the function name, like myAwesomeFunction. One method that's very useful to set as a breakpoint is objc_exception_throw. That's the method that gets called when any exception is thrown.
Setting Permanent Breakpoints in gdb
If there are methods or functions that you wish to set breakpoints for in every debugging session, you can put one on each line of a file located at ~/.gdbinit after the keyword "fb". For example, if I wish to break anytime an exception is raised or passed within Objective-C, my ~/.gdbinit file might look like this:
Since Xcode uses gdb for debugging, these breakpoints will work in every Xcode project, and even if using gdb from the terminal.
