1. Use verbs such as "is" or "can" as the prefix of Boolean variables
When declaring Boolean variables, add verbs such as "is" or "can" before the variable name to help readers quickly understand the type of value they are using. Let's look at some examples.
display vs isDisplaying
const display = false;
const isDisplaying = false; // better
Although you can interpret display as "yes" or "no", I think display can also contain equivalents such as "block", "in-line" and "none". For "isDisplaying", the range possibility may be limited to "true" or "false"
Toggle vs canToggle
const switch = false;
const canToggle = false; // better
Again, I think "can toggle" is more intuitive than "toggle". "Toggle" opens the door to more explanations, such as "off" or "on", or even functions that perform some additional logic. Using canToggle, it is obvious that it is either a Boolean value or a function that returns a Boolean value.
moreItems and areMoreItems
const moreItems = false;
const areMoreItems= false; // better
In this example, we prefix "are", which is only a form of "is" in the plural (many). In this case, "more items" can refer to a series of additional items, but are more items clearly represents whether there are more items.
2. Put the 'id' attribute first in the HTML element
If you use html, or JavaScript frameworks like React or Vue, you should know that the number of attributes on < input > or < div > will grow rapidly. When browsing large html files or forms, always place the id = "elementId" attribute in the It's really helpful in the first place so that readers quickly know what elements they're looking at
<span style="background-color:#f2f2f2"><span style="color:rgba(0, 0, 0, 0.8)"><span style="color:#292929"><form id="signUpForm">
// The right way
<input
id="email" // Clear at top
type="email"
onChange={(e) => setEmail(e.target.value)} // Reaction code
value={email}
tabIndex="1"
</input></span><span style="color:#292929 "> / / wrong way
<input
onChange={(e) => setPhone(e.target.value)} // React code
value={phone}
tabIndex="2"
id="phone" // ID is harder to find
type="Telephone"
</input>
</form></span></span></span>For the first input, we put the id attribute first, and for the second input, we hide it in some attributes. When scanning this code, I think readers will recognize the first input as an e-mail field faster than the second. In the second input, readers may have to scan the onChange method and try to explain from there, while in the first input It's hard to miss.
3. When interacting with DOM, always add 'handle' before the function
If you pass a callback function to a DOM element when using a framework / library like React, and you are receiving a This is a form of "event" object. I strongly recommend that you add "handle" before the function. You will often see this in the React document But I want to restate how helpful this Convention is in reading components.
<span style="background-color:#f2f2f2"><span style="color:rgba(0, 0, 0, 0.8)"><span style="color:#292929 "> / / not very good
function save(event){
event.preventDefault();
}</span><span style="color:#292929"><button onClick={save}></form></span><span style="color:#292929">VS</span><span style="color:#292929 "> / / OK
function handleSave(event){
event.preventDefault();
}</span><span style="color:#292929"><button onClick={handleSave}></form></span></span></span>If you introduce other methods from external sources that execute business logic or call API services, such as "save", it is really helpful to distinguish between functions that interact with DOM elements and functions that do not interact with DOM elements, and use the prefix "handle" to make this simple and effective.
4. Use CQRS mode to distinguish query from command
If you are not familiar with CQRS mode, I suggest you read Martin Fowler's This wonderful article . my brief overview Yes, there are two types of operations, query (get information) and command (take action on something). If you know CRUD, check The query is "R" and the command is "CUD" (and everything else).
Since most applications have a balance of queries and commands, building applications to distinguish between the two can make your code easier to read and easier to maintain. For example, if your application calls an api, I will create a backendConfig file in my React application and build it like this.
<span style="background-color:#f2f2f2"><span style="color:rgba(0, 0, 0, 0.8)"><span style="color:#292929">// Backendconfig. JS / / < / span > < span style = "color: #2929" > export queryEndpoints ={
getAllCustomers: '/api/get-all-customers'
getCustomer: '/api/get-customer/'
}</span><span style="color:#292929">export commandEndpoints = {
createCustomer: '/api/create-customer',
updateCustomer: '/api/update-customer'
}</span>
<span style="color:#292929">// Customer service. JS / / < / span > < span style = "color: #292929" > Import {queryendpoints, commandendpoints} < / span > < span style = "color: #292929" > / / create customer method from '. / backendConfig.js'
...
axios.post(commandEndpoints.createCustomer, customer);
...</span><span style="color:#292929 "> / / get customer method
...
const customer = await axios.get(queryEndpoints.getCustomer + customerId);
...</span></span></span>This example omits a lot of surrounding logic, but I hope you understand the intention and grasp the benefits of dividing endpoints into queries and commands. If you have a larger API, this may be very useful, and it should save you time when adding new endpoints or finding existing endpoints.
5. Conditional statements always use braces
Some of you may disagree with me, but I always use parentheses when writing conditional statements. If you come from python, you may like to use only indentation, but I found that curly braces provide a lot of white space, which can not only read the code, but also Quickly acknowledge that you need to consider a condition. In addition, you will encounter situations where curly braces must be used for multiline conditions, so it's best Be consistent and use them anywhere. I know you might want to use fewer lines of code, but I think it's not small for someone The important condition of excessive heartbeat is not worth it.
<span style="background-color:#f2f2f2"><span style="color:rgba(0, 0, 0, 0.8)"><span style="color:#292929 "> / / OK
if(isValid){
save();
}</span><span style="color:#292929">contrast</span><span style="color:#292929 "> / / not very good - not very consistent
if(isValid) save();
or
if(isValid)
save();</span></span></span>I do use ternary operators, but I usually try to make them obvious by wrapping and indenting. I also use them only when assigning results to variables.
<span style="background-color:#f2f2f2"><span style="color:rgba(0, 0, 0, 0.8)"><span style="color:#292929">const errorMessage = !form.isValid ? "The form is invalid" :"";</span></span></span>
wrap up
You have it! Five simple tips for writing cleaner, easier to maintain code. If you agree or disagree with any of them Please leave a message in the comments below. If you like this article, please applaud and follow me as always.