Handy tricks you should already know
by AcidFaucet · 08/21/2007 (9:06 pm) · 10 comments
It seems theres an awful lot of posts that ask questions that could be easily solved by using the compiler (VC2003 in this case) as a work horse.
Advice Item #1: Use doxygen, not compiler related but it makes research easier. Don't forget that you can open it up with an HTML editor like dreamweaver and add your own personal notes (assuming you used HTML output).
Advice Item #2: In VC when you right click on a term you get this handy dandy option "Go To Definition." There's also "Go To Declaration" but it's not as useful. Go to definition will take you to the root of the term (typically a class).
If there's more than one definition than it will display a dialog allowing you to chose which definition you'd like to check, and of course, it tells you the names of the files where the definition appears. With some logic there's no trouble.
Advice Item #3: Use "Find in Files" (it's the button that's highlighted and showing off a tooltip). Any compiler worth anything will have such a feature, so find it and use it. By the way the shortcut is CTRL+SHIFT+F.
If you highlight a term and then use Find in Files, the dialog box will already be loaded with the term.
And when you do search, you get a nice list in a persistent little search results window. Everywhere your term shows up you'll get the filename and the line number of each occurence.
Something to consider is that if you're looking at maybe making some considerable code changes do a couple of these searches and see just how many times a term comes up. It could be a useful consideration as to whether it is really worth making the change.
Advice Item #4: If you look in the above image where I've focused on "Go To Definition" you'll see that in the right click dialog box that there's an "Outlining" option. Collapsing all outlining is a handy way to view things. It'll let you skim the junk and get to the functions that you're after. Use it, it's great for general browsing.
Advice item #5: Search for header names. There's no easier way to tell if code from a header is used in a file than to look at the headers. Using the name of a header as a search term can be a big help in understanding what's going on in the engine just by file relationships.
Advice Item #1: Use doxygen, not compiler related but it makes research easier. Don't forget that you can open it up with an HTML editor like dreamweaver and add your own personal notes (assuming you used HTML output).
Advice Item #2: In VC when you right click on a term you get this handy dandy option "Go To Definition." There's also "Go To Declaration" but it's not as useful. Go to definition will take you to the root of the term (typically a class).
If there's more than one definition than it will display a dialog allowing you to chose which definition you'd like to check, and of course, it tells you the names of the files where the definition appears. With some logic there's no trouble.
Advice Item #3: Use "Find in Files" (it's the button that's highlighted and showing off a tooltip). Any compiler worth anything will have such a feature, so find it and use it. By the way the shortcut is CTRL+SHIFT+F.
If you highlight a term and then use Find in Files, the dialog box will already be loaded with the term.
And when you do search, you get a nice list in a persistent little search results window. Everywhere your term shows up you'll get the filename and the line number of each occurence.
Something to consider is that if you're looking at maybe making some considerable code changes do a couple of these searches and see just how many times a term comes up. It could be a useful consideration as to whether it is really worth making the change.
Advice Item #4: If you look in the above image where I've focused on "Go To Definition" you'll see that in the right click dialog box that there's an "Outlining" option. Collapsing all outlining is a handy way to view things. It'll let you skim the junk and get to the functions that you're after. Use it, it's great for general browsing.
Advice item #5: Search for header names. There's no easier way to tell if code from a header is used in a file than to look at the headers. Using the name of a header as a search term can be a big help in understanding what's going on in the engine just by file relationships.
#2
08/21/2007 (9:41 pm)
Nice. Thumbs up ;) 
#3
Nice blog though - tips and tricks blogs seem to be out of fashion recently.
08/21/2007 (9:47 pm)
Darn it - I already knew them!Nice blog though - tips and tricks blogs seem to be out of fashion recently.
#4
Use C++ syntax to your advantage when doing searches.
To find out where a method is implemented, just prepend :: to the method name. Example "::getTransform()"
To find out where a method is used, prepend a -> to the method name. (Also, .method) to catch nonpointer cases.
Use codebase conventions as well.
A great example is Torque's console methods and functions. I can never remember how to generate a random number in script, but it's easy to find for if you use this regular expression "Console.*random".
I end up using these searches more than fancy languages refactoring things to get around quickly.
08/21/2007 (10:41 pm)
Awesome blog! Here are some more tips in that vein:Use C++ syntax to your advantage when doing searches.
To find out where a method is implemented, just prepend :: to the method name. Example "::getTransform()"
To find out where a method is used, prepend a -> to the method name. (Also, .method) to catch nonpointer cases.
Use codebase conventions as well.
A great example is Torque's console methods and functions. I can never remember how to generate a random number in script, but it's easy to find for if you use this regular expression "Console.*random".
I end up using these searches more than fancy languages refactoring things to get around quickly.
#5
08/21/2007 (10:54 pm)
Good stuff! 
#6
These are so simplistic in nature, and almost all of us who already know them take them for granted ... every day.
08/22/2007 (5:58 am)
Goto Declaration also has a shortcut, F12 ... not sure about Definitions shortcut ... but I usually just 'Goto Definition' with F12, Ctrl Left, and F12 again ... pesky mice ... now where'd i put that mouse trap at?These are so simplistic in nature, and almost all of us who already know them take them for granted ... every day.
#7
if you go on a tangent researching a particular class you can always use them to navigate back to your initial starting point.
also, when you're researching classes sometimes it's better to do it by browsing the header file, rather than the implementation file. if you go straight to the implementation file, you may feel overwhelmed in a sea of never ending code. browsing through the header file allows you to get a feel for the general functionality a class provides.
08/23/2007 (7:36 am)
dont forget the forward and back buttons. =)if you go on a tangent researching a particular class you can always use them to navigate back to your initial starting point.
also, when you're researching classes sometimes it's better to do it by browsing the header file, rather than the implementation file. if you go straight to the implementation file, you may feel overwhelmed in a sea of never ending code. browsing through the header file allows you to get a feel for the general functionality a class provides.
#8
Most people either aren't aware of dOxygen at all, or use it for studying "stock code", but don't use the dOxygen commenting syntax in their own code development. Spending just a bit of time learning (and using) the dOxygen commenting syntax, and regenerating your documentation in a consistent periodic manner can make your project self-documenting in many ways, and is well worth the initial effort.
08/23/2007 (8:36 pm)
I want to reinforce Tip #1 very strongly: dOxygen is your friend--use it!Most people either aren't aware of dOxygen at all, or use it for studying "stock code", but don't use the dOxygen commenting syntax in their own code development. Spending just a bit of time learning (and using) the dOxygen commenting syntax, and regenerating your documentation in a consistent periodic manner can make your project self-documenting in many ways, and is well worth the initial effort.
#9
dOxygen is a "power" of YOUR engine, and YOUR power too in development.
08/23/2007 (10:54 pm)
agree with Stephen.dOxygen is a "power" of YOUR engine, and YOUR power too in development.
#10
10/11/2007 (8:49 am)
This would have been very helpful 6 years ago. Anyone who didn't know these things should not take them lightly.
Torque 3D Owner Peter Simard