This commit is contained in:
Mau Di Bert 2019-01-10 11:03:51 -03:00 committed by GitHub
parent 9e593ccb1f
commit cfd46fd2d8
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -302,7 +302,7 @@ Some good-to-follow rules are:
- Use human-readable names like `userName` or `shoppingCart`. - Use human-readable names like `userName` or `shoppingCart`.
- Stay away from abbreviations or short names like `a`, `b`, `c`, unless you really know what you're doing. - Stay away from abbreviations or short names like `a`, `b`, `c`, unless you really know what you're doing.
- Make names maximally descriptive and concise. Examples of bad names are `data` and `value`. Such names say nothing. It'ss only okay to use them if the context of the code makes it exceptionally obvious which data or value the variable is referencing. - Make names maximally descriptive and concise. Examples of bad names are `data` and `value`. Such names say nothing. It's only okay to use them if the context of the code makes it exceptionally obvious which data or value the variable is referencing.
- Agree on terms within your team and in your own mind. If a site visitor is called a "user" then we should name related variables `currentUser` or `newUser` instead of `currentVisitor` or `newManInTown`. - Agree on terms within your team and in your own mind. If a site visitor is called a "user" then we should name related variables `currentUser` or `newUser` instead of `currentVisitor` or `newManInTown`.
Sounds simple? Indeed it is, but creating descriptive and concise variable names in practice is not. Go for it. Sounds simple? Indeed it is, but creating descriptive and concise variable names in practice is not. Go for it.