-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Naming conventions #419
Comments
I like the idea of trying to tidy this up a bit. I just pushed a branch with an initial stab at this. Because of how all the identifiers are generated on the fly, knowing in advance that a particular one will be reused sounds like a lot more trouble than it's worth. The way that the |
How high is the likelihood that it comes to clashes when picking the next integer to append? |
It's all synchronous. No risk of clashes. |
use snake case in generated identifiers (#419)
This is just me being a bit anal, and it's entirely my fault in the first place, but I think the internal naming conventions in the generated code could be nicer. In this example...
...there's all sorts going on —
renderMainFragment
,text$1
,eachBlock_anchor
,eachBlock_iterations
,cat__index
and so on.I propose that we use snake_case for all generated identifiers, use a convention of adding
_1
,_2
and so on to identifiers that need to be deconflicted, and avoid__
double underscores. This would be more consistent, a bit easier (everything is lowercase, no worrying about capitalising things or whatever), and would make it easy to distinguish between generated code and helpers.So the examples above would become
render_main_fragment
,text_1
,eachblock_anchor
,eachblock_iterations
andcat_index
.Relatedly, it would be a tiny bit neater if we knew in advance that a particular name was going to be reused, so we could have
div_0
,div_1
instead ofdiv
,div_1
.The text was updated successfully, but these errors were encountered: