Show HN: Ease your dev life with these general naming rules

github.com

5 points·khangnd··4 comments

I thought this part was great... I've seen this in action but I never consciously noticed the pattern.

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)

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?

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.

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 :)

Reply on news.ycombinator.com