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

Issues - Oh so many issues #1

Open
TotallyNotAHaxxer opened this issue Aug 18, 2023 · 1 comment
Open

Issues - Oh so many issues #1

TotallyNotAHaxxer opened this issue Aug 18, 2023 · 1 comment
Assignees

Comments

@TotallyNotAHaxxer
Copy link

Golang is a pretty unique and also very flexible language, as I have had quite a round of experience with the language, and reading your message in the discord server, I figured I would take a look at your code. That being said, I have a unique sense of how handling this should have been done with a more- unique sense of code

> Error Handling

I noticed that in your code you either print or completely log the error as fatal under each error. Typically, if you are going to do this in a more direct production environment where errors are not handled, then you may want to create a function to handle the errors. For example, take the function below that would cut your code down by 20+ lines.

// error handling function
func CheckError(x error, message string) {
    if x != nil {
        log.fatal(message, x)
    }
}

you would call these functions where bricks of conditions are met not only to make the code much more organized but in some states less cluttered.

if err != nil {
			log.Fatalf("failed to open domains file: %v", err)
		}

would be replaced with

CheckError(err, "failed to open domains file:")

and you get the idea. I also notice that you use the log function to call this over and over within each conditional, it might be suggestive to just use another function to de-clutter. Some people do enjoy just using

				if err != nil {
					log.Print(err)
				}

but sometimes depending on the case you may want to automate that function.

> Using initiation functions

an overlooked thing within the Go programming language is the use of init functions. Init functions are initiation functions that are run before the main() function is. They can not be called, can not take arguments, and can not return data. The purpose? Well, when setting up arguments especially positional arguments within a program, it's important to maybe store data within a structure and then use init functions to fill the data. For example, take the code below.

type Arguments struct {
            DomainFile string // first argument within the script
}
var Args Arguments

// runs before main
func init() {
    	if len(os.Args) == 1 {
		fmt.Println("Please supply a file")
		os.Exit(0)
	} 
        Args.DomainFile = os.Args[1]  
}

func main() {
     // other code here
}

Redundant Else statements

when you call to check an error or even check arguments as you did below

	if len(os.Args) == 1 {
		fmt.Println("Please supply a file")
		os.Exit(0)
	} else {
        ...
} 

you create a redundant else statement. If the length of the operating system positional arguments is equal to 1 then you exit, but the program's native structure does not require an else since the code already exits if the condition is true and if the condition is false will just continue as normal. So, the else statement is not so needed here.

> Conditional Checking And Data Verification

Another huge missed thing with Go is the factor that some clients will auto-fill data, it's important that when parsing files and unique logic you make sure the data being supplied is correct especially when parsing them into http links. The following code shows what you have done.

			text := fileScanner.Text()
			fmt.Println(text)
			resp, err := http.DefaultClient.Get(fmt.Sprintf("http://%s", text))

when scanning the file and calling the default client, it might be worth it to not fully trust the user or even a program to properly supply direct host names. In the event that this is a bigger framework for future notice, you can use regular expressions or even string operations since Go has amazing support for that to check and verify that it is a properly formatted host for said needs.

@WyvDoesDev WyvDoesDev pinned this issue Aug 19, 2023
@WyvDoesDev
Copy link
Owner

Leaving open for now: Planning on refactoring and parsing better later once this project is close to completion, WIll implement cleaner/better error handling with next commit

@WyvDoesDev WyvDoesDev self-assigned this Dec 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants