SNR relation to the code

Signal

"Signal is information which conveys knowledge via facts. Knowledge is derived from Facts. Fact is produced by Business Use Case in time"

What is your language support to make facts visible ?

Signal properties

Fact that happened incorporated in time

Fact is an Immutable Value

Decisions are made on facts (humans and machines)

What is Fact ? it is a value Fact = something that happend, that existed, incorporate time
Comparing facts from different time points all the time.
If mutable in a time a needs to be protected (OOP) (lock?)
Why this is important ? We can assert on Facts and not on mechanisms

Noise

"Everything which infers with a signal and not contribute to the Knowledge"

Noise properties

Irrelevant or false data

Fact mutation

Everything that hinders readability of Facts

This can be a code specifity, organization

Categories of code noises

Organization

Readability

Correctness

Expressiveness

Frameworks

Effort

Complexity

Organization : how the code is structured
Readability : how it is easy to read the code. Most of the time we are reading to understand the code, naming
Correctness : modeling with types, null reference exceptions, no side effects, try catc
Expressiveness : how much plumbing code, curly braces punctuations, powerfull type inference
Frameworks : how many frameworks for DI, AOP, ORMS
Effort : how difficult is to write code, maintain and refactor, know design patterns etc
Complexity : cyclic dependencies, LoC, Cyclomatic Complexity

Active patterns

Active patterns enable you to define named partitions that subdivide input data, so that you can use these names in a pattern matching expression just as you would for a discriminated union. You can use active patterns to decompose data in a customized manner for each partition.

It is normally fine for the data to be exposed without being encapsulated. The data is immutable, so it can't get "damaged" by a misbehaving function. And it turns out that the focus on transparent data allows for more code that is more flexible and generic.

Designing with types

"It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures" -- Alan Perlis

OO classes shouls have behaviour operating on private state. Just state is a bad design "Anemic domain". In F# data is separated from functions

Computation expressions in F# provide a convenient syntax for writing computations that can be sequenced and combined using control flow constructs and bindings. They can be used to provide a convenient syntax for monads

Immediate feedback

Observations

F# implementation noises

Lines of code: 397

Correctness: 5% (-20%)

Expressiveness: 10% (-24%)

Frameworks: 28% (-14%)

Complexity: N/A

Organization: Easy

Readability: Excellent

Effort: Low

CodeSNR = 23% (+16%)

Code organization

What's nice about this approach is that, if you are a newcomer to a code base, you always know where to start. The first few files will always be the "bottom layer" of an application and the last few files will always be the "top layer". No folders needed!

How we've improved the signal with F#

No need of frameworks for DI

No need of AOP frameworks

No need of ORM frameworks

No need to know 23 OOP patterns and more

DI : Partial application

Dependencies can only happen when a specific type is referenced. If you use generic types, you cannot have a dependency! And rather than hard coding behavior for a type, why not parameterize it by passing in functions instead?