Hello, have you consider any code style like in https://github.com/TheAlgorithms/Python/blob/master/CONTRIBUTING.md#coding-style ? I don't see any CONTIRBUTING.md file in this repo. Maybe it will be worth it? How about using gofmt:https://golang.org/doc/effective_go.html#formatting ?

My second question is: can we add unit tests to github action? For now we only have lint check.

Description
Implement an algorithm to decide whether a vertex is a cut-vertex or not. The algorithm will return a list of boolean with the ith index representing whether the vertex i is a cut-vertex or not.

For new implementation:

• Articulation Points/Cut vertices are special vertices in bi-connected graphs which when removed decomposes the graph into two or more connected sub-graphs https://en.wikipedia.org/wiki/Biconnected_component

Description
The currently README file is not appropriate. Instead of describing a few algorithms, it should contain

• general information about the repo
• link to guidelines
• directory structure

Take reference from the following README files
https://github.com/TheAlgorithms/C-Plus-Plus/blob/master/README.md
https://github.com/TheAlgorithms/Python/blob/master/README.md

For disconnected graphs like the below graph, it will catch in an infinite loop.
Also, this implementation doesn't support the directional graphs.

For more info this link will help

Add a .travis.yml file to this repository.
Refer to this doc https://docs.travis-ci.com/user/languages/go/

golangci-lint run --no-config searches

