Understanding the existing code to provide better patches

LibreOffice inherits a gigantic code base from its ancestors, StarOffice and OpenOffice. Here I discuss some notes for the newcomers on how to better understand the existing LibreOffice code, and improve the patches.

Studying the Existing Code

As said, LibreOffice is a huge code base, containing ~10 million lines of mostly C++ code. There are different assumptions, conventions and coding styles across ~200 modules that LibreOffice has.

Therefore, it is important to first, study the existing code, through reading and debugging LibreOffice source code, to understand the things that it does, and the way you can implement your ideas, including bug fixes and adding new features.

And although implementing some ideas seem to be straightforward at first sight, it is meaningful to study the details.

Quality Assurance Point of View

First of all, you should understand the thing that you want to implement. No matter if it is a bug, a new feature, or just an EasyHack, you should understand what is requested, what works and what does not work. This requires careful reading of the Bugzilla pages.

User Point of View

Then, you should try to run LibreOffice to understand the exact place in the application where you want to change. LibreOffice user interface has thousands of dialog boxes, so you need to make sure that you understand the thing that you want to do.

Developer Point of View

And at last, you get into implementing something in the code. Here are some questions that you can ask yourself about the details, when reading the existing code:

• Why this statement is here, in the first place? (detail-oriented view)
  • You can use git blame to see the last author of a specific line
  • You can use git log to study the details by knowing the commit hash
  • What can this part of code actually does?
  • Can I see its effect?

git log

Or, you may be interested in the code behavior in the big picture:

• What does the code do as a whole? (holistic view)
• There are many other statements, functions and other constructs in the code. What do they do?
• What is the overall goal of the code?
• Can I test that in action?

You can do some small changes, before even getting into implementing your idea:

• What happens if I remove it? (small changes)
• Does the removal prevent the code from working?
• Is it incomplete, or does it actually do something useful, which
• will be absent if I remove it?

Then, you can work on the actual implementation. Ask yourself:

• How can I implement the idea in its simplest form? (straightforward change)
• Does it have side effects?
• How can I make sure every thing else works as before?
• How can I write a test for it?

After understanding some of the basic details about the way things work, you may go into improving your implementation.

• How can I make it better? (sophisticated change)
• Can I make the code more robust where it is brittle?
• Can I complete the code where it is incomplete?

Final Notes

These were the questions to give you some ideas of some of the underlying complexities in the code. You can start from small changes to become familiar with these complexities, and then grow to do more complex stuff in the code.

We have various different EasyHacks in LibreOffice, with different difficulty levels. If you are interested in coding, you can always find something that fits you, and grow gradually.

You can read more in these links:

• TDF Wiki: EasyHacks
• Blog posts on some (solved) difficultyInteresting EasyHacks