Developers, who are responsible for writing software, often write hundreds of thousands of lines of code. Additionally, in many instances, a team of programmers jointly write code, & commit their work to a “team” repository.
Much can go wrong, & it’s very often difficult to find bugs or even remember where & how certain problems were solved — particularly if obscure functions were used, or classes written to solve a half-remembered issue. For this reason most IDEs have an inbuilt search facility, which allows developers to search via file or directory name, & some even maintain an order or work as to when a file was last modified.
Repositories such as GitHub offer these facilities as well. Nevertheless, if the code is like a labyrinth, & much of it certainly is, these search facilities may be inadequate, & particular functions & necessary points in code may take hours or even days to uncover, which is a waste of precious time.
Google maintains many hundreds of thousands of lines of code, & employs thousands of developers, most of whom work in teams. Understanding the issues & the failings of IDE’s Google developed its own mechanism for digging into their code (especially open source code) & accurately pinpointing lines of code that required attention.
Realizing the value of its tools & the lack of equivalent resources on the market, Google has made its search facilities widely available. Code Search for Google open source projects is, according to Google’s developer blog, it’s most popular internal tool.
Google’s tools enable deep & through searching facilities & include a “blame” button, which shows who last changed any line of code, & can pull up a history file as a text file, clearly showing all changes.
“Suggest-as-you-type in any search box annotates suggestions with the type of code object, the repository & the path, helping users find what they want faster.”
– Google
Google’s search “language” is quite specific, & involves either wrapping your search terms in quotes, for code related queries, or using file or directory names without quotes to find items that you know the name of or at least part of the name.
Naming classes, functions & files, is elective, & often has little to do with the nature of the code. A programmer can name a function that adds up variables, for instance, findPrice, & may not remember that this function simple creates a total of the variables coming in for addition, & might think it’s a search function – by being able to quickly pull up underlying functions, such as mathematical functions, the role served by the code would be far easier to establish, making it much easier to fix issues.
Google’s language supports regular expressions & search atoms, which allows developers to search in a way they personally understand & are used to. Cross-referencing between repositories is powered by Kythe, which supports the programming languages Bazel, CMake, Maven, & Go.
However, Kythe also offers wrappers for other build systems. Clicking on inbuilt functions, methods & classes, which are not elective, will pull up a cross reference of all instance of the operation across the code, making it easier to understand the flow of logic & identity problems.
See below supported languages:
- Angular
- Bazel (with cross-references)
- Dart
- ExoPlayer
- Firebase SDK
- Flutter
- Go (with cross-references)
- gVisor (with cross-references)
- Kythe (with cross-references)
- Nomulus (with cross-references)
- Outline
- Tensorflow (with cross-references)
Image credit: Google dev’s blog
