Almost… To be precise it’s a Merkle DAG

One day you will inherit a code base so bad that you’ll end up commenting old code

Will not be the case, I won’t take a job, where I have this situation (or I’ll quit pretty quickly)…

Yeah my “comment standards” (btw. as others mentioned here, I was unprecise/unlucky with the choice of words, I meant “comment the why” or doc-comments totally fine and should be aimed)

Your so called comment standards and principals are fine if you are building something from the ground up

Yes that was also targeted with my comment. But what you’re referring to is just missing documentation, and I think this should be done on a higher level. The “comment why” rule applies for spaghetti code non-the-less…

Nah, it’s not, code is modular (IME should be kinda tree-structured), a book is linear.

So the API should be in your analogy the synopsis. And I haven’t said, that there shouldn’t be any comments. E.g. doc-comments above functions, explaining the use-cases and showing examples are good practice.

Actually it’s been so stable for me for at least a year (not sure when I switched exactly), that this post kind of surprised me, I thought it was > 1.0 already

Don’t get me wrong comments != documentation (e.g. doc-comments above function/method).

I probably was a bit unprecise, as others here summed up well, it’s the why that should be commented.

Yeah that’s a good summary

Yeah, but unironic…

If your code needs comments, it’s either because it’s unnecessarily complex/convoluted, or because there’s more thought in it (e.g. complex mathematic operations, or edge-cases etc.). Comments just often don’t age well IME, and when people are “forced” to read the (hopefully readable) code, they will more likely understand what is really happening, and the relevant design decisions.

Good video I really recommend: https://www.youtube.com/watch?v=Bf7vDBBOBUA

SUUUUUUUUURE!!!11 I"M oN ITTTTTTTT

We’re at 22.8̅2̅8̅7̅8̅4̅1̅1̅9̅1̅0̅6̅6̅9̅9̅7̅5̅1̅8̅6̅1̅0̅4̅2̅1̅8̅3̅6̅2̅2̅% slowly gaining rainbow ground

I just calculated exact subpixel accuracy, for me it’s exactly 20.5̅9̅5̅5̅3̅3̅4̅9̅8̅7̅5̅9̅3̅0̅5̅2̅1̅0̅9̅1̅8̅1̅1̅4̅1̅4̅3̅9̅2̅0̅ % that is still missing to fill the whole comment body with rainbows, way to go!

Let’s start the sixth rainbow!

Plenty of space for me still (browser version on desktop)

Rookie numbers, it’s probably 15% on my screen, There’s space for a lot more rainbows

“easily” solve it.

FTFY

And we’re about to enter the fourth rainbow dimension in the next comment…

We’re in the third rainbow, keep building more stripes lol

Depends on what trait bound error messages you have had yet, I had 1000 lines long already, where it’s not obvious at all what is meant (and is often a very simple fix). But I’m sure this will get better over time, there’s already a bigger ongoing redesign of the type system solver, so maybe it will be integrated into stable rust soon.

but effectively it’s bash, I think /bin/sh is a symlink to bash on every system I know of…

Edit: I feel corrected, thanks for the information, all the systems I used, had a symlink to bash. Also it was not intended to recommend using bash functionality when having a shebang !#/bin/sh. As someone other pointed out, recommendation would be #!/usr/bin/env bash, or !#/bin/sh if you know that you’re not using bash specific functionality.

Nah the old official reddit code is entirely out of date, writing up something like the original official reddit clone, is not too hard, and I would rather rewrite it (in Rust obviously ^^).

Hubzilla is certainly an interesting and ambitious project (though a PHP codebase repels me a little bit, TBH). Need to check it out further. Zot also sounds interesting. Looks a little bit like a swiss-army-knife sandbox-toolkit of federated social networks.

misunderstanding was

I think here’s a misunderstanding too :). With quickly I mean closing without getting feedback, or without providing a good reason why the issue is closed (without being obviously resolved), not the dates (which I think are only relevant, when actually awaiting a response). I have seen this over the repo a few times, good writeups often explaining some behavior etc. and then bam closed, either as duplicate (although it’s not (example)), or “not as planned” etc. I think this is not good behavior for an open source project (I’m around the block for a few years contributing and maintaining OSS, for reference…). Especially as this is a real community project and not some random opinionated application (well depending on how you define it, could be true to lemmy, but I don’t think it is…)

I rather let an issue open than close it, “just to have fewer open issues”. I can close it anytime, and if someone searches for that issue sees it closed while it isn’t resolved, it just creates confusion…