Skip to content
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

Closed
Rich-Harris opened this issue Mar 28, 2017 · 3 comments
Closed

Naming conventions #419

Rich-Harris opened this issue Mar 28, 2017 · 3 comments

Comments

@Rich-Harris
Copy link
Member

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...

screen shot 2017-03-28 at 3 36 18 pm

...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 and cat_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 of div, div_1.

@Conduitry
Copy link
Member

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 tmp (formerly __tmp) identifier is now being handled in the branch feels like it might lead to conflicts. Better probably would be to just generate it (with generator.current.getUniqueName) once, store it somewhere on the generator, and then use that in the other places where we need it, similar to how the deconflicted name for component is being handled.

@Ryuno-Ki
Copy link

How high is the likelihood that it comes to clashes when picking the next integer to append?
Is it running synchronously (unlikely to clash) or asynchronously?

@Rich-Harris
Copy link
Member Author

It's all synchronous. No risk of clashes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants