Suggestions about project structure

[Doodeletion]

I've been using SourceGit for a few months and really enjoying it. I recently forked the project and started poking around a bit, but I found it difficult to find my way around the codebase.

For Commands, Viewmodels and Views, I think it would be easier if the files were organized in a few more subfolders, as some of these folders contain 90+ files.

For the .axaml files, I think it would be easier to read and maintain if more parts were implemented as custom controls. It can be hard to tell which part of an .axaml file renders which portions of the ui. I know that in WPF implementing such subcontrols should be implemented as custom controls rather than UserControl, because UserControls have too many restrictions. I don't know if this applies to Avalonia as well.

[goran-w]

I agree that grouping the main categories into a few subcategories would be helpful.

However, my biggest issue with navigating the codebase is that there are 29 cases of .cs files (and corresponding classes) with exact duplicate names, only in different folder (and with different base-class). Usually it's a Command and a Model/ViewModel that has the exact same name, but there are different combos (in one case it's actually a Model and a View).

The two worst cases are Blame.cs and Statistics.cs - these filenames each exist in 3 instances (under Commands/, Models/ and ViewModels/)!

@love-linger - This makes for some confusion when I'm looking in one of these duplicate-named files/classes. I have a harder time keeping track of the context when it's not obvious from the file/class name itself and must be deduced from its parent-folder/base-class...

It also makes searching harder, since there will be many "irrelevant" hits when multiple classes share the same name.

Here's the full list of duplicate filenames (along with their "parent" category-folders) :

Apply.cs               (Commands, ViewModels)
Archive.cs             (Commands, ViewModels)
Bisect.cs              (Commands, Models)
Blame.cs               (Commands, Models, ViewModels)
Branch.cs              (Commands, Models)
Checkout.cs            (Commands, ViewModels)
CherryPick.cs          (Commands, ViewModels)
Clone.cs               (Commands, ViewModels)
Commit.cs              (Commands, Models)
CommitGraph.cs         (Models,   Views)
Discard.cs             (Commands, ViewModels)
ExecuteCustomAction.cs (Commands, ViewModels)
Fetch.cs               (Commands, ViewModels)
GitFlow.cs             (Commands, Models)
Init.cs                (Commands, ViewModels)
InteractiveRebase.cs   (Models,   ViewModels)
Merge.cs               (Commands, ViewModels)
Pull.cs                (Commands, ViewModels)
Push.cs                (Commands, ViewModels)
Rebase.cs              (Commands, ViewModels)
Remote.cs              (Commands, Models)
Reset.cs               (Commands, ViewModels)
Revert.cs              (Commands, ViewModels)
SelfUpdate.cs          (Models,   ViewModels)
Stash.cs               (Commands, Models)
Statistics.cs          (Commands, Models, ViewModels)
Submodule.cs           (Commands, Models)
Tag.cs                 (Commands, Models)
Worktree.cs            (Commands, Models)

I would suggest renaming each relevant file and class (even the ones which are not duplicated, where applicable) with a categorizing suffix like Cmd, Model, VM, View (or similar) respectively.

(This would be a big refactoring effort to take on, and would put a rebase-conflict burden on contributors, but it would improve the codebase readability and maintainability once completed.)