##[error]searches/binary_search.go:20:6: `iterBinarySearch` is unused (deadcode)
func iterBinarySearch(array []int, target int, lowIndex int, highIndex int) int {
     ^
##[error]searches/binary_search.go:6:6: func `binarySearch` is unused (unused)
func binarySearch(array []int, target int, lowIndex int, highIndex int) int {
     ^

2 implementation of linked lists are present please convert them in 1 folder. or delete the repetitive one.

Description
The ExampleAlgorithm function gives a actual runnable block of code for the specified algorithms which works automatically in the documentation - ref here. It's kind of similar to the main function that many people submit in the repository. An example in our repository is given here if you further click on that example it would take you to the our GitHub repo where this example is written.

For new implementation:

• Adding Example functions would give a new way for contributors to contribute and an additional resource for people to learn from.

For enhancement:

• For now, we should discuss on whether this is a good idea and collectively agree or disagree with this.

@halafi Can you please make some changes in https://github.com/TheAlgorithms/Go/tree/master/strings ?

1. The directories contain spaces instead of dashes in the directory names. This forces us to quote the directory names when using command line tools such as linters.
2. File names need work also. Is ac.go a calculation for alternating current or is it controller for an air conditioner? Is bom.go a tool for building a bill of materials or does it generate a byte order mark? Why does the reader have to guess?? aho-corasick.go is a much more self-documenting filename than ac.go.
3. Can you help us to get the last two lines of .github/workflows/golangci-lint.yml to pass without || true?

Add Bogo Sort Algorithm implementation

Description

Title is self explanatory. The Go idiomatic style of package name is very different from the recent merge of #313 . For reference see this blog post on go.dev. The relevant line states that, "Good package names are short and clear. They are lower case, with no under_scores or mixedCaps."

In #313 the author has changed old names with under_score naming conventions – depending on the maintainers preference this may be okay, however since this repo is for learning, it might be a good idea to adhere to the idiomatic style of Go as this constraint is one of the main reason which makes it easier for large teams to adopt go as it has only one specific way of doing things (albeit its not enforced sometimes). This may be good for other languages but its not idiomatic in Go.

Another point I would like to make is that file names with under_score.go conventions have some predetermined rules for Go build tools. For example, the file name ending with _test.go are checked by go test. Another example is that the file names ending with _linux.go builds only on linux and file names ending with _amd64.go will only build on an amd64. Same applies for different go versions _go113 etc. For further information on go build constraints, please refer to go help command go help buildconstraint, this will show you all the main constraints that go build tools have.

Proposed Solution:

Package naming: My opinion is that we should combine the types of packages together to make it easier to navigate the source. For example, consider the cipher package, instead of having multiple packages within that package for caeser cipher etc, we could create a unified package which is more easier to navigate and manage. This is not a unique idea and if you review the standard library this pattern appears everywhere in standard library. If, however, it is not possible to combine packages, we should try to keep the packages abbreviated – in the mean time someone tries and changes the code to work in a unified manner – even if it may not be easier for a reader to understand. The reason I suggest this, even though it is difficult for the reader is because the file names would still contain the full name of the algorithm/implementation and since the source of this repository is usually kept well documented, it will not be very difficult to understand what each package abbreviation stands for when a reader opens the source. Nevertheless, this is just my opinion and the decision is left up to the maintainers.

File naming: Technically this is not wrong (as this is not enforced by go build tools) but again if the go devs made some changes to the build strategy and added some extra keywords for later versions of Go, it may create issues (although this is highly unlikely to happen but is nonetheless its not idiomatic). I propose that we should keep the names without underscore even if the names are big, this pattern is also not new and is present in the standard library (for example poolqueue.go or waitgroup.go - notice no underscores). The underscores are specifically used to interact with the go build tools and in my opinion, shouldn't be used. But again, it is up to the maintainers to decide.

I believe this should be a separate issue - do let me know if I should create one and I'll oblige.

Issue:

For any algorithm, we have some intermediary functions that are used within the main algorithm that we want to work on. For example, suppose I'm working on an implementation of algorithm A and it uses another algorithm B inside it. Suppose this algorithm B is already present in this repo, so I should create only algorithm A and use algorithm B that was already defined instead of creating my own implementation of B. The reason for this is quite simple, the algorithm contributors want to make should be self explanatory which makes it easier for people to understand self contained code without replicating code (and making their own implementations for A and B densely coupled). You may have already noticed that, within this repo majority of the implementation repeatedly creates the same intermediary algorithm (I'll refer to it as B) for different implementations of their main algorithm (I'll refer to this as A). This is again not an issue when learning and people should at least implement intermediary algorithms at least once but since the intermediary algorithms created do not usually get tested (either because they are coupled strongly or there is very low cohesion in their code). This is also something that people learning to program should work towards, as it keeps to the separation of concern and their code bases maintainable.

For solution to this, I propose that maintainers should include a clause in How to Contribute.md so that the algorithms that they are writing and all the intermediary steps that their algorithm requires are not present anywhere within this repository. They should implement a new intermediary algorithm if and only if there is no implementation of intermediary steps or the intermediary implementation is somehow flawed which should be pointed out in the documentation and PR description. The chances are that the intermediary steps have already been implemented in the repo and when there is already a good (and tested) implementation within this repo it is unnecessary for them to include a new implementation just for one algorithm.

Maintainers, do let me know of your thoughts.

Description
Hello,
I think this package very good resource and I thought implementing design patterns here would be a good addition to the repo.

For new implementation:

• creational
• structural
• behavioral

What do you think and is there anyone I should add to the review?

Description
The dynamic programming approach for finding the longest increasing sub-sequence in O(n^2) within an integer array is defined here: https://github.com/TheAlgorithms/Go/blob/master/dynamic/longestincreasingsubsequence.go. However, there's a greedy approach which solves the problem in O(nlogn).

For enhancement:

• Greedy logic for finding the longest increasing sub-sequence in lesser asymptotic time.

Describe the bug
A clear and concise description of what the bug is.
Fix the failing rsa tests so they pass and then remove | grep -v /rsa from

• https://github.com/TheAlgorithms/Go/blob/master/.github/workflows/golangtests.yml#L13

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Please add more algorithms to this repo.

See the structure and README of this repo for reference
https://github.com/TheAlgorithms/Python

Traversal is error of binary-tree.go.

// LNR
func inorder(n *node) {
	if n == nil {
		return
	}
	inorder(n.left)
	fmt.Print(n.val, " ")
	inorder(n.right)
}

// NLR
func preorder(n *node) {
	if n == nil {
		return
	}
	fmt.Print(n.val, " ")
	preorder(n.left)
	preorder(n.right)
}

// LRN
func postorder(n *node) {
	if n == nil {
		return
	}
	postorder(n.left)
	postorder(n.right)
	fmt.Print(n.val, " ")
}

Traversal is error of binary-tree.go.

Many files have code which is commented out (Especially main functions as tests). Remove them and write proper tests.

There's a lot of main packages in this project

sorts/selection_sort.go:1:package main
sorts/Heapsort.go:1:package main
....
....
other/PasswordGenerator.go:5:package main
other/PrimeNumbers.go:1:package main

We can improve this package organization to let each package have its place

Description
Currently the repository is in a good condition to start thinking about how to better explain things to students. I personally use TheAlgorithms repositories for inspiration, so I think it should be great if we can start writing good documentation which can make it easier for us students to understand the nitty-gritty of algorithms better.

For new implementation:

• Documentation: The GoDoc org provides a very clean and elegant way of showing documentation of your repositories. For example, if you just go to the link https://pkg.go.dev/github.com/TheAlgorithms/Go/ here, you will see that this repository's documentation works but it isn't up to good standards (for lack of a better word).

For enhancement:

• Specify what needs to be changed and why. For example:
  • To improve the documentation, I propose we start writing documentation in a way that works well with the GoDoc orgs system. Whilst this may take some time, I believe this is achievable and would help raise the standards for this repository. In the meantime, we should ask the PR authors to check whether their code's documentation is up to standards by asking them to check their fork's documentation using https://pkg.go.dev/github.com/<username>/Go/ and accept them if this is well written.

Do let me know of your thoughts. I'm also open to suggestions for creating a automated documentation using GitHub-pages. In my personal opinion, the styling for the godoc command is very simple and therefore I personally prefer the GoDoc org's documentation generation. (To be fair, we cal also automate the styles from GoDoc org's pages with the wget command but it may take some time to get it right.)

An improve in this repository could be remove commented main functions and add tests for the code in order to provide examples and let the code be executable easily

Describe the bug
@tjgurwara99
Our GitHub Action is testing github.com/tjgurwara99/Go/... not github.com/TheAlgorithms/Go/...

To Reproduce
Steps to reproduce the behavior:

1. Look at the path in the output of our GitHub Actions go tests. We are testing tjgurwara99, instead of TheAlgorithms.

Expected behavior
A clear and concise description of what you expected to happen.
We test github.com/TheAlgorithms/Go/...

Screenshots
If applicable, add screenshots to help explain your problem.

Run go test $(go list ./... | grep -v /sbom | grep -v /rsa)
?   	github.com/tjgurwara99/Go/ciphers	[no test files]
ok  	github.com/tjgurwara99/Go/ciphers/caesar	0.016s
ok  	github.com/tjgurwara99/Go/ciphers/polybius	0.010s
ok  	github.com/tjgurwara99/Go/ciphers/rot13	0.005s
ok  	github.com/tjgurwara99/Go/ciphers/xor	0.006s

Additional context
Add any other context about the problem here.

Need to write test.go files for the following unmarked directories as we are using non-executable packages. (no package main at the top)

• ciphers
• data-structures
• dynamic-programming
• other
• searches
• sorts
• strings

Describe the bug

The go.mod file in the tag v0.0.1 is incorrect and still contains my GitHub handle for the Go repository.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'tag v0.0.1'
2. Click on 'go.mod'
3. See the first line

Expected behavior
The first line should be module github.com/TheAlgorithms/Go instead of module github.com/tjgurwara99/Go
Also the required module has been removed from the code so it can now be deleted.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Our GitHub Actions lint and test our code really fast.

Gitpod runs in parallel and is slowing down the feedback to our contributors that their pull requests tests pass.

Does anyone actually use Gitpod for this repo or can we remove it to speed up our turnaround time?

From our GitHub Actions...
go test $(go list ./... | grep -v /sbom | grep -v /rsa)

• ciphers [no test files]
• datastructures/binary-tree [no test files]
• datastructures/dynamic-array [no test files]
• datastructures/linkedlist/doublylinkedlist [no test files]
• graphs/breathfirstsearch [no test files]
• graphs/depthfirstsearch [no test files]
• graphs/floydwarshall [no test files]
• other/maxsubarraysum [no test files]
• other/nestedbrackets [no test files]
• other/passwordgenerator [no test files]
• other/stringcombinations [no test files]
• strings/single-string-matching/bom [no test files]
• strings/single-string-matching/horspool [no test files]

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

For example, in sort, there are 2 selection sorts and 2 insertion sorts. Besides minor differences in formatting, these files are identical. Not sure which should be kept and which should be deleted.

Adding license to the repository officially allows the developers/coders to modify and enhance the code.
If you allow me, I will submit a PR which will add license to this repository and hence close this issue.

I have implemented Disjoint Set Union in GoLang.
Wanted to Contribute here.

Quicksort doesn't sort in place. I was studying algorithms the other day and decided to try and implement quicksort in go. It was apparent that implementing an in place sorting algorithm would be tedious involving pointers and pointer indirection, so I decided to check the one already implemented here. And it's implementation is incorrect. It's still close enough to quicksort but the additional work that goes on to combine slices adds an overhead that shouldn't be there with quicksort. I will make a PR to address this soon!

Describe the bug

In the file CONTRIBUTING.md, there is a section with the heading "Code Formatter". This section describes how to install go, and it has build instructions that may be out of date since they refer to the nonexistent file "main.go"

To Reproduce
Steps to reproduce the behavior:

1. View the file https://github.com/TheAlgorithms/Go/blob/master/CONTRIBUTING.md

Expected behavior

• I would expect this section to contain instructions something like "run the command go fmt".
• I would expect the existing content to be in an earlier section of the document with a header like "Installing Go"
• It might be helpful for beginners if there was a unified section of the document with sub-sections for installing go, running the existing code, formatting code, etc. The section on preparing pull requests could then just reference the earlier section.

Hi everyone, as you may have noticed, there's some activity going on recently in this repo. That's me cleaning it up :) I'm a new maintainer of this repo and will do my best to review and give feedback on new PRs. There are a lot of old ones at the moment and I'm not a Go expert to try and fix issues found in them on my own. So, please update your PRs by merging in the latest master branch and making sure that all checks pass. I'll try to review as many PRs as I can as soon as possible, but many of them will be closed by stale bot too. If your PR is marked as stale, please comment on it to show that it's not abandoned and I'll review it when time allows.

Describe the bug
The readme contains links to files in different directories than actual ones. For example, directory is cipher and readme is linking to ciphers

I feel that the rate at which PRs are merged will have a huge impact on the growrate of this repo's codebase. Right now we are still implementing the basic algorithms, and it really should not take this long to review our commits. You could also grant write access to the more active developers,xd.

Description
Provide a clear and concise description of the issue.

For new implementation:

• Name and problem statement for the algorithm.

For enhancement:

• Specify what needs to be changed and why. For example:
  • Adding tests.
  • Optimizing logic.
  • Refactoring file and folders for better structure.

For Python, the LGTM tool is nearly useless so we got rid of it. Is the same true for Go?

Describe the bug
A clear and concise description of what the bug is.
Fix the failing sbom tests so they pass and then remove | grep -v /sbom from

• https://github.com/TheAlgorithms/Go/blob/master/.github/workflows/golangtests.yml#L13
  To Reproduce
  Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Description
Currently the dynamic programming examples, no implementation of Fibonacci sequence has been made. This is by far the most common and beginner friendly example for dynamic programming. I would like to implement the same.

For new implementation:

• Fibonacci sequence using dynamic programming.

I can't find a place to say my needs, so say it here : I need php ,

Description
IMO algorithm should be working on data type float64 instead of int.

For enhancement:

• All the algorithms should be converted to use float64 as an arguments. Followings are the possible enhancements.
  • User must handle the type conversion of int to float64.
  • Should provide both type where int internally uses float64 related function.

The Contribution Guidelines are empty.

I added some functions to binary-search-tree but not able to push. It says I do not have access. Is this the problem or something unrelated ?

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Few years back I implemented common string matching algorithms in Go, seems like they belong here, would a PR be welcomed or is this no longer actively maintained?

Python equivalents are here

I was looking over this repository and I noticed that lots of the files have commented out testing methods, however some have no proper tests. It seems to me that there's no centralized testing for the repository, and I think that it would be beneficial.

Proposal:

• Centralized testing (go test) for entire project at once
• Integration with CI (Github actions - test and lint on each new PR)
• Code cleanup and migration of tests in main() methods to unit tests

Thoughts? I would be happy to work on this if others think it would be useful!

In the file golangci-lint.yml...

• Remove || true from ciphers -- Fixed in #222
• Remove || true from data-structures/binary-tree
• Remove || true from data-structures/dynamic-array
• Remove || true from data-structures/hash-map -- Fixed in #222
• Remove || true from data-structures/linked-list
• Remove || true from data-structures/trie
• Remove || true from dynamic-programming
• Remove || true from other
• Remove || true from searches
• Remove || true from "strings/multiple string matching"
• Remove || true from math/sieve

Describe the bug
The AddAtEnd function of singlylinkedlist has a fixed argument type of int, so it can only add nodes of type int to the single linked list.
file: structure/linkedlist/singlyinkedlist.go
function: AddAtEnd(val int)

Expected behavior
Any type of value can be added to a single linked list.