Changes between Version 20 and Version 21 of HowtoGoodProgrammingTechniques

Timestamp:

Apr 22, 2014, 8:28:31 AM (11 years ago)

Author:

Thanatermesis

Comment:

--

HowtoGoodProgrammingTechniques

@@ -50 +50 @@
 * Whitespaces improves readability a lot, use them, if you combine them with foldings in your editor you will not suffer the side-effect of removing contents visually
 
+=== Think less ===
+If you think less, you can read faster, for example:
+* Don't say ''equal or less than 2'' if you want to say ''less than 3''
+* Never use negatives, they are harder to think than afirmatives, for example:
+  * ''if not accept'' becomes ''if ignore''
+  * ''if is not disabled'' becomes ''if enabled'' (stupid but very common)
+  * 
+* write shorter and clever sentences
+
 
 == Convention Names ==
@@ -91 +100 @@
 1. Convention names, take some time to decide the optimal names for your variables and functions
 
+
+== Wisdom ==
+1. The secret to building large apps is never build large apps. Break your applications into small pieces. Then, assemble those testable, bite-sized pieces into your big application.
+1. Reducing the amount of code in your product should be a goal.
+1. If you are changing more than 25% of a class or method, consider simply rewriting it. You will write the code more cleanly.
+1. Accept that you have no idea how this will grow. The key is to acknowledge from the start that you have no idea how this will grow. When you accept that you don't know everything, you begin to design the system defensively... You should spend most of your time thinking about interfaces rather than implementations.
+1. Write all your functions to be able to work independently without requiring extra data like global variables, this let's you to test them independently, or even re-use them elsewhere. ''Thanatermesis''
+
+==== Common Excuses For A Software Rewrite ====
+* The Code Sucks
+* "We're So Much Smarter Now"
+* We Picked The Wrong Platform/Language
+
+==== Why Rewriting Is (Almost) Never A Good Idea ====
+* It Always Takes Longer Than You Expect
+* Markets Change
+* Existing Customers Become Frustrated
+* Refactoring Can Cleanup The Code
+* You Don't Control The Rewrite, It Controls You
+
+
+=== The Zen of Python ===
+* Beautiful is better than ugly.
+* Explicit is better than implicit.
+* Simple is better than complex.
+* Complex is better than complicated.
+* Flat is better than nested.
+* Sparse is better than dense.
+* Readability counts.
+* Special cases aren't special enough to break the rules.
+* Although practicality beats purity.
+* Errors should never pass silently.
+* Unless explicitly silenced.
+* In the face of ambiguity, refuse the temptation to guess.
+* There should be one-- and preferably only one --obvious way to do it.
+* Although that way may not be obvious at first unless you're Dutch.
+* Now is better than never.
+* Although never is often better than *right* now.
+* If the implementation is hard to explain, it's a bad idea.
+* If the implementation is easy to explain, it may be a good idea.
+* Namespaces are one honking great idea -- let's do more of those!
+
+=== Art of Unix programming ===
+* Rule of Modularity: Write simple parts connected by clean interfaces.
+* Rule of Clarity: Clarity is better than cleverness.
+* Rule of Composition: Design programs to be connected to other programs.
+* Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
+* Rule of Simplicity: Design for simplicity; add complexity only where you must.
+* Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
+* Rule of Transparency: Design for visibility to make inspection and debugging easier.
+* Rule of Robustness: Robustness is the child of transparency and simplicity.
+* Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
+* Rule of Least Surprise: In interface design, always do the least surprising thing.
+* Rule of Silence: When a program has nothing surprising to say, it should say nothing.
+* Rule of Repair: When you must fail, fail noisily and as soon as possible.
+* Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
+* Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
+* Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
+* Rule of Diversity: Distrust all claims for “one true way”.
+* Rule of Extensibility: Design for the future, because it will be here sooner than you think.
+
+
+
+
 == Extra ==