ryanmcdermott
What about Magic strings?
Do you think that can be good to include something about magic strings?
Bad:
let posts = getPostsFromCategory('sports');
Good:
const categories = {
sports: 'sports',
economy: 'economy'
};
let posts = getPostsFromCategory(categories.sports);
Sounds good. The example you wrote isn't that good imo. In most cases categories will be dynamic, just like posts. Not changing is a characteristic of magic strings I believe. Maybe the example will be more clear when a enum with months is used and the function is called getPostsByMonths(months.jan) or something :)
Hey there Quique! It sort of feels like you're referring to an Enum. JavaScript of course doesn't have them! It also feels like you're referring to named constants as in the case of Searchable Names. https://github.com/ryanmcdermott/clean-code-javascript#use-searchable-names
It's sort of an extension of that too, where you're hiding the textual implementation details of the sports category key, and you're simply namespacing them under a constant categories object. All in all, it's an interesting idea to extend the subsection on Searchable Names to have namespaced constants. What does everyone else think?
I think that all of you are right, maybe not the best example xD Totally useful to use as Enums and some examples could be:
- Days of week (days.monday)
- Months of year (months.january)
- Event names (events.mouseover)
etc.
Keyboard keycodes are another example you see in the front-end JavaScript world, where you have something like:
const KEYCODES = {
ENTER: 13
};
document.addEventListener('keydown', function(event) {
if (event.which === KEYCODES.ENTER) {
//...
}
}
This is typically how I do things. I'll also go a step further and add enums statically to my classes for more organized namespacing (rather than just having randomly floating constant objects).
export default class Person { /* ... */ }
// Static Property:
Person.GENDERS = {
MALE: 'm',
FEMALE: 'f',
OTHER: 'na'
};
// Const + Static Property:
const GENDERS = { ... };
Person.GENDERS = GENDERS;
// New Syntax Static Property:
class Person {
static const GENDERS = { ... };
}
// Static Property Usage:
import Person from './Person';
let bob = new Person();
bob.setGender( Person.GENDERS.MALE );
// Or you can do a Named Export Variation:
import Person, { GENDERS } from './Person'; // or { GENDERS as PERSON_GENDERS }
let bob = new Person();
bob.setGender( GENDERS.MALE );
This allows me to keep the enums very close to their intended usage. And it's easier to expose since I don't have to go around creating some unrelated global / flat constants container object. person.gender can be one of Person.GENDERS in essence.
const KEYCODES = {
ENTER: 13
};
document.addEventListener('keydown', function(event) {
if (event.which === KEYCODES.ENTER) {
//...
}
}
When u wish actual enums existed xD
@jacktuck Just out of curiosity, what advantage do enums give over constants? I used to do C# and we had enums and I never really understood why they were that great.
@toddmantell Enums can not be changed. Objects can be, unless you freeze them. That's the only behavioural difference I can think of. Other than that, aesthetics, I guess.
@jacktuck Object.seal.
const enum = Object.seal;
const KEYCODES = enum({
ENTER: 13
});
KEYCODES.ENTER = 14;
KEYCODES.NEW_KEY = 15;
delete KEYCODES.ENTER;
KEYCODES // => { ENTER: 13 }
Clean code doesn't mean less code. It's about being more readable, manageable, and efficient.
