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.)

[love-linger]

In SourceGit, namespace is used to distinguish the different functions of classes with the same name, which is also the original intention of the design of namespaces. At the same time, you can also trait the namespace as the prefix of this class.

[goran-w]

In SourceGit, namespace is used to distinguish the different functions of classes with the same name, which is also the original intention of the design of namespaces. At the same time, you can also trait the namespace as the prefix of this class.

I understand your point. However, having identical names for the classes means the namespace prefix would need to be present everywhere for clarification - and since it sometimes isn't (inside the same namespace, for example), it still affects readability and searchability.

In a line like this, I can't immediately see easily which class is actually instanced here (despite helpful tooltips from Visual Assist etc - there is some more useful info in the VA top bar, but I have to click/select the identifier before I get that additional info, so it's not at-a-glance) :

A little redundancy of suffix would actually help readability here, IMHO. Additionally, it would make it more obvious if a class/files has ended up in the wrong namespace/folder.

Using the same filenames also makes it slower to switch tabs / "Open file in solution" etc, since I have to inspect the tooltip etc to make sure the parent-folder is the correct one - I can't just click/select the intended tab/item directly...