^^Design patterns. Software patterns.

 

Pattern, Pattern Language
a way to describe best practices and designs.
a named description of a recurring solution to a problem in a given context.

Patterns

  1. c2/PatternsForBeginners
  2. c2/ElementaryPatterns
  3. c2/PortlandPatternRepository
  4. cs.uni/~wallingf/patterns

Presentation/content separation

The principle of separating presentation and content is admirable.

It really does have advantages, but it’s easier said than done.

ref: johndcook

Regole pratiche. Clear code

  1. every line of a function should be at the same level of abstraction, 1 under the name
  2. use explanatory variables: they say what its contents is
  3. construct well written prose from the name of variables and functions
  4. functions should not be 100 lines long, hardly ever be 20 lines long, smaller the a screenful
  5. a function should do 1 thing; a function does 1 thing if it's not possible to extract another function from it
  6. indenting:  1 or 2, makes functions easier to read and understand
  7. if  employee_old: fire_employee
  8. max 3 arguments; in case pass an obj. Quasi mai booleans.
    Brutale:  my_fun(a, b, True)   what does in mean "True" ?
    Separate the calculated case before in 2 functions.
  9. don't output arguments: arguments that are passed into a function for the purpose of collecting the output !? nobody understands that right; you're reading along ... double take (american slang)
  10. avoid switch statements. Es: programma di disegno di forme:
  11. no side effects. es: open close, allocare rilasciare, sono funzioni che vengono a coppie, col loro ordine di esecuzione, ma poi ci si dimentica di eseguire la seconda.
  12. command and query separation. A function that returns void must have side effects, altrimenti non avrebbe senso chiamarla.
    Come stile di programmazione: una funzione che ritorna un valore non deve avere side-effect; in questo modo si riesce facilmente a tenere traccia dello stato del sistema.
  13. prefer exceptions to returning error codes.
    try block deve essere il solo contenuto di una funzione.
  14. DRY Don't Repeat Yourself
  15. test: si rinuncia a provare la correttezza, che e' un processo matematico, ma si fanno dei test che mostrano i casi in cui passa.
  16. commenti. Da usare se il codice non puo' essere autoesplicativo. Usare nomi di variabile e funzioni per un codice esplicativo, piuttosto che i commenti.
  17. variables: long scopes need long names.
    functions: more specific  -  long names
  18. wp/Comparison_of_integrated_development_environments

ref: Clean Code Uncle Bob

Raymond Hettinger

yt/Transforming Code into Beautiful, Idiomatic Python

yt/Object Oriented Programming from scratch (four times)

 

yt/The Mental Game of Python

  1. chunking and aliasing  Chunking_(psychology)
  2. solving a related but simple problem, and to do an incremental development
    1. Feynmann
      1. write down a clear problem specification
      2. think very very hard
      3. write down the solution
  3. build classes indipendently and let inheritance discover

    "walkin through the fog, and each step in the fog you can see further"

  4. Consider OOP as a graph traversal problem

Software development topics I've changed my mind on after 6 years in the industry >>>

  1. TDD wp/Test-driven_development

    TDD purists are just the worst. Their frail little minds can't process the existence of different workflows.

  2. YAGNI, SOLID, DRY. In that order.
  3. wp/You_aren't_gonna_need_it
  4. wp/Don't_repeat_yourself

 

SOLID wp

Single-responsibility principle
A class should only have a single responsibility, that is, only changes to one part of the software's specification should be able to affect the specification of the class.
Open–closed principle
"Software entities ... should be open for extension, but closed for modification."
Liskov substitution principle
"Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program." See also design by contract.
Interface segregation principle
"Many client-specific interfaces are better than one general-purpose interface."
Dependency inversion principle
One should "depend upon abstractions, [not] concretions."

Links wp

  1. Kent_Beck (born 1961) is an American software engineer and the creator of extreme programming, a software development methodology that eschews rigid formal specification for a collaborative and iterative design process.

Links librosito

c2.com  e' anche un deposito di "Design patterns. Software patterns".

Links inet

  1. hillside/patterns about all aspects of software patterns and pattern languages
  2. The Elementary Patterns Home Page
  3. Collection pipeline  martinfowler
  4. michaelfeathers/collection-pipelines-the-revenge-of-c

 

english

wreak havoc   scompigliare

wreak havoc on anyone who was trying to actually use it for anything

You can also try the bleeding edge unstable version.

 

 

 

Talk

Titolo

  1. Design patterns.
    c: ori.
  2. Design patterns. Software patterns.
    c: 17-8-2020.

Tags

sw