1. Use correct grammer (Classes, variables, packages are nouns. Methods and functions are verbs) 2. Avoid abbreviation & acronyms 3. Invest time in picking names (will pay off in the future) 4. Follow a coding style (eg. Google style guide) 5. Don't re-use variables to optimize (compilers are smart enough to do that on its own) 6. Avoid tongue-twisters (like HWNDsck, mCustRpt_ptr etc) 7. Avoid "not" prefix (for example you won't know what *!notDeletable* means at a glance) 8. Never use Hungarian Notation (like szFirstName). The name should suggest the type: isRed, hasChildren = boolean totalAmount, userCount = int firstName, simpleLabel = string startDate, signedOn = date firstNames = string[], List 9. Avoid prefixes if possible 10. Length: 1 is fine for iterators. For others 64 characters 11. If a function needs more longer name, then the function is most likely too big 12. Keep things explicit but short 13. If there is a shorter name for explaining what the function does then rename it 14. Include side-effects in function names 15. Split your code by single concerns 16. Avoid weasel-words (like helpers, handlers, managers etc). Alternatives: Decorator, Producer, Consumer, Selector, Grouper, Collecter, Persister, Loader, Streamer, Orchestrater, Store 17. Look for ambiguity
There were some choose-between-names cases that I've tried to solve and stay consistent at. I ended up with my standard approach to those: & vs And - prefer "and", leave "&" for brand names and programming actions. Add vs Create - prefer "add". It's more intuitive for non-programmers. Attribute vs Property - attribute for xml, properties for objects. Change vs Modify vs Update - prefer "update". It's more standard. Common vs Partials vs Shared - common for library names, shared for directory name, don't use partials. Configuration vs Options vs Preferences vs Settings Configuration - for internal system (for example: webpack.config.js, ecosystem.config.js). Options - for others choices (especially other developers, for example: ). Settings - for system-administrating end-user (for example: admin dashboard) Preferences - for end-user (for example: website visitor). Controller vs Resolver vs Route - controller for REST, resolver for GraphQL, route for analysis of url, query and params, possibly pointing to one of previously listed. createdAt vs creationDate - prefer "createdAt" over "creationDate". It's shorter and more common. Delete vs Remove - prefer "remove". It's more intuitive for non-programmers. Entity vs Model - for ORM model names use model, as it's more common and part of MVC naming. Module vs Package - module for internal stuff, package for external libraries. Page vs View - use view, as sometimes one page/view may be part of another one (also it's part of MVC).
1. Use correct grammer (Classes, variables, packages are nouns. Methods and functions are verbs)
2. Avoid abbreviation & acronyms
3. Invest time in picking names (will pay off in the future)
4. Follow a coding style (eg. Google style guide)
5. Don't re-use variables to optimize (compilers are smart enough to do that on its own)
6. Avoid tongue-twisters (like HWNDsck, mCustRpt_ptr etc)
7. Avoid "not" prefix (for example you won't know what *!notDeletable* means at a glance)
8. Never use Hungarian Notation (like szFirstName). The name should suggest the type:
isRed, hasChildren = boolean
totalAmount, userCount = int
firstName, simpleLabel = string
startDate, signedOn = date
firstNames = string[], List
9. Avoid prefixes if possible
10. Length: 1 is fine for iterators. For others 64 characters
11. If a function needs more longer name, then the function is most likely too big
12. Keep things explicit but short
13. If there is a shorter name for explaining what the function does then rename it
14. Include side-effects in function names
15. Split your code by single concerns
16. Avoid weasel-words (like helpers, handlers, managers etc). Alternatives: Decorator, Producer, Consumer, Selector, Grouper, Collecter, Persister, Loader, Streamer, Orchestrater, Store
17. Look for ambiguity
Classes are only singular*
16 is the path to doom
That’s not OOP
That’s CLASS Oriented programming
See Yegor Bugayenko
Most devs have not seen true Alan Kay style OOP
No
There are only 2 problems in programming:
1. Cache invalidation
2. Naming things
3. Off by one errors
Thank for your sharing your knowledge.
Great video. The point about prefixes is really important.
Great comprehensive video. Definitely going to send this to my team!
There were some choose-between-names cases that I've tried to solve and stay consistent at. I ended up with my standard approach to those:
& vs And - prefer "and", leave "&" for brand names and programming actions.
Add vs Create - prefer "add". It's more intuitive for non-programmers.
Attribute vs Property - attribute for xml, properties for objects.
Change vs Modify vs Update - prefer "update". It's more standard.
Common vs Partials vs Shared - common for library names, shared for directory name, don't use partials.
Configuration vs Options vs Preferences vs Settings
Configuration - for internal system (for example: webpack.config.js, ecosystem.config.js).
Options - for others choices (especially other developers, for example: ).
Settings - for system-administrating end-user (for example: admin dashboard)
Preferences - for end-user (for example: website visitor).
Controller vs Resolver vs Route - controller for REST, resolver for GraphQL, route for analysis of url, query and params, possibly pointing to one of previously listed.
createdAt vs creationDate - prefer "createdAt" over "creationDate". It's shorter and more common.
Delete vs Remove - prefer "remove". It's more intuitive for non-programmers.
Entity vs Model - for ORM model names use model, as it's more common and part of MVC naming.
Module vs Package - module for internal stuff, package for external libraries.
Page vs View - use view, as sometimes one page/view may be part of another one (also it's part of MVC).
Thanks for sharing! In my dictionary Model is after going through ORM, Entity is on the DB side, before going though mapper.
Super solid info. Background music is relaxing but it might be too relaxing; it made me a bit sleepy.
Excelent, worth my time, Thanks man!!!
Bro keep it up the good work! Appreciateed!
Thank you for sharing your knowledge, I like them.
Great video :) I'm a software developer myself and I found it very interesting :) although the music did make me a bit sleepy . :)
Vehicle wymawia się bardziej w stylu "wiekl".
a nie bardziej "weikl"?
Pretty good video but why are you talking down to your audience? It's quite annoying
But... but... I like hungarian notation :(
Everyone does! That's why you shouldn't use it ;)
@@SmokCode You know nothing, Jon Snow. I think you say such things because you don't want us to be pro programmers! :p