Software Development Principles
Outline of common, popular Software Development Principles
1. D.R.Y.
1.1. Don't
1.1.1. Don't
1.2. Repeat
1.2.1. Repeat
1.3. Yourself
1.3.1. Yourself
2. Object-Oriented Programming Principles
2.1. Abstraction
2.2. Inheritance
2.3. Polymorphism
2.4. Encapsulation
3. S.O.L.I.D.
3.1. SRP
3.1.1. Single Responsibility Principle
3.2. OCP
3.2.1. Open-Closed Principle
3.3. LSP
3.3.1. Liskov Substitution Principle
3.4. ISP
3.4.1. Interface Segregation Principle
3.5. DIP
3.5.1. Dependency Inversion Principle
4. Y.A.G.N.I
4.1. You
4.2. Ain't
4.3. Gonna
4.4. Need
4.5. It
5. Defensive Programming
6. Offensive Prorgramming
7. Separation of Concerns
8. Information Hiding
9. Law of Demeter
10. Ninety-nine Rule
11. CodingHorror's Less Serious Additions to the Lexicon NOT REALLY PRINCIPLES
11.1. Smurf Naming Convention
11.1.1. When everything is prefixed with the same word
11.1.1.1. SmurfController
11.1.1.2. SmurfAccountPage
11.2. Rubber Ducking
11.2.1. Talking a problem out to someone or something but not actually getting any response yet still either illuminating or totally solving it
11.3. Ninja Comments
11.3.1. Zero comments
11.3.2. AKA "Secret comments"
11.3.3. AKA "Hidden comments"
11.4. Lochness Monster Bug
11.4.1. Not reproducible
11.4.2. Seen by one person
11.5. Atwood's Duck
11.5.1. A purposefully 'lame' feature added to the product that you demo to a client.
11.5.2. Meant to allow for them to remove it and thus feel like they are contributing.
11.5.3. Lessens the possibility that they'll argue other more important items.
11.6. Fear-Driven Development
11.6.1. When project management adds more pressure
11.7. Baklava Code
11.7.1. if(thing1){ if(thing2){ if(thing3){ if(thing4){ // keeps going } } } }
11.7.2. Baklava code is an IT term for code that is too complex, specifically, a code base that has too many layers of abstraction or architectural layers.
11.7.2.1. Code with too many layers
11.8. Jimmy
11.8.1. Shitty new developer
11.9. Doctype Decoration
11.9.1. "When web designers add a doctype declaration but don't bother to write valid markup."
11.10. Yoda Conditions
11.10.1. if(5 == five)
12. Inversion of Control
13. K.I.S.S.
13.1. Keep
13.2. It
13.3. Simple
13.4. Stupid
13.5. Great advice. Hurts my feelings every time.
13.6. Enterprise Quality FizzBuzz
14. Why Should I Care What Color the Bikeshed Is?
14.1. AKA
14.1.1. Law of Triviality
14.1.2. Parkinson's Law of Triviality
14.1.2.1. Not to be confused with Parkinson's Law
14.1.2.1.1. Parkinson's Law vs. Parkinson's Law of Triviality
14.1.2.1.2. Or, Law of Triviality vs. Parkinson's Law
14.1.3. bicycle-shed effect
14.1.4. bike-shed effect
14.1.5. bike-shedding
14.2. People give disproportionate weight to trivial issues.
14.3. Design discussions are usually incorrectly focused on syntax rather than semantics
14.3.1. Difference between syntax and semantics in programming
14.3.1.1. Semantics
14.3.1.1.1. Whether it has meaning (or at least a logical meaning and is represented in code as such)
14.3.1.2. Syntax
14.3.1.2.1. Whether it's correct or valid for the grammar of the language
15. Parkinson's Law
15.1. "Work expands so as to fill the time available for its completion"
15.2. NOT TRIVIAL
15.2.1. 'Triviality' is not involved in this definition at all. Easy to distinguish if you separate them out via this word.