Does anyone have any good advice on variable naming? Here’s some of my rules I try to live by:
camelCase
use prefixes
prefixes should be one word followed by an underscore.
10 character limit or 3 word limit, not counting the prefix
functions should be prefixed with the file in which they’re defined, ie utils_FooBar
file names should be one word
Start Bools with is
Don’t use not in bool names.
This has farther-reaching implications that will keep you from making confusing code most of the time (I’m sure this will be controversial, but it works no matter what they say)
start output with _
Globals should be g_VARIABLENAME
use the least amount of words possible
but being too verbose can draw attention - use this to aide in readability
calc_ImportantValueThatWillDecideTheUsersView is better than calc_SumYears if the variable is more important than the others.
Even the greatest variable names are not replacements for documentation
Even the most readable code is not replacement for documentation.
Force yourself to love documentation.
Edit: I realize I was speaking about function-naming with the prefix stuff.
For variables, I still use prefixes, but for variable type. Even if you define the variables as types, it’s still incredibly useful. For instance,
a string is s_MyName,
enumerable is e_MyType,
A number is int or double or whatever i_MyAge or d_MyWeight
This might be obvious for custom objects, but I’d still do it like this p_Person or per_Person.
Don’t code in a language/style that requires you to write code that makes prefixing necessary - divide and conquer instead
Readable code and well written unit/BDD tests is much better than separate documentation that will go out of sync the minute another Dev does some surgical incision into the code
Be verbose if you need to in order to convey the relevant semantics, the characters are virtually free
Use the casing that is mainstream/recommended by its’ developers for the language at hand
I have to disagree on some points, but I def feel like you’re helping me learn, so for that I am grateful.
I feel like you’re speaking from the perspective of a perfect coding environment, which if you have that, that’s great. Maybe all your code is in one place, maybe you have an IDE that does a lot of the work for you, and that’s great. However, for most of us, that’s rarely the case.
Prefixes have been an absolute game changer for me personally, and I will never not use them again.
I have also found that verbosity of variable name and readability are mutually exclusive. A long variable name, most of the time, takes away from the logic. Yes, they are “free” as far as memory, but are very expensive to reliability.
Units tests, again are great, but most places think unit tests are like golden toilets. It sucks, but that’s the way it is. Usually you’re given a task, and if it’s not done next week, maybe you’re not as good as they thought.
These are things I have picked up from 18 years in the industry.
Let me comment some of it then …
camelCase
use prefixes
prefixes should be one word followed by an underscore.
Highly depends on your environment, your naming convention, etc.
functions should be prefixed with the file in which they’re defined
In modern day programming the file names are pretty much irrelevant. All somewhat recent programming languages have modules and namespaces. I don’t care in what file fooBar was defined. ALso: what happens if you refactor stuff and rename the file? Do you want to go through everything where the function is mentioned? (This can be automated, though, but still.)
Start Bools with is
Or with whatever is the naming convention you or your team follows. I do embedded scripting and one of the projects explicitly wants can_verb_thing when it comes to user permissions (can_change_foobar, can_run_baz, etc.). It is a good advice but heavily depends on your environment.
start output with _
Paraphrasing the naming convention I mostly work with: Start everything with _ that will be exported to global namespace. Also use the name of your module. Instead of foobar use _mymodule_foobar.
Globals should be g_VARIABLENAME
Globals should be properly namespaced to global context. constants are uppercase.
calc_ImportantValueThatWillDecideTheUsersView is better than calc_SumYears
And summarizeYears is even better. Do not use abbreviations and describe what the function does. If it summarizes the years there is no need to name it something else. Document your code (in-code documentation as well as user-facing documentation if applicable).
I appreciate your emacs perspective, thanks for the input.
I get the sense that programmerhumor hates prefixes, but I’m telling you, they have changed my life. Next project-for-fun, just give it a try and see what happens. I think you’ll be surprised.
To many of your points, I say I agree that a lot of naming conventions depend on context. The environment you’re working in, the IDE, the team you’re working on, the language you’re coding in.
However, prefixes I’m firm on. I think it’s unpopular because it’s from a bygone era where IDEs were non-existent. And while yes, ides have replaced many of the uses, they have been the most radical change to my readability and comprehension of the code I’ve written.
Also, I’m mostly a js programmer, so yes, very different from emacs.
Also, for calc_SumYears, I literally meant to add the years together, hense the prefix. So, maybe the prefixes are a little more useful than you give them credit.
I might be already exposing myself as an emacs user, but I think Lisp naming convention is pretty reasonable. I use it in other languages as far as their language rules allow me
if a variable or function is a predicate (as in if it tests if something is true or not), append p or _p/-p
variables and functions both have lisp case variable-name-here. Sub for _ in languages that dont allow - in names
unused or unexposed variables are prefixed _ .
top level packages get naming rights. So if I’m making cool-package then variables or functions that are specific to it are cool-package-variable (especially if it is exposed to other packages). cool-package/variable is also good if allowed.
otherwise, separate namespaces with /. So there’s main-function and my/main-function. If / is reserved, then I assume the language has a way of segmenting namespaces already and just default to that since _ or - would get ambiguous here.
Does anyone have any good advice on variable naming? Here’s some of my rules I try to live by:
utils_FooBarisnotin bool names._g_VARIABLENAMEcalc_ImportantValueThatWillDecideTheUsersViewis better thancalc_SumYearsif the variable is more important than the others.Edit: I realize I was speaking about function-naming with the prefix stuff.
For variables, I still use prefixes, but for variable type. Even if you define the variables as types, it’s still incredibly useful. For instance,
a string is
s_MyName,enumerable is
e_MyType,A number is int or double or whatever
i_MyAgeord_MyWeightThis might be obvious for custom objects, but I’d still do it like this
p_Personorper_Person.Seriously it does make a huge difference
I have to disagree on some points, but I def feel like you’re helping me learn, so for that I am grateful.
I feel like you’re speaking from the perspective of a perfect coding environment, which if you have that, that’s great. Maybe all your code is in one place, maybe you have an IDE that does a lot of the work for you, and that’s great. However, for most of us, that’s rarely the case.
Prefixes have been an absolute game changer for me personally, and I will never not use them again.
I have also found that verbosity of variable name and readability are mutually exclusive. A long variable name, most of the time, takes away from the logic. Yes, they are “free” as far as memory, but are very expensive to reliability.
Units tests, again are great, but most places think unit tests are like golden toilets. It sucks, but that’s the way it is. Usually you’re given a task, and if it’s not done next week, maybe you’re not as good as they thought.
Not sure if you’re trolling or serious.
Sorry, I’m serious. These are things I have picked up from 18 years in the industry.
Let me comment some of it then …
Highly depends on your environment, your naming convention, etc.
In modern day programming the file names are pretty much irrelevant. All somewhat recent programming languages have modules and namespaces. I don’t care in what file
fooBarwas defined. ALso: what happens if you refactor stuff and rename the file? Do you want to go through everything where the function is mentioned? (This can be automated, though, but still.)Or with whatever is the naming convention you or your team follows. I do embedded scripting and one of the projects explicitly wants
can_verb_thingwhen it comes to user permissions (can_change_foobar,can_run_baz, etc.). It is a good advice but heavily depends on your environment.Paraphrasing the naming convention I mostly work with: Start everything with
_that will be exported to global namespace. Also use the name of your module. Instead offoobaruse_mymodule_foobar.Globals should be properly namespaced to global context. constants are uppercase.
And
summarizeYearsis even better. Do not use abbreviations and describe what the function does. If it summarizes the years there is no need to name it something else. Document your code (in-code documentation as well as user-facing documentation if applicable).I appreciate your emacs perspective, thanks for the input.
I get the sense that programmerhumor hates prefixes, but I’m telling you, they have changed my life. Next project-for-fun, just give it a try and see what happens. I think you’ll be surprised.
To many of your points, I say I agree that a lot of naming conventions depend on context. The environment you’re working in, the IDE, the team you’re working on, the language you’re coding in.
However, prefixes I’m firm on. I think it’s unpopular because it’s from a bygone era where IDEs were non-existent. And while yes, ides have replaced many of the uses, they have been the most radical change to my readability and comprehension of the code I’ve written.
Also, I’m mostly a js programmer, so yes, very different from emacs.
Also, for calc_SumYears, I literally meant to add the years together, hense the prefix. So, maybe the prefixes are a little more useful than you give them credit.
Camel case for local variables
Pascal case for global ones
The name should tell me it’s purpose
That’s it
Right?! People out here are writing a bible on how to name variables lmao
Yeah I bet they feel so good about having the perfect recipe for naming variables, a recipe only they know or care about
I might be already exposing myself as an emacs user, but I think Lisp naming convention is pretty reasonable. I use it in other languages as far as their language rules allow me
if a variable or function is a predicate (as in if it tests if something is true or not), append
por_p/-pvariables and functions both have lisp case
variable-name-here. Sub for_in languages that dont allow-in namesunused or unexposed variables are prefixed
_.top level packages get naming rights. So if I’m making
cool-packagethen variables or functions that are specific to it arecool-package-variable(especially if it is exposed to other packages).cool-package/variableis also good if allowed.otherwise, separate namespaces with
/. So there’smain-functionandmy/main-function. If/is reserved, then I assume the language has a way of segmenting namespaces already and just default to that since_or-would get ambiguous here.See the rest here: https://github.com/bbatsov/emacs-lisp-style-guide