That’s sick! I really love the flexibility of that.
I just had the thought, is there a style guide that I should be following when formatting code? I’m trying to make sure it looks as similar to the other panning functions as possible at the moment but was just curious.
A style guide would be good. There currently isn’t one.
When imitating the code you currently see, is there anything that you notice? Anything that rubs you the wrong way? I ask just because you’re a fresh set of eyes so it can be useful to help see the codebase differently!
I know this is slightly different from what you’re asking, but, there is mojo format. I know that sometimes teams choose a formatter to keep things standardized and avoid formatting disagreements (which isn’t a problem for this codebase, I think because Mojo very nicely has a pretty narrow set of possibilities when it comes to how to do something syntactically).
Here’s a diff of what mojo format does, just to get a flavor.
I think for the most part everything is pretty straight forward and very readable! One of the only things that I’ve noticed is that the use of the var keyword is inconsistent at times. For instance, in pan_az there are two variable declarations but one uses the var keyword and one does not:
var constant = pan * 2.0 * aligned_pos_fac + aligned_pos_const
out = MFloat[simd_out_size](0.0)
It’s not a huge deal but it makes it a little less clear to me what is an argument for the function and what is a variable declared inside the function (not that you can assign a new value to an argument obviously, but looking at a glance it would just be nice to see the var explicitly stated imo).
I’m also wondering about general organization when writing functions for readability. Should all variables (when possible) be declared at the top of the function a la Supercollider? Should variables be declared as close to their use as possible? Should comptime constants always come before runtime variables? Or should they also be defined as close to their use as possible? What about meta programming things like @parameter. I defined a @parameter function in the dbap2D function to calculate a value at compile time instead of run time. Should that be placed before variable declarations? Things like that. What I’m generally seeing and following is:
function:
documentation
error handling
comptime constants
sometimes variables? sometimes straight into code
code ...
...
return out
I do want to emphasize though how smooth the experience has been for me in terms of reading the code! Mojo’s syntax is very approachable which makes figuring out what other code is doing relatively easy. For what it’s worth a lot of my current programming has been in GDScript (a python-esque language for the Godot game engine) with a little bit of c++ and rust. Mojo was a much easier transition than c++ or rust in terms of understanding what is happening in the code in for me.
Yeah, I never use it 
. I have been writing Python for a long time where one doesn’t do that, so I’m not in the habit. I remember there being some implications wether to put var or not regarding scope, but I don’t think it’s every really come up that I’ve needed to use the var keyword in that way.
This is true, but in a function signature, if an argument is indentified as var, it passes a copy (mutable) of that argument into the function. You can see a use case here in var num_frames. However I’ve been meaning to change num_frames to an Optional[Int]…
//======================================
Here’s my take, glad to hear others’ thoughts.
I’d say close to their use. I don’t like the way SuperCollider does it.
In this case, I do tend to put the comptime declarations at the top. I think it’s C++ muscle memory, but I don’t think that’s a good reason. Maybe I should start putting them closer to where they’re used. Unless it is like a “global” value, in which case the top is preferred?
I think @parameter is now deprecated for comptime.
If they’re little functions, such as for passing into sort or something, then I think they definitely should go near where they’re used so that when reading the code, I can just see what sort is doing (for example). If they’re big functions, then they should probably be elsewhere.
I agree with your observation. And I think it’s a good starting point for a style-guide. I do think the local variables can just be declared when they’re needed instead of at the top, though. At some point a style guide would be nice to discuss.
So glad the code is clear. Something that I think you are seeing is that both Ted and I like verbosity over terseness. Descriptive variable names with underscores are encouraged. Readability is paramount. Consistency of function names, especially the .next() or .next_xxx() functions is good to follow.
Otherwise, there is no style guide.
Something I like about Mojo is that it is a relatively simple language. And audio processes are usually linear and not too complicated. Some are, but those can easily be broken into clear functions.
Sam
I really appreciate the verbose variable names. With VSCode’s autocomplete it’s rare to ever need to type more than 4 characters anyway. I’ll update the arguments for dbap2D to be a little more descriptive as well.
I personally feel that a style guide is a good thing, not only for maintainability but for learning as well. Having everything structured the same way makes parsing what’s happening a little quicker. One of the pain points when learning Supercollider for me was that the examples would be formatted in different ways: some using different syntactic sugar, some using ~ variables, some using synthdefs, etc. It led to some bad habits for me that I had to fix later once I stumbled upon an example that had a more scalable/transferable example.
For the time being I’ll follow as closely as possible to what’s there/keep my code as consistent as possible!
I agree with Drew, I think it would be a good thing. I also don’t think it needs to be a priority right now.
The thing about a style guide is there kind of always is one, just perhaps not explicitly… as in, if someone makes a PR that does things in an unusual way or in a way that is not readable or not efficient, maintainers might say, “Hey actually, can it be this other way instead?” (this has of course already happened!).
(for example,
)
At that point there is a style guide being expressed ad hoc.
Having it typed up to point to can save everyone time. It should be quite concise. Contributors can align their code with it (if needed) before maintainers even look at it. And I agree it can help with learning. There’s not much MMMAudio code yet, but once (if?) there is, it can be a way for learners to do a reality check, as in “Huh, this code looks weird, is this normal?” and a style guide could answer that question.
What I think a style guide should not do is be prescriptive for users’ code. That code can look however they want. Also it shouldn’t be tedious or pedantic, like if there should be a space after an = or something. Checking on that is not a good use of anyone’s time.
But for things contributed to the codebase and to help learners, a “best practices” is helpful. I think a good style guide is quite concise and is aimed at saving contributors and maintainers time, not be prescriptive of others’ code.
