I am actually writing the analyser code to approve_with_comment if someone has not extracted it. There are two variants we see that are approvable but not optimal.
They already have it as a constant, but it's "re-created" each invocation. Extracting is might be a premature optimisation from a speed standpoint, but that's not it.
The variable name is shadowing the function name, which leads to subtle bugs.
Extracting the constant to the top-level allows for re-use (which is ok, not a necessity)
Extracting the constant is declaring intent: this is a "compile"-time value, that is actually constant in value, and not just assignment, which is further solidified with making it UPPERCASE
In the above case, extracting it is a small gain, but mostly for declaring intent.
There is nothing wrong with the solution above, but this is a magic number or rather magic expression. It's adding a number to date, but in a year's time, can you remember why it's 10 ** 12 and not 10 ** 9 (which would be giga)? Maintainability is easier if you name your constants.
What's your personal rule of them for this? (i.e. when to use all caps)
This is just a preference I inherited from other languages where this is enforced in the language (Ruby constants start with a Capital for example), but mostly I do this in JavaScript and TypeScript based on:
If the constant is constant per invocation, e.g. it is a computed constant that can change based on the state of the process or function (input is a state), then I use const camelCase.
If the constant is constant per process, e.g. it is the same value when "compiled" or when "first interpreted", it is probably a file-level (and thus process-level) constant. I use const UPPER_CASE
The added benefit of the approach above is:
It's instantly clear which VALUE is always the same and which functionValue depend on state.
Most code highlighters (such as prism, or the tsc in vscode etc.) will color the UPPER_CASE differently.
Focused on getting people excited to learn and helping developers learn quickly.
Created: https://vimforvscode.com
@freeCodeCamp alum
Instructor @eggheadio
They already have it as a constant, but it's "re-created" each invocation.
Great point! Didn't even think about that when I first wrote my solution.
Also, thanks for the detailed explanation and sharing your thoughts on when to use uppercase for your consts. Seems like a solid rule I may adopt into my own practice!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great questions!
I am actually writing the analyser code to
approve_with_comment
if someone has not extracted it. There are two variants we see that are approvable but not optimal.They already have it as a constant, but it's "re-created" each invocation. Extracting is might be a premature optimisation from a speed standpoint, but that's not it.
The variable name is shadowing the function name, which leads to subtle bugs.
Extracting the constant to the top-level allows for re-use (which is ok, not a necessity)
Extracting the constant is declaring intent: this is a "compile"-time value, that is actually constant in value, and not just assignment, which is further solidified with making it UPPERCASE
In the above case, extracting it is a small gain, but mostly for declaring intent.
There is nothing wrong with the solution above, but this is a magic number or rather magic expression. It's adding a number to date, but in a year's time, can you remember why it's
10 ** 12
and not10 ** 9
(which would be giga)? Maintainability is easier if you name your constants.This is just a preference I inherited from other languages where this is enforced in the language (Ruby constants start with a Capital for example), but mostly I do this in JavaScript and TypeScript based on:
constant
is constant per invocation, e.g. it is a computed constant that can change based on the state of the process or function (input is a state), then I useconst camelCase
.constant
is constant per process, e.g. it is the same value when "compiled" or when "first interpreted", it is probably a file-level (and thus process-level) constant. I useconst UPPER_CASE
The added benefit of the approach above is:
VALUE
is always the same and whichfunctionValue
depend on state.tsc
in vscode etc.) will color theUPPER_CASE
differently.I hope these make sense!
Great point! Didn't even think about that when I first wrote my solution.
Also, thanks for the detailed explanation and sharing your thoughts on when to use uppercase for your
const
s. Seems like a solid rule I may adopt into my own practice!