![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://lemmy.magnor.ovh/api/v3/image_proxy?url=https%3A%2F%2Fprogramming.dev%2Fpictrs%2Fimage%2F170721ad-9010-470f-a4a4-ead95f51f13b.png)
An autistic coder would have documented this feature to the point of pedantry.
An autistic coder would have documented this feature to the point of pedantry.
I actually agree that “good enough” code can be self-documenting, but it isn’t always enough to achieve my goal which is to make the code understandable to my audience with minimal effort. With that goal in mind, I write my code as I would write a technical document. Consider the audience, linear prose, logical order, carefully selected words, things like that… In general, I treat comments as a sort of footnote, to provide additional context where helpful.
There are limits to self-documenting code, and interfaces are a good example. With interfaces, I use comments liberally because so many of the important details about the implementation are not obvious from the code: exactly how the implementation should behave, expected inputs and outputs under different scenarios, assumptions, semantic meaning, etc. Without this information, an implementation cannot be tested or verified.
I will read that post sometime (maybe). I wasn’t really referring to some well defined thing, but rather to something that happens naturally when complex software development is done right. Quasi-scientific: make assumptions, build the thing, test assumptions, update assumptions, rinse and repeat. The “architecture” ends up being the collected knowledge about the system which emerges from the development.
Something like that anyway. Interested to read about One and Two Way decisions.
I vividly remember some of the garbage code I’ve written in the past. Huge interface definitions… Weird and brittle abstractions… Overly complex processes to do what should have been a simple task…
Funny thing is, I read and understood the same kinds of things as any other coder worth their salt: agile, SOLID, YAGNI, do one thing well, and so on – but it was all just theory. It takes experience and mistakes to really grok it all.
Is there a meaningful difference between this idea of Post-Architecture and emerging architecture?
I’ve had a colleague or two like that before. “I’m willing to put in the work to fix the code” is something I would hear, as if it were some kind of virtue. To their credit, people like this move mountains to make shit work, and it usually does. Yet, trying to read and understand their code (much less change it) is a Sisyphean endeavor.
Afaict wine uses XWayland. Sometimes with my games I’ll have problems like the game running on one display and expecting input from the other, even when I’ve switched the second display off with wlr-randr. I also have occasional UI scaling problems. Most things works well most of the time though.
With a good compositor, Wayland itself is probably ready enough for most cases. A lot of applications need to be updated to better support it though., and that seems like a lot of work.
Removed by mod
regexes are a well established solution for parsing strings. what exactly is the “proper” alternative you propose?