👋 Howdy! I'm @JohnAlexINL/ You'll find a bunch of small widgets I've made for myself over the moons, as well as links to bigger projects I'm working on here.

🌱 If you're looking for a dev, I always love an opportunity to do something cool. I know C, JavaScript, BASIC, Python, Lua, a few different assemblers, and I'm teaching myself C# too!

❤️ I help run an indie record label! Here's a couple of our artists

• The Lithiums, "Future If Future" (Music Video)
• INoLonger, "Being You" (Music Video)
• Shane Something, "Empty Actions" (Audio)
• billie arc, "Better Off" (Audio)

• 🕸️ Weaver, tiny JavaScript webhosting library
• ✏️ nex, tiny terminal hex editor with a Nano-like interface

• 🔮 Moongin, C+Lua Game Engine w/ lightweight 2D and 3D Support
• 🐍 Garter, straightforward procedural programming language
• 🛠️ gasm, portable platform-agnostic assembler

Code should be based around and implement interfaces in a way that our logic can be plugged in and out with other code implementing that same interface.

• Avoid additional external dependencies; if you do not need it, do not depend on it
• Complicated build chains mean code that is not portable and has points of failure that are hard to hunt down
• Code with less surface area is more performant, easier to maintain, and easier to extend
• Don't Repeat Yourself; reused logic should get factored out
• Fail early & fail often; instead of nesting ifs, invert the logic and break out on failure.
• If code needs lots of comments, it probably isn't very good code
• If code cannot be reasonably read by one single person in a single sitting, it's going to suck to maintain
• Looking at a variable's name, it should be immediately obvious what it is: a function, a number, an iterator, a string, ...
• Code being readable and logically coherent is more important than "optimizations" your compiler is going to replace anyway
• If code matter-of-factly describes what it does, documentation and commentary becomes redundant

• Source distribution is always preferable; blobs cannot be ported, cannot be audited, and cannot be maintained
• Single-file source libraries are easier to include, easier to build, and easier to ship
• Definitions and interfaces should go at the top after any copyright notice
• Implementations should go in the middle, followed at the end by the full license agreement
• Platform-specific implementation should be factored out of the API functions and interfaces themselves
• Our libraries should do one thing and do them well

• Short licenses are licenses that actually get read
• As much as reasonably can-be, code should be open-sourced for its own longevity and for the community good
• Subscriptions suck. I do not want to "subscribe" or pay for a "license", I want to purchase and own.
• BSD-style licenses are based because they're straightforward
• Putting code into the Public Domain is even more based