Skip to content

Instantly share code, notes, and snippets.

@kashifrazzaqui
Created July 21, 2015 13:38
Show Gist options
  • Save kashifrazzaqui/4f0421f3edfbff55c51a to your computer and use it in GitHub Desktop.
Save kashifrazzaqui/4f0421f3edfbff55c51a to your computer and use it in GitHub Desktop.
code design guidelines
- when designing libraries its better to leave threads out but not always
- realize that your users may have varying threading strategies and your lib should not prescribe or assert one lest it resists reuse
- typical novice problems
- http://joostdevblog.blogspot.in/2015/01/what-most-young-programmers-need-to.html
- liar variables, methods, classes
- muddy classes
- oversized classes
- code in comments
- parallel logic and duplication
- reduce the number of explicit if conditions in the codebase
- DRY in data, code and ideas
- reduce dependence on caches
- reduce what you persist
- reduce reliance on threading
- modularization is serious business
- understand what should go into what module
- understand what is the app and what is the library
- one function should only be at one layer of abstraction and do only one thing at that layer of abstraction
- io is the outermost layer and business code is the inner most - clean architecture
- primitive objects at the edges and composite objects as you go up
- stateless at the edges and stateful as you go up
- all io should have async apis
- threads should typically only be used for io
- don't design for the future the future is never here
- do less not more
- you should be able to count lines of code required for any feature with resaonable accuracy
- if you feel something is too complicated it probably is - simplify it
- don't invent artificial design rules
- example - too many simple classes is a bad thing - it isn't
- separate presentation from model, same code should run on a different platform/UI
- methods with booleans in parameters should be decomposed into two separate methods each
- methods with more than one boolean is smelly
- booleans are crude
- minimize Singletons
- decide what to promote to OOP and what stays procedural, almost everything should promote
- methods should prefer data parameters rather than objects
- unless they need the object to execute some process
- Encapsulate all mutable fields belonging to one invariant into a separate class
- coupling means sharing
- internal state/data structures
- db schemas
- internal representational objects
- any api that can be added without adding new state is a good idea
- make sure your tests only test code you have written
- don't test IO, or libs/framework written by other parties, in order to achieve this you will be forced to pull business logic out into a testable unit
- how to identify modules in existing code
- algorithm
"for class in classes:
if class belongs to only one existing module:
module.add(class)
elif class belongs to more than one module:
split class and then add to respective modules
else:
create new module and add class to it"
- power law
- premature optimization is evil; why you should not optimize your domain model for performant queries when creating a new system
- typically such a tradeoff effects object and relational schemas and is usually about which object references/contains which other object
- premature optimization is unnecessary because required levels might still be achievable in the better domain model instead of making a premature compromise and you can't prove or assume this before hand
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment