Content
View differences
Updated by Eric Schubert 10 months ago
The options so far are:
* Option A
* snake\_case: share\_point
* PascalCase: SharePoint
* Option B
* snake\_case: sharepoint
* PascalCase: Sharepoint
Jan's argument:
I still believe that treating "SharePoint" as one word/name would be the right thing to do. And it being one word means we'd code it as `sharepoint`/`Sharepoint`, because trademarks are not part of code. If I call my product "tHe AwESomePrOdUcT", you'd still call your library `Theawesomeproduct` or at best `TheAwesomeproduct` (because you'd want to encode the space in my trademark), but you'd never encode my capitilization decisions in your code. Here we do it, because it _looks like_ it could have occured like that in code.
Another good example are the trademarks GitHub and GitLab. In our codebase both usually occur has `github`/`Github`\* and `gitlab`/`Gitlab` respectively, while we spell them correctly in documentation and UI.
\* The GitHubTabComponent seems to be the only outlier here
Eric's argument:
The community around the MDN with SharePoint and OneDrive is huge, and it is almost impossible to find common guidelines on the spelling. But when looking on the [samples](https://github.com/search?q=repo%3Apnp%2Fsp-dev-fx-webparts+sharepoint&type=code&p=1) from the SPFx - the SharePoint Framework - the spelling of variables, constants and methods goes towards option A. Fun stuff: libraries are indeed spelled `sharepoint`, like written before they use the camel humps mostly in variable and method names.
Link without search: [https://github.com/pnp/sp-dev-fx-webparts/tree/main/samples](https://github.com/pnp/sp-dev-fx-webparts/tree/main/samples)
My final take probably is, that most occurrences we use are supposed to be written with the camel humps. We do not have any URL patterns, where microsoft uses `sharepoint` and we do not export any libraries. We "only" name variables, classes, and methods.
* Option A
* snake\_case: share\_point
* PascalCase: SharePoint
* Option B
* snake\_case: sharepoint
* PascalCase: Sharepoint
Jan's argument:
I still believe that treating "SharePoint" as one word/name would be the right thing to do. And it being one word means we'd code it as `sharepoint`/`Sharepoint`, because trademarks are not part of code. If I call my product "tHe AwESomePrOdUcT", you'd still call your library `Theawesomeproduct` or at best `TheAwesomeproduct` (because you'd want to encode the space in my trademark), but you'd never encode my capitilization decisions in your code. Here we do it, because it _looks like_ it could have occured like that in code.
Another good example are the trademarks GitHub and GitLab. In our codebase both usually occur has `github`/`Github`\* and `gitlab`/`Gitlab` respectively, while we spell them correctly in documentation and UI.
\* The GitHubTabComponent seems to be the only outlier here
Eric's argument:
The community around the MDN with SharePoint and OneDrive is huge, and it is almost impossible to find common guidelines on the spelling. But when looking on the [samples](https://github.com/search?q=repo%3Apnp%2Fsp-dev-fx-webparts+sharepoint&type=code&p=1) from the SPFx - the SharePoint Framework - the spelling of variables, constants and methods goes towards option A. Fun stuff: libraries are indeed spelled `sharepoint`, like written before they use the camel humps mostly in variable and method names.
Link without search: [https://github.com/pnp/sp-dev-fx-webparts/tree/main/samples](https://github.com/pnp/sp-dev-fx-webparts/tree/main/samples)
My final take probably is, that most occurrences we use are supposed to be written with the camel humps. We do not have any URL patterns, where microsoft uses `sharepoint` and we do not export any libraries. We "only" name variables, classes, and methods.