Package names and file names are not idiomatic
tjgurwara99 opened this issue · comments
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.
Closed by #320