Home

About this project

I created this project during the 2020 COVID-19 quarantine to keep busy, learn some new languages and frameworks, keep my coding chops sharp, and create some well-rounded projects to document skills, experience, and modern adaptability.

Design principles

I tried to strike a balance between elegance and practicality:

• Game play code is object-oriented
• MVC-like separation of view (python Cmd class), controller (KlondikeGame) and models (Foundation, Tableau, etc)
• Decomposition of testable functional units, e.g. complex gameplay functions like select_tableau composed of multiple reusable functions
• Designed for test-driven development. In a future iteration (in another language), the tests can come first
• Core library to be reusable for more games, e.g. freecell, spider, pyramid, tripeaks, etc

Code style

I aimed to make the code as pythonic as possible:

• Expressive but simple and readable.
• Lots of clear comments
• Docstrings and type hints
• Functional-style comprehensions, currying, generators
• Generous use of functools, itertools, and decorators without being too obtuse.

Testing

I aimed for high coverage and testable code. The ideal state would be for 100% code coverage with meaningful tests (preconditions + postconditions), and tests portable to other languages.

Structure and packaging

The project is structured as a package installable with pip:

• Clean module/directory structure
• Minimum python version requirements
• requirements.txt and separate test-requirements.txt
• Package classifiers (python version, status, topic, etc)
• Open source license (GPL v3)
• Console scripts
• Package version

Development process

A good open source project invites collaboration, clearly documents code and goals, and tries to maintain a semblance of some kind of process (dependent on the number of collaborators of course). CI/CD is important in any project, if for no other purpose than to keep me honest about the value of my code.

• Targeted and meaningful github issues (and corresponding commit messages)
• Branch-only development
• CI (Travis) + code coverage (Codecov) metric badges
• Squash-and-merge PRs
• GPG-signed tagging and PyPI releases

Usability

I've found many projects tend to languish for lack of adoption because their creators don't tackle the barriers to entry. For users, this means the user experience. For developers, this means creating something others want to use and also don't have a difficult time digging into.

While I don't envision too many other developers contributing to a simple python game exercise (likely none, this is a pet project), I did aim for simplicity. No surprises on source checkout, no strange dependencies, no mysteries to setting up your IDE. For more complex projects, I'd normally add a docker base image for doing builds, and may do so if the project becomes more complex.