Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Suggestions about project structure #964

Doodeletion started this conversation in General
Discussion options

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.

You must be logged in to vote

Replies: 2 comments 1 reply

Comment options

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

You must be logged in to vote
0 replies
Comment options

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.

You must be logged in to vote
1 reply
Comment options

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

image

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

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
not-planned It's not planned in the future

AltStyle によって変換されたページ (->オリジナル) /