Modular•6mo ago

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•6mo 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•6mo 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!•6mo 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•6mo ago

Or even worse ?: DType.

Nick!•6mo ago

Perhaps this should be raised as a Github issue

Joe•6mo 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•6mo ago

Thanks Joe

sora•5mo ago

Hey, Joe. And update for this? Shall we bring this conversation to GH?

Joe•5mo 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.

Stijn•5mo ago

Sorry for the delay. Filed the issue here https://github.com/modularml/mojo/issues/2557

GitHub

[Docs] Mojo style guide for value parameters · Issue #2557 · modula...

Where is the problem? https://github.com/modularml/mojo/blob/4d0b45f74fbcf883c63603a762b0c5c3a11895ed/stdlib/docs/style-guide.md#code-conventions What can we do better? Moving a discord discussion ...

Gaming

Programming

Parameters style guide