#Training testing, error handling and project layout with a number-guessing game

7 messages · Page 1 of 1 (latest)

jaunty cloak
#

Hello đź‘‹,

I’m excited to share my first Go project—a CLI number-guessing game! 🎉

While it’s a simple game (guess a number between 1 and 100), the real purpose of this project is to train and improve my Go skills, focusing on:

  • Testing (unit and integration tests)
  • Error handling (custom error types and context)
  • Code structuring (encapsulation, separation of concerns, and scalability)

Repo link: for feedbacks.

Roadmap.sh link: for upvotes.

While it’s not groundbreaking, I’m proud of how far I’ve come and wanted to share it with you. Feedback is always welcome, and upvotes would mean a lot—it’s the result of a year of learning while balancing code, life and work. At one point, I almost stopped programming because I struggled with understanding testing and structuring even a small app. But I finally figured it out.

Thank you for taking the time to look, and I hope this inspires others to keep learning and growing. ❤️

solemn pewter
#

feedback: great you did something to help you learn. I wouldn’t use cmd/ for a single binary, I would also not use internal/ for this. also what do you mean by scalability in this cli?

#

the why is on my blog (linked on my discord profile)

#

module in go.mod does not match the path, thus making go run/install not working

#

requiring a config file to be present / not embedding a default is also not a great ux

jaunty cloak
#

Hi @solemn pewter , how are you? Thank you for your responses!

  • When I mentioned scalability, I was referring to how easily new commands or features can be added. For example, the scores feature was added in this manner. However, following your question, I wonder if “scalability” is the right term to use here?

  • I went through your publication yesterday, and if I understood correctly, you’re suggesting that having only a main.go file in the root directory is preferable? Where would I put my configs then?

  • This approach would then resolve issues with go run and go install, correct?

  • Regarding the point about requiring a config file, I’m not sure I fully understand. Could you elaborate further, please? I chose this solution because I thought it would be cleaner than having large string literals directly in the code. Since the config file is already part of the project, isn’t it essentially embedded in a way?

solemn pewter
#

  1. maybe “extensibility” ?

  2. yes but that’s orthogonal to where configs are

  3. the go.mod bug is also orthogonal to where main and configs are. though having at the top makes for shortest go install/run

  4. using https://pkg.go.dev/embed you can have a default config file in the binary