Show HN: Ease your dev life with these general naming rules(github.com)
github.com
Show HN: Ease your dev life with these general naming rules
https://github.com/kettanaito/naming-cheatsheet
4 comments
I was always struggling with one thing: the naming conventions of attributes may differ depending on if it's backend or frontend.
For example,
1. In MySQL it's common to name columns like user_name
2. In PHP you can use anything, but if you use camelCase, then it might turn out:
$userName = $user->user_name (using ORM for example)
3. In Javascript if I choose to have camelCase, which is common too, it might turn out:
fullName = user.first_name + ' ' + user.last_name
So the mix of conventions is unavoidable which is irritating.
How to deal with that?
For example,
1. In MySQL it's common to name columns like user_name
2. In PHP you can use anything, but if you use camelCase, then it might turn out:
$userName = $user->user_name (using ORM for example)
3. In Javascript if I choose to have camelCase, which is common too, it might turn out:
fullName = user.first_name + ' ' + user.last_name
So the mix of conventions is unavoidable which is irritating.
How to deal with that?
As stated in the repo, you could just go with anything, just pick one for your project, and follow. The general rule that applies here is consistency.
So let's say in PHP, the preferred convention is snake_cake, then use it for the whole project. Then if you are working on a JS project, which the team demands camelCase, then just follow it.
There could be some cases, like in your 3rd example, the team applies camelCase for normal variables, and snake_cake for properties. Again, you still have to follow if it is something the team has agreed.
So let's say in PHP, the preferred convention is snake_cake, then use it for the whole project. Then if you are working on a JS project, which the team demands camelCase, then just follow it.
There could be some cases, like in your 3rd example, the team applies camelCase for normal variables, and snake_cake for properties. Again, you still have to follow if it is something the team has agreed.
Yep, I understand, I just dislike the fact that we'll have 2 types (like fullName and user.first_name + user.last_name), even though it's an agreement.
Just a bit annoying :)
Just a bit annoying :)
https://github.com/kettanaito/naming-cheatsheet#naming-funct...
>There is a useful pattern to follow when naming functions:
>prefix? + action (A) + high context (HC) + low context? (LC)