search

RyanEdwardHall / anagrambler

Finds all anagrams and sub-anagrams in a string
MIT License
4 stars 1 forks source link

Library code could be moved into better location #19

Closed mcgid closed 2 years ago

mcgid commented 6 years ago

Currently, the project is structured like this:

/anagrambler.go
/anagrambler_test.go
/cmd/
  anagrambler/
    main.go
...

anagrambler.go: 'anagrambler' package, containing data structures and main program logic anagrambler_test.go: testing code for 'anagrambler' package main.go: command line tool that imports 'anagrambler', prepares user input, calls the main machinery.

This works, but there are two small issues:

  1. It seems a more common pattern for library code to live in /pkg or /internal, apparently. This does make the organization clearer; it's library code, so that's where it goes.
  2. By putting the 'anagrambler' package in the top directory or /pkg, we're essentially implicitly making a public guarantee of backwards compatibility, as per the Go project recommendations. We could consider using an /internal directory, to communicate that the code isn't yet designed for exporting. (Or is it ready for exporting? I'm not sure. Maybe it's fine.)

We could also move the anagrambler.go code into cmd/anagrambler/, I suppose; it's mainly application code, and does things like file input. You could argue it's not exactly designed as a library.

We can also just leave everything as it is and forget about it. It's not hurting anything. I want it to be """right""", but I am also definitely overthinking it.

Also the location of go-dict.txt sticks in my craw too but that's an issue with less of a canonical answer.

mcgid commented 2 years ago

I don't think I even remembered writing this when I made #20 in September, but I did exactly what I wrote. At least I'm internally consistent? Anyhow yeah, closed: done in #20.