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

Variable name pattern #57

Open
zongqichen opened this issue Sep 4, 2024 · 4 comments
Open

Variable name pattern #57

zongqichen opened this issue Sep 4, 2024 · 4 comments
Assignees

Comments

@zongqichen
Copy link
Contributor

I notice there are some variables named with special pattern, e.g. fReadORDExtensions, aServices, aODMEntity, having prefix like f and a. I want to discuss that, where does this pattern coming from? Do we have chance to get rid of it? Or we have to use it because it meets the requirements of CAP framework?

I briefly look other repos under cap-js, such as cds-typer and cds-dbs, there is no such naming pattern. So I want to listen others opinion.

@Fannon
Copy link
Contributor

Fannon commented Sep 4, 2024

I would be in favor of removing this "hungarian" notation. With an IDE and a compiler / language server, we already know what type a variable is. Adding types to variable names is therefore not needed and just adds noise, imho.
I would therefore just go with the typical JavaScript conventions as most open source projects, which is variable names in lowerCaseCamelCase that express the meaning (not the technical type).

@ductaily
Copy link
Contributor

ductaily commented Sep 4, 2024

Specifically fReadORDExtensions I would define functions using the function keyword. It is much more clear. If there is a reason why functions must be defined using const then it is a different story. But I am not aware of any. If anyone knows please correct me.

@zongqichen
Copy link
Contributor Author

Specifically fReadORDExtensions I would define functions using the function keyword. It is much more clear. If there is a reason why functions must be defined using const then it is a different story. But I am not aware of any. If anyone knows please correct me.

I'm also confused about function creation in javascript, there are ways like statement, expression and arrow function. From my side, they are slightly different, but the purpose is same which is improving code readability and flexibility. Sometimes, expression and arrow functions are opposite, reduced the readability. I would propose that we use statement function as high priority but not strictly forbidden other ways to create function.

@Fannon
Copy link
Contributor

Fannon commented Sep 4, 2024

https://dev.to/skinnypetethegiraffe/function-or-const-which-do-you-prefer-typescriptjavascript-apa

States it well. Reasons for going with function :

  • The intent is clear and concise, so that readers quickly differentiate between variables and functions. The faster you know what is going on, the better right?
  • Function hoisting, meaning it lets you use a function before you declare it in your code, where with const it will be undefined until it has been reached in the execution.
  • Also hoisting issues related to using function in bundling tools is no longer the issue it once was
  • Named functions show up in stack trace messages, which is handy

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

5 participants