I will also add that it has been my recommendation that the first thing we do once the DAO is launched is add a (preferably ICRC3) archive of absolutely all state changes, so everything is entirely auditable.
Everything is not perfect yet. I only joined a few weeks ago, but I did take over the responsibility, so all I can really do is to give credit to the previous dev where the code is good and take the blame where it is bad, so that’s what I’m here to do.
Fair mate I’m just calling for good code - I thought perfection was required that’s all, that’s what is holding me back on SNS’ I’d say are much more mature than this.
I’m not against Taco or anything, i didn’t get that far, if my devs coded that I’d be annoyed let’s say.
I get you just got hold of the repo.
All the best.
I’m gunna break it down when I got time in the next few days - it’s more than just a single function name.
Like if this is productions ready, your comments don’t say that
Production adjustments everywhere.. it’s the whole thing it just looks unfinished to me.
Like I get it but I tell my devs never leave comments, is this required is it not.. it’s just unclear in a lot of places.
Like you wanna add comments to inform me great
but not in each file consistently
Just hard to get round the repo and that’s before i go into the functions and overall structure and scalability of it
Ah for this one the point is we need to send a prop to update it once we know the new TACO DAO principals. So this one actually makes sense.
As for the commented away stuff, I hear you, the code cleanup will continue but for now I am not yet familiar with the code that I want to delete (and search for clues in git history), I prefer to comment away instead.
Not disturbing me at all…this is actually fascinating.
I took a look at the code you linked from the twitter post.
It is quite impressive…I’ve never quite seen someone write motoko code that actually looks like rust. It is so organized and systematic that it blows past English sensibility to German levels of structure.(I’m not good with my European banter so I hope that was witty and not racist.)
So here’s the thing…My actors look like yours too. But my next-level library code is less compartmentalized and patternized. I don’t know that this was a conscious choice, but I see something emerging out of this. If someone reads your waterway file they can say “This file says it does something.” If they read the TacoDao actor they see exactly what the software does. The motility of the code is on full display sometimes in painfully long scripted sequences. When I get to the end of that file I may be disgusted as a computer scientist, but I don’t doubt that the code does SOMETHING. In your waterway project, I had to go through about 4 folders, sometimes two layers deep to finally find some code that did something to/with a piece of data. I 100% understand that this is the way software is supposed to be written when you are on a team and you have resources and only trained people will see or care about the code.
When you are writing software for grumpy assholes with tokens it might be that one big ass actor is far more effective in getting people to see, engage, and understand what you are trying to do.
I’m not saying you can completely debase yourself and throw sound best practices to the wind, but if your code can’t be read by a DAO voter such that they can tell what you are doing but perhaps you’re losing something important.
I’ll point out is that the Waterway project seems to be a very self-contained thing that you control.
The TACODao code I did audit was trying to do a couple HARD and VARIABLE things and keep things outside the control of the DAO in check. Some of the breadth of the code is likely from that. Keeping cycle attacks from spam should be an easy problem to solve. With a bit of an update to candid to limit the input size of text and blob we could mitigate like 75% of the problem, but the reality is there is no real defense against someone who really wants to cycle drain you by creating a bunch of canisters and then spamming you. They may need money, but they can do it. It is a messy problem to solve and the resulting code reflects that. Likewise, neuron tracking with hotkeys is just a bad design and bit of a mess that it is the only way we have to get that information. It is a function of us not having figured out the async data thing. All in all, much harder problem to solve than a self-contained creation. When they start dealing with the difficulties of Kong/ICPSwap it is going to get interesting.
Second, this dev improved such a massive amount from v1 to v2. A very long way to go to be sure, We should likely be a bit careful about the gatekeeping around knowing manager and observer patterns. People are going to build DAOs and the code will get better the more people see the code and make it better. I wrote a bit more about it here: Upcoming TACO DAO SNS Decentralization Swap - #15 by skilesare. I hope the dev keeps building because if they improved that much in a couple of months then they’ll be a valuable part of the community for a long time. This code gets open-sourced so we can all learn. We should do it constructively.
I’m retiring, I’m out 
I try to write code like a story, language is everything. I’m all for domain driven design and I believe it gives me an advantage for the AI I’m training.
All public and we are moving things to mops all the time lol - I post regular articles about the methodolgy and encourage real projects to use this code. It’s the integrations into the daos, dapps etc that is cool too.
I hear you, so I get a pass for a couple SNS’? I didn’t think so.
Bare in mind my limited resources but look at the timeline of the code in the repos, the abstraction towards design patterns and a component based back and frontend architecture should be clear, that is the same in 15+ repos now.
This is a much deeper philosophical question than you may have intended. Bluntly, we should have had 500 various DAOs by now and some of them should have failed super hard. Maybe then we would have had some real breakouts. Forcing everyone to be perfect on the first go and get past the NNS before you can get your icon on a list was perhaps, in hindsight, not the best idea.
The ideal level is likely somewhere between “all the stakes are on the line and it needs to be perfect or the NNS will make fun of me” and “let’s just wing it with this tiny wacky thing and see how it goes”.
I don’t have the exact answer.
I won’t have a single DAO that fails mate.
I want to emphasise that this comment concerns the previous dev, who was the one to implement those improvements! I have barely had time to touch the code, and I have only tried to add the minimum instrumentation required to feel confident in launching.
So, I am not blowing my own horn when I say I think the code is generally quite good. I agree with Afat that it is a fascinating debate, and one I have engaged in countless times and from many angles. Back in my day, the most general version of the debate was procedural scripting vs object oriented programming. I have come to land in an “it depends” position, not unlike what Afat describes.
In general, I prefer an OO style code base with small functions that each do as little as possible (yes you can do that with FP, and even with PP, I’m talking from the old general perspective of OO vs Procedural). Following the rule that no method should be more than 10 lines long is not a bad idea. But there are use cases where the “script pattern” always emerges as popular, and orchestration is one of them.
Still, long methods do hurt my puny brain and I will probably break things up and refactor quite a bit over time.
This was good.
Thank you for taking the time to write this comment out. As the frontend dev on the project, I had no idea these guys were building turbo encabulators back there 
James it sounds like your gripes are with formatting, commenting, and documentation. Duly noted my friend, we will work on this, the project does need to survive the team winning the lottery (was told this is a better analogy than getting hit by a bus)
“I try to write code like a story, language is everything. I’m all for domain driven design and I believe it gives me an advantage for the AI I’m training.”
Then that is another thing we have in common 
I have the majority of my career in Language Oriented programming, Domain Specific Languages and DDD.
I just want to say we have one frontend dev (me) and one backend dev (tirex, now snassy), with regular full time jobs (edit: just me, snassy is full time), getting paid nothing (all equity for me, tirex was the same, snassy is being paid), doing this on nights and weekends, living the dream
Again, I have not stopped working on this night and day for years, spent a lot of ICP to design and build great code so just have standards for what projects get the same level of consideration.
I know what it is like to do work outside of a job to get things done, just for me this is everything.
I don’t wanna be negative, I’m genuinely trying lol - I’m glad you can see the room for improvement and I wish you all the best on it.
So we’re both working hard building on the IC, I love it. Your initial comments felt a little FUDy instead of constructively critical, and I feel like your issues are with the follow-alongability of the code, not the logic. I agree we have a lot of work to do on our documentation, it’s high on the list for us. How we interact with fellow builders on here is critical to the ecosystem, let’s do it right
