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

Clarify Naming Convention for classes/interfaces and their file names #77

Open
demisx opened this issue Nov 27, 2019 · 0 comments
Open

Comments

@demisx
Copy link

demisx commented Nov 27, 2019

Can you please clarify what should be the naming convention for classes, service, interfaces in each lib? Shall they use "ScopeType..." prefix or not? I am seeing different variants being used, even in this example repo and can't produce a clear guideline for the team. For example, I'd expect the interface in https://github.com/nrwl/nx-examples/blob/master/libs/shared/product/types/src/lib/shared-product-types.ts to follow the file name and be called something like SharedProductType to match the file name, or if this is not the convention why the module in https://github.com/nrwl/nx-examples/blob/master/libs/shared/product/state/src/lib/shared-product-state.module.ts can't simply be named ProductStateModule? Why does it have scope as part of the name? And so forth.

Can someone please 🙏 explain two things:

  1. When the file names should have [scope]-[type]-... prefix?
  2. When the classes/interfaces/constants in files above should have the same scope/type in their names and when they should not? SharedUtilCreatePostResponseInterface in libs/shared/util-create-post-response-interface/... lib sounds silly, but at least Nx 8 generates it this way.

Thank you very much.

@demisx demisx changed the title Clarify Naming Convention for classes/interfaces Clarify Naming Convention for classes/interfaces and their file names Nov 27, 2019
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

1 participant