Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

modules/setting probably needs refactoring #3917

Closed
7 tasks
mikolysz opened this issue May 7, 2018 · 7 comments
Closed
7 tasks

modules/setting probably needs refactoring #3917

mikolysz opened this issue May 7, 2018 · 7 comments
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented type/refactoring Existing code has been cleaned up. There should be no new functionality.

Comments

@mikolysz
Copy link
Contributor

mikolysz commented May 7, 2018

Gitea version (or commit ref): 0b718e0

Description

The setting module has the following problems and bad code smells:

  • improper english in some comments and names (i.e. // enumerates all the policy repository creating, IsRunUserMatchCurrentUser)
  • Very long functions (NewContext is currently 399! lines long).
  • Non-idiomatic names that don't reflect what the code's doing (maybe they reflect what the code was doing earlier or what it was supposed to be doing)? Those include - Functions Named NewXXX which don't return any new instances of anything, setting global variables instead. Names like ConfigureXXX, SetXXX or SetupXXX would be more appropriate.
  • Some structs declared as type literals should be declared with normal type Declarations to avoid repeating the code (see Repository.Editor)
  • Some code is mindlessly copypasted without even being looket at. The message Error saving generated JWT Secret to custom config: %v", is repeated twice (and for a third time elsewhere, there might be more), and it appears in places completely not related to the saving of the jwt secret. The problem is the lack of a "saveCustomConfig" function and very similar code sprinkled through the module and other parts of the codebase (cmd/web.go is a good example).
  • Some variables and the code that sets them aren't close, particularly those set by NewContext (because the function is huge, breaking it down into smaller functions and breaking the big var block into many smaller ones, declared close to the related functions would probably help).
  • This is a bit of personal taste, but I believe that the ordering of the functions should be a bit different. Go is not c, and declaring functions (like DateLang, getAppPath etc.) before their usage makes the code less clear. For someone reading the file top to bottom, it's more useful to see the functions used in context and then declared instead of doing it the other way around.

I'm willing to work on this in the next few weeks if the maintainers are ok with that. I'd like to get feedback on which points to fix and which ones to leave as they are.

@lunny lunny added the type/refactoring Existing code has been cleaned up. There should be no new functionality. label May 7, 2018
@lunny
Copy link
Member

lunny commented May 7, 2018

@devil418 Please try that.

@lafriks
Copy link
Member

lafriks commented May 8, 2018

Please feel free to work on that. Also it is better to submit multiple small PR than single large as that helps to get it merged faster as it is easier to review.

@bkcsoft
Copy link
Member

bkcsoft commented Jul 8, 2018

I would start by breaking out all structs to it's own file (like modules/setting/ssh.go) with their own Parse function that gets called.

Kind of like this:

// ssh.go
func (s *SSH) Parse(section *ini.Section) error { ... }

// setting.go
// func NewContext...
ssh := SSH{}
if err := ssh.Parse(); err != nil { ... }

@stale
Copy link

stale bot commented Jan 19, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale stale bot added the issue/stale label Jan 19, 2019
@lunny
Copy link
Member

lunny commented Jan 19, 2019

Like @bkcsoft 's idea, don't close.

@stale stale bot removed the issue/stale label Jan 19, 2019
@stale
Copy link

stale bot commented Mar 20, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale stale bot added the issue/stale label Mar 20, 2019
@lunny lunny added issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented and removed issue/stale labels Mar 21, 2019
@delvh
Copy link
Member

delvh commented Apr 29, 2023

How up to date is this issue?
Can it be closed by now? The package has changed drastically…

@lunny lunny closed this as completed Apr 29, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 14, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented type/refactoring Existing code has been cleaned up. There should be no new functionality.
Projects
None yet
Development

No branches or pull requests

5 participants