Browse Prior Art Database

Annotate source code sections based on user code familiarity Disclosure Number: IPCOM000200633D
Publication Date: 2010-Oct-21
Document File: 2 page(s) / 24K

Publishing Venue

The Prior Art Database


This article describes the ability to annotate source code sections based on user code familiarity degree.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 01 of 2

Annotate source code sections based on user code familiarity

Disclosed is a process for using familiarity information associated with source code items to help developers easily locate relevant source code. Familiarity is determined using information describing an activity of a developer while working with the code item, a level of familiarity and when the level was assigned. Familiarity once determined can be sorted and presented in an existing directory structure of the source code items or in a flat directory structure.

Typically a developer introduces source code changes across different components in a project and after a while, the developer may not remember personally written code, reviewed code or code that was looked at closely in the past. Developers typically face the issue because too many source code files are processed too frequently.

The disclosed process provides a capability for developers to more easily locate relevant source code. Using the disclosed process indicates source code based on developer familiarity with the source code while the developer is looking at the source code. For example, there are several degrees of familiarity, including a developer wrote this code, a developer reviewed this code in the past, and a developer looked at this code in the past. Using the disclosed process enables a developer to search source code by familiarity level and when a corresponding familiarity level of code was established. The disclosed process further enables sorting source code files by familiarity, either in an existing file directory hierarchy or a flat directory hierarchy.

In one example, a developer reviews source code items for handling a life cycle of a composite bundle. There is a utility code block that helps to find a relationship between a composite bundle and a parent or child block. The developer in reviewing the logic in detail realizes the utility code block was written by the same developer for another project and the same utility code block was re-factored into the source code being reviewed.

Without using the disclosed process, an interactive debug environment (IDE) typically displays no visual indication to show when the developer is the author of a code block, even though the block has been moved into a common utility file. For example the developer visual view before using the disclosed process

CompositeBundle cb;

Bundle[] bundles = cbs.getBundleContext().getBundles(); For (Bundle bundle : bundles) {

// code to iterate bundles and take actions

…. }

The same view using the disclosed process enables placement of indicators,...