M
Modular8mo ago
Stijn

Parameters style guide

I noticed that the style guide (https://github.com/modularml/mojo/blob/4d0b45f74fbcf883c63603a762b0c5c3a11895ed/stdlib/docs/style-guide.md) Is recommending PascalCase for parameters that are values:
fn value parameter fn repeat[Count: Int]() PascalCase
fn value parameter fn repeat[Count: Int]() PascalCase
Can any of the modular people confirm that this is the headed direction? To be honest, I wasn't really doing this for values and it is really confusing with Types and Structs in my opinion. I also noticed the stdlib isn't following this, and even the docstrings example a couple of lines further of the style guide isn't.
GitHub
mojo/stdlib/docs/style-guide.md at 4d0b45f74fbcf883c63603a762b0c5c3...
The Mojo Programming Language. Contribute to modularml/mojo development by creating an account on GitHub.
10 Replies
Ryulord
Ryulord8mo ago
good catch. Snake case is also what I've been using for value parameters. It's what felt most intuitively correct to me as a python dev
sora
sora8mo ago
I too hate it with a passion and was about to raise an issue on GH. - It breaks the nice symmetry between arguments and parameters. - If this style is enforced, change an argument to a parameter means renaming everything in the function body - Makes function with overload like vectorize look extra bad:
vectorize[func, simd_width, unroll](size)
vectorize[func, simd_width, unroll, size]()
# vs
vectorize[Func, SimdWidth, Unroll](size)
vectorize[Func, SimdWidth, Unroll, Size]() # why the sudden `Size`?

vectorize[func, simd_width, unroll](size)
vectorize[func, simd_width, unroll, size]()
# vs
vectorize[Func, SimdWidth, Unroll](size)
vectorize[Func, SimdWidth, Unroll, Size]() # why the sudden `Size`?

- Inconsistent with the guideline on value aliases, as parameters are like local aliases - Looks horrible
Nick!
Nick!8mo ago
I was also on the verge of starting a discussion about this. It's nice to know I'm not the only one irked by it. Another problem with using PascalCase for values is that it makes it impossible to use the naming scheme name: Name or size: Size for parameters, which is very common and useful. This is probably the biggest issue tbh, because it will force programmers to spend time coming up with clunkier or more verbose names. (It goes without saying that more descriptive names are sometimes a better choice, but this is context-dependent. Oftentimes the most descriptive name possible is merely the type name.)
sora
sora8mo ago
Or even worse ?: DType.
Nick!
Nick!7mo ago
Perhaps this should be raised as a Github issue
Joe
Joe7mo ago
Sorry I'm just seeing this thread. I'll TAL at the style guide and comments here and open a GitHub issue. Will raise it with the team this week and we'll decide how to move forward. We're open to feedback on the style guide and none of it is set in stone. For some context, it was just an initial v0 to have something when we open sourced the library.
Stijn
StijnOP7mo ago
Thanks Joe
sora
sora7mo ago
Hey, Joe. And update for this? Shall we bring this conversation to GH?
Joe
Joe7mo ago
Naturally this fell off my radar/I forgot. Please do file a GH issue so I can properly track it and not forget. I'll bring it up now in our team's Slack channel to get some early discussion going on it.
Want results from more Discord servers?
Add your server