[程序员英语口语][Clean code]Chapter1-6 Naming variables & properties -Example

Clean code

chapter1 naming

1.6 Naming variables & properties -Example

So now that we know how to name variables, constants and properties, Let’s see more examples and let’s see different variations of names.

For that we will consider what’s being stored. we’ll then have a look at the bad names,at okay-ish names and at good names.

And let’s start with the good old user object again. Let’s say we have a variable in which we store a user object.

And the same would be true if it’s a constant, or if it’s a property.

And let’s say that user object is simply the combination of the name of the user, the email address and the age.

Now what could be bad names here. Now bad names for this kind of variable would be something like u or data.

u is simply very short and unspecific. and data is also not very specific.

These variables could contains anything. It’s not clear that they hold some user object.

Names which are okay could be userData, instead of just data. or person.

The problem with userData is that it might have some redundant information attached to it.

I mean, if we have a user object, it’s clear that it contains data about that user. So we probably don’t want to name the variable userData.

And for person, that might be too unspecific. It can make sense, I will not say that it’s always wrong.

But often you might be working on a customer,or on an author, or an instructor, or an administrator.

So maybe you want to use these specific words instead.

If we would not be storing a user object here, but let’s say we would just be collecting data, a user entered in some form and we have a mixture of the entered values and of validation results of our validation these inputs, then we could have a user_data variable. which holds this bag of entered values and validation results.

There, something like that could make more sense, because it would not be the finished user object then

but some intermediate object between collection the values and creating the user.

So that’s something to consider. And I’m bringing this up here just to make it clear that a name which might be okay in one scenario might be a good name in another scenario and vice versa.

Just bad names are really often very bad. So therefore, good names could be user, or as I just said, something more specific like customer.

user is pretty descriptive and clear, and customer is even more specific, which often might be the better option to make it really clear which kind of user that is.

Of course, if you have an application where a user is really just a user and not necessarily a customer yet.

Then there is nothing wrong with going with just user. which is why it’s listed under good names here.

And with that, I got a first little exercise for you. Let’s say we’re now validate some user input.

and it’s the result of this validation which is being store in a variable or in a property. How would you name that?

Pause the video for a second and think about bad, okay, and good names.and then we’ll havea look at the examples I came up with.

So what could be some bad names for this?

Well again, just using a single charater is pretty much always bad with some rare exceptions.

So we could usev for the validation result, or something like val.

The problem with v is that it could be anything. The problem with val is that we could also think that is stands for value instead of validation result.

so these are too unspecific and don’t tell us anything.

When it comes to okay names, we could have something like correct or validationResult. The problem with these names is that they don’t imply that they hold true or false values.

correct could be hoding any kind of value, It could be true or false, but it could also be some text or anything else.

And validatedInput could hold the value which was validated instead of the validation result

So better options could be isCorrect or isValid, or something like did validate successfully

These would be names which are descriptive and where it’s clear that we have a true or false value stored in there.

Now there will be more examples throughout this course. But this hopefully gives you a first idea on how variables, properties and constants may be named.

1. redundant 冗余的

We should reduce the redundant code as much as possible.

2. intermediate 中间的

   Too many Intermediate objects could be annoying.

3. vice versa 反之亦然

   Good name doesn’t have be short and vice versa.

4. descriptive 描述性的

   Good name should always be descriptive.

5. imply 暗示，意味着

   The code doesn’t imply the intent of the user.

Tips：此系列的重点在于如何用英文表达一些逻辑，适合积累口语，大家可以仔细品读短文，找到自己喜欢的表达方式。

Source：【整洁代码 Clean Code-哔哩哔哩】 https://b23.tv/skgyGMC