Ask HN: What conventions do you use for naming your funcs, vars, ids & classes?

I name them what they are. A piece of pizza is a piece of pizza, not a bowl of soup.

I try to stick to the most common conventions for the language I'm using.

For JavaScript this means:

* Classes use camelCase and start with an uppercase letter: BlogPost

* Constants are all uppercase: PASSWORD

* All other variables (including function names) are camelCase: getAllPosts

I name them as they are, in lowercase. Occasionally in Camel Case, in the event I have, say, a getter/setter. I personally dislike pressing the shift button to write stuff in camel case, it breaks my flow of typing (weird, I know.)

Classes: camelCase CONSTANTS: UPPERCASE variables_and_methods: lowercase_underscore

I think that's fine with PEP8. I'm not 100% on how to name things that can be abbreviated. I dislike using img, pwd, tmp or similar in my code, but js or id is fine and I often use db or app, but I don't feel happy about it for some reason.

You should probably specify in what language. I would use a totally different scene for C++, Java, C and so on. Normally I try and gravitate to the norm, unless there is something that anoys me.

For example I dislike C++'s standard to appending _m to local variables. ie vabiable_m. If you need to be specific just use this->variable.

For you JavaScript devlopers, If you want to really annoy fellow devs, try unicode!

var ♼ = 12; var ㊹ = 44.0; var π = 3.0;

http://mathiasbynens.be/notes/javascript-identifiers

First, use whatever popular formatting is used in whatever language you are in (i.e. in PHP - UPPERCASE for constants, camelCase for functions, etc.) Benefit is your code is just compatible with most of the other code out there.

then for me - be as descriptive and terse as possible in naming:

  function validateScheduleArray($schedulearray) {...

For database fields I include the referencing table in the fieldname, (foreign keys may have the other table's name):

i.e. contact table:

  contact_id
  customer_id
  contact_type
  contact_description
  contact_info

or for more specific if you have similar tables in a large database:

  videocontact_id
  videocustomer_id
  videocontact_type
  videocontact_description
  videocontact_info

with that you always have an idea where something originated from.

Also I tend to go with singular terms for names in tables and fields. (contact instead of contacts) for fields with multiple values I use something like: contact_statlist

The more your source reads like psuedocode the easier it is to understand and maintain.