Cataloging Source Files

In trying to organize and sift large quantities of source code files, I've found that the LimitsOfHierarchies keeps mucking things up. There are multiple aspects to search and/or group or view by, and trees tend to favor one over the others. Plus, moving the files around a source tree to make adjustments tends to break references.

Thus, I dream of using TableOrientedProgramming to search and organize files. Just keep them all in a flat folder and use a database browser and/or QueryByExample as the "front end" to find, query, and list source files.

To facilitate this, some form of cataloging source and config files is needed. (Doing it at the method/function level is also something to consider, but existing tools are not ready for that yet. See SeparationAndGroupingAreArchaicConcepts for more on that level of cataloging. Doing it at the file level gives us more options with existing tools/IDE's.)

Here's a draft form to hint at the kind of info that could be collected:

  ************************************************************
  SOURCE FILE CATALOG FORM
  .
  File Name: ________________ Extension: ______
  Description: _______________________________________
  Primary Purpose:    {// also consider check-boxes instead of radio buttons}
    (_) Library/Utilities
    (_) Configuration/System
    (_) Tabular or Summary Report
    (_) Detail Report/Screen (read-only)
    (_) Web-Page (end-user)
    (_) Data/Content Entry Screen
    (_) Wizard/Dialog/Picker/Finder/QBE
    (_) SQL query or procedure
    (_) Batch processing (little or no UI)
    (_) Content (image, document, data file, etc.)
    (_) Other/Mixed UI
    (_) Other/Mixed Non-UI
    .
  Check all that apply:
    [_] Security-related
    [_] Admin/Power-User/Back-End Audience
    [_] Printer/paper/PDF-related
    [_] User Help or Documentation-Related
    [_] Internal Documentation-Related
  Entities Read:
    {// list of entities/tables that are read from}
  Entities Changed:
    {// list of entities/tables added to, changed, and/or deleted.}
    {// (A fancy version could distinguish between these change kinds, }
    {// but that may be over-kill in my opinion.)}
  .
  Parent File: ______________ . _____  (if applicable)
  Notes: ___________________________________________________
  .
  ************************************************************

(Square brackets are check-boxes and round ones are radio-buttons. Dots to prevent wiki formatting bug.)

The front end would use this info, and perhaps optionally search the source text also for key-words. If it's integrated with source search, then the "read" entities probably shouldn't be formal inputs because searching on table name is perhaps "good enough"; for hand-cataloging each is rather tedious and error-prone.

Even if you decide to make the top-most list non-mutually-exclusive, I would still recommend having one and only one primary because it works better for basic listing (directory-like listings). Filtering is still available for multiple secondary categories ("OR").

--top


See also: SeparationAndGroupingAreArchaicConcepts, FileTreesToManageCodeDiscussion


CategorySourceManagement, CategoryInfoPackaging


EditText of this page (last edited May 3, 2013) or FindPage with title or text search