Setting up Code Categories allows another layer of understanding and analysis to be applied to your repo. Once you've set up Code Categories, you can unlock a higher echelon of insight around the unique strengths of your developers. For example, here's my Annual Review page with Code Categories configured:
Combining Code Categories with your Developers' Annual Review page, the manager can ascertain which of their developers are most effective at writing different types of code, whether it be backend code (models, templates, scripts), front-end code (views, Javascript, CSS), or something in between. Match Engineer strengths to issues that require those strengths, get more done, rinse and repeat.
What's more, you can scope this visualization by repo, organization, or entity, so if you have a ticket that is going to require the best backend developer within a repo, or the best developer at writing tests in your entire company (i.e., entity), Code Categories let you extract that information instantly.
linkSetting Up Code Categories
Code Categories can be defined at the entity, organization, or repo-level. If all of the repos within your entity or organization use comparable technologies (or follow similar conventions), we recommend defining Code Categories at the higher levels, so you don't have to do repetitive work setting them up in multiple repos. Code Categories are found as a tab on the left side of the screen after clicking the "Settings" tab in your main nav:
There are two aspects to setting up Code Categories: choose what you want to categorize, and write a regular expression to identify files that fit into what you want to categorize. Let's dig deeper into each.
linkChoose Your Categories
By default, GitClear suggests the following Code Categories:
Autogenerated
Controller
Devops
Documentation
Library
Model
Test
Third-party
View
These cover most of the different specialties that web engineers will range between. Want to define a category that isn't in the list? No problem. Just enter it into the Code Category dropdown:
After clicking the "Create Code Category" link, you're ready to start tracking which of your Engineers write the greatest volume of "Mobile" code.
linkDefine a Regular Expression
A regular expression is a special text string that describes a search pattern. For the purpose of using a regular expression to define your Code Category, you simply need to identify some pattern to the files that comprise a given category. Following are some common examples of regular expressions that identify Code Categories.
Files that share a parent directory. If all of your view files are placed in subdirectories beneath a common parent directory, it's easy to use that parent directory as your regular expression. For example, if all of your view files (html, php templates, etc) fall in various subdirectories under a single "view" folder, then you can use the regular expression \/view\/ to match all of your project's view files.
Files whose name follows a convention. If all your files of a certain type have a shared element in their name, this can be used to identify the files as a Code Category. For example, if all of your test files end in _test.rb (as is the case with most Ruby on Rails projects), then you can use the regular expression _test\.rb to define your "Test" Code Category.
Files with a shared extension. If the files that comprise your Code Category share one (or more) file extensions, you can use this to build a regular expression for them. For example, if you define a Code Category named "Javascript," you could define the regular expression as \.js. If your Javascript files can end in different extensions, you can create multiple regular expressions that combine to feed the main "Javascript" Code Category.
Combination of directory and extension. Let's combine the first and third examples above to show a slightly more interesting case. For this example, let's say that want our "View" Code Category to include all files in a subdirectory of "public" that end in ".js". To do this, you'd just use the wildcard operator, .*, in between the directory name and file extension. So: public\/.*\.js will do the trick, matching both the word "public" followed by a forward slash, then anything (the wildcard), then ending in ".js".
We try to make writing regular expressions as easy as possible by giving you a real-time snippet of which files are matching the regular expression you're experimenting with:
linkCopying Settings Between Repos
As mentioned above, you can define Code Categories for an organization or entity, and then remove individual repos from the full list of repos that fall in the higher-level scope:
Clicking the "X" in this case would stop the "Test" Code Category from being applied to this repo where it matches zero files.
We also offer the means to copy Code Category settings between repos. This option is available at the bottom of the Code Category settings page if you're visiting in the scope of a repo.
linkWe're Here to Help!
Please feel free to email us at support@gitclear.com if you'd like for us to work with you to get these set up optimally for your needs.