I've been thinking a lot about how we write code in IDEs and organize files and classes (and types) in c# and other modern software languages and projects.
With this series of texts, I want to explore:
- Code Organization
- Why do folders and files still have such importance in modern code solutions?
- Code Editing and Visualization
- Is it possible to browse classes by how often they are edited together?
- Is it possible to visualize and even edit multiple related classes together?
- LLM
- How can we create an LLM-friendly IDE to easily see the code suggestions/changes without using
git diff?- How can we have more than one suggestion at the same time?
- Is it possible to detect similar classes and instruct LLMs to use some classes as inspiration when answering questions?
- How do we store LLM instructions as part of the solution?
- How can the generation of LLM tests be made easier?
- How can we create an LLM-friendly IDE to easily see the code suggestions/changes without using
- Can we find a solution in other fields?
Solution and Project Organization in .NET
I think we have two types of project organization:
- Language organization
- File organization
From a language perspective, we have namespaces and classes. We can argue that we have projects (assemblies), too, but is a project more of a file type of organization or a language one?
From a file perspective, we have textual files that can have a single or more classes. We have folders and Projects - specialized file types that somehow group multiple files into one unit. That grouping can be done by folder, like in .NET Core, or by direct file reference, like in .NET (classic).
Of course, c# is multipurpose language, and it does not have to follow this organizational pattern strictly, but in most cases, it does. Most of us work on enterprise projects, where c# has the most significant strengths.
The Problem? - File Centric IDEs
Modern IDEs and Text Editors can only work with files! Why do we not use a different concept to open classes and not worry about how it is stored on our data system? Why are we so focused on the concept of files? Compilers work with classes, not files.
Sure, it made sense decades ago. Just take any text editor and do the work. But, most of us today use powerful IDEs and enhanced Text Editors that use more computing power for LLMs per single call than all the computers in the world in the 60s. Why not use that power differently?
Project and File Navigation in Modern IDEs
The two most popular ways of navigating the files in software projects are the equivalent of the explorer, where we have a list of projects with a list of folders and files recursively. The second is some type of search, where we type parts of file name, class name, etc., and jump to specific parts of some file.
There are more practical ways, such as a 'go to' declaration, usage, etc. I frequently use source control's 'list of changed files' to jump to edited files. There are ways we can bookmark lines that some may find helpful.
There are options like 'peek definition' in Visual Studio and 'quick definition' in Rider that show small popup windows with details from other classes. It even gives you the option to edit the class. But it still switches your focus from one class to another, but in a popup window. You don't see the relationship.
Perhaps I'm missing something, but is the pinnacle of the environment for code writing tabs and windows?
The problem remains: There is no simple way to open, browse, and show related classes we often edit together. It is always a process to find and open related files.
Relationship-based navigation?
I am a "visual thinker". I need Trello and Post-It notes; I need some way to visualize entities and relationships.
I like working with C# in Visual Studio and Rider, but I have to "imagine the visual part." I feel there is an opportunity to create some "Class Navigator" where you can visually explore and write code through class relationships, not by file organization.
I still don't know what that would look like, but I believe there is a better way to write code than opening a file and then another file and organizing windows.
I will try to explore this topic by creating a plugin for Rider, with limited capabilities, around a single idea of alternative-related class visualizations.
Part 2 will explore navigation in modern photo libraries and how it enables "multidimensional" navigation.