The ability to annotate 'regions' of code as belonging to one or more 'purposes'.
Ability to query for desired sections of code. Example: "Show me all code chunks related to double-clicking, security, and databases (SQL) in modules, or functions having the text 'major' in their name."
The ability to sort and group by various dimensions would also be desirable when displaying or printing code.
"Query" here may refer both to a query language similar to SQL, or query interfaces, such as QueryByExample.
The ability to 'view' (e.g. in a debugger) dataflows that are actively being processed through regions selected based on programmer interest (via query).
The ability to 'hide' regions of code in which we are not interested
That is one reason I miss the IBM ISPF editor - you could hide both rows and columns of text.
I've always wanted a global hide-all-comments toggle so that no vertical space is wasted.
The ability to actively 'edit' in a view the code we control that is associated with certain regions or dataflows (with support from the IDE to warn of potential or likely breakage even in hidden regions)
Security to control who can read and edit which "kind" of code segment.
Open Issues and Important Questions
Will it just process/manage code text, or also be integrated with other tools, such as the debugger, interpreter, etc.
How close will it be tailored to a specific language? Does it need to "understand" (parse) a given language in order to handle it for needed features (listed above)? Generally it will fall into one of these sub-categories:
A specific language has built-in meta-classification or aspect features, and the tool is closely aligned with these feature.
A "kit" will be provided that serves as a template to build language-specific tracking tools that fairly closely fit a given language's style.
A generic tracking tool that heavily uses built-in indirection (lots of many-to-many tables) in order to sufficiently "flex" to a given language per parameter configuration. Let's call this the SAP model.
Will it be a "two-way" tool such that one can switch between traditional code editors and/or the file system's view, or will editing be primarily initiated within the tool?
It may be possible to launch an existing file-based code editor to use with it, but it may be acting on a "dummy" or temporary file such that the code manager tool actually hides or removes the file system. For example, when a developer clicks on "Edit", the tool makes a file copy in a temporary folder, launches the COTS code editor, and when finally saved, moves the copy back into the database. (The details of knowing when the developer is "finished" need to be ironed out.)
Should programming style change to take advantage of new tools?