Bayle Shanks's website: books-programmingLanguages-programmingLanguagesPartPractices

Table of Contents for Programming Languages: a survey

Part IV: Idioms, patterns, and best practices

visitor

strategy pattern

factory pattern

inversion of control

http://en.wikipedia.org/wiki/Inversion_of_control

http://en.wikipedia.org/wiki/Dependency_injection (a form of inversion of control)

http://en.wikipedia.org/wiki/Template:Design_Patterns_patterns

misc

two-way model binding

futureproofing patterns

(cross-reference extensibility)

http://journal.stuffwithstuff.com/2010/09/18/futureproofing-uniform-access-and-masquerades/

points out three kinds of futureproofing in java:

using getters and setters instead of fields
writing functions that require interfaces instead of classes
creating instances via factory methods rather than directly via constructors

these are all annoying boilerplate, but they are all good things to do because if you don't, and you want to make one of the following changes, then you must change every call site, instead of just one line. This is especially bad if your program is a shipped library and the call sites are in client code (e.g. you would have to make breaking/incompatible changes to your library):

perform processing upon reading or writing to what was previously just a field
swapping the class that is passed to a function for another class with the same signature
wrapping a class with another one with a superset of functionality while keeping the old, original version intact

now, Jasper already deals with the first two of these, and maybe the third. If not, We should probably deal with the third, too. That is to say, when you call a constructor (if we have constructors at all; i'm leaning towards yes), you don't actually determine an implementation but merely an interface, and perhaps a factory method to determine the implementation. In other words, 'everything is an interface', like we always say.

in http://journal.stuffwithstuff.com/2010/10/21/the-language-i-wish-go-was/, he also points out a few more that Go handles that Java doesn't:

in languages that do not allow an existing type to retroactively implement a new interface, you might have to overdesign interfaces upfront in case you need them later

in http://journal.stuffwithstuff.com/2010/10/21/the-language-i-wish-go-was/, he also points others kinds of futureproofing that aren't needed in Java but that may be needed in other languages, such as Go:

in languages without pervasive constructors, you should creating your object through an init object, even if all you have to do is malloc some memory for it; because later you might want to add some initialization. Again, if you don't do this, you'll have to change all call sites later.
in languages that cannot overload subscript (array-lookup) syntax (e.g. array[index]), you might want to wrap arrays inside objects in case you want to replace them with some other class, which is not allowed to use the special syntax, later

book rec: design patterns

C

"By default you should compile with optimization on. Forcing the compiler to work harder helps itﬁnd more potential problems." -- http://www.slideshare.net/olvemaudal/deep-c

C++

C++'s rule of three: https://en.wikipedia.org/wiki/Rule_of_three_%28C++_programming%29

prefer STL vectors rather than raw arrays -- http://www.slideshare.net/olvemaudal/deep-c

don't prefix variable names with _ b/c this may conflict with some "reserved naming conventions for C, Posix, and/or compilers" -- http://www.slideshare.net/olvemaudal/deep-c

"A nice rule of thumb is to always write the member initializers in the order they are deﬁned." -- http://www.slideshare.net/olvemaudal/deep-c

compile with -Wall and usually -Wextra-pedantic and -Weffc++ as well -- http://www.slideshare.net/olvemaudal/deep-c

write constructor initializers in the order they will be evaluated -- http://www.slideshare.net/olvemaudal/deep-c

don't make any functions virtual in a class unless you are designing the class to be inherited from -- http://www.slideshare.net/olvemaudal/deep-c

be careful to use delete[] when appropriate, e.g. when you used new[] to allocate

Chapter: Types of coding tasks

numeric linear algebra:

operator overloading is crucial

https://news.ycombinator.com/item?id=6284842

embedded:

memory footprint is crucial (often, GC isn't good enough, e.g. Objective-C)

hobby project:

little boilerplate; no need for team features

simulation: CPU-bound; speed; OOP; parallelism

Concurrency patterns

overuse of synchronization leads to throwing away a lot of concurrency. advanced algorithms such as lock-free algorithms accept/permit nondeterminacy as much as possible during their execution, but still give deterministic results at the end. but they are difficult to write/reason about.

if using basic locking, where to lock in data structures (e.g. to create critical sections): create a critical section out of any piece of code s.t. if you stopped in the middle, an invariant would be violated; or any piece of code s.t. if another thread updated shared memory in the middle, there would be a problem.

beware: returns, gotos, possible exceptions; anything that could interrupt you

beware: function calls that might call something else that would block on one of the locks you've acquired

POSIX, pthreads

design criteria for programs

http://www.w3.org/DesignIssues/Principles.html
http://www.catb.org/esr/writings/taoup/
loose coupling
incorporate my notes from [1]
incorporate my notes from [2]
incorporate my notes from [3]
'purity is the right default'
incorporate my notes from [4]

books-programmingLanguages-programmingLanguagesPartPractices