Basic coding tips: Getting to grips with Orxonox code
Often you'll find yourself in a situation where you have to work on a large code project you've never been involved with before. In such a situation, it is important to work systematically. This page tries to give hints and present software tools that are useful in doing so.
Navigating code with Eclipse
Using an integrated development environment such as Eclipse can make your life a lot easier by providing tools to jump around in a project. A few important shortcuts are presented below:
- Ctrl-LeftClick? on anything: takes you to where it was defined.
- Ctrl-Hover: More advanced version of Ctrl-LeftClick?, lets you choose to go to implementation, declaration or super-declaration (not the same as super sayans )
- Alt-Left: go back to where you came from after doing Ctrl-LeftClick? on something
- Ctrl-H: (Choose the 'File Search' tab): Search for text across the project
- Ctrl-Spacebar: Completion of functions, arguments etc
Getting help: Documentation and authorship
It makes a lot of sense to find out what documentation there is and who wrote the code you're concerned with. In terms of who wrote some code, look at the beginning of the file to see who the author is. Alternatively, try
svn blame filename
This outputs (rather verbosely) who wrote what line in the given file. Contact them if anything is unclear. The documentation of Orxonox is built by doing the following in the build folder:
as soon as this is done, open
In a web browser to get to the main page of the documentation. From there, you can enter the name of what you're looking for in the search bar on the top right.
General important tips
Some or all of the following are simply good practice for any project:
- Keep a log of your activities and progress. This does not have to be very formal and can be in the SVN commit messages, on a wiki page or anything you like. The more verbose, the better. Trust me (I'm an engineer ).
- Document all the changes you do in SVN. Try to commit after every big change or addition you do to code and clearly write what has changed. Browsing code differences is as boring as it sounds.
- Write the documentation while you write the code. If you implement a feature, create a wiki page on how it works conceptually, what files are involved in its implementation and
- If you work with a lot of different files, it can be useful (especially at the beginning of your work) to also keep a list of relevant files and a few comments on what is where.