<commit_before>

== Principles

Software entropy of the system increases over a period of time unless it is refactored


http://www.laputan.org/mud/

=== Clean code

keeping your code clean is not just cost effective; it’s a matter of
*professional survival*.

[verse, <NAME>, on clean code] 
Reduced duplication, high expressiveness, 
and early building of simple abstractions.
That’s what makes clean code for me.

== good practices
=== Method, Variable, Function, Interface, trait naming 
1. Use intention-revealing names
2. Avoid disinformation
3. Make meaningful distinctions
4. Use pronounceable names
5. Pick one word per concept
6. Add meaningful context
7. Classes and objects should have noun or noun phrase names
8. Methods should have verb or verb phrase names


=== Functions
1. keep it small (2-3 lines)
2. Do one thing
3. One level of abstraction per function
4. Apply the stepdown rule consistently
5. Avoid passing boolean arguments, rather seperate function into two
6. Keep arguments to one, two at most for functions
7. Prefer Exceptions to Returning Error Codes

`In the case of a monadic function, the function and argument should form a very nice verb/noun pair.`



=== Microservices

Microservices vs Monoliths
http://blog.arungupta.me/microservices-monoliths-noops/

Design patterns
http://blog.arungupta.me/microservice-design-patterns/

=== Guidelines on testing code 

One particularly good method to start using thrid party APIs in your code base is to use them in *Learning Tests*. 
These are normal tests which essentially start interacting with the api, but in ways you would expect. This allows you
to quickly find out the lmitations in how it might solve some of your problems.

== the three laws of TDD
---

. *First law* You may not write production code until you have written a failing unit test.
. *Second law* You may not write more of a unit test than is sufficient to fail, and not compiling
is failing.
. *Third law* You may not write more production code than is sufficient to pass the currently
failing test.

> These three laws lock you into a cycle that is perhaps thirty seconds long. The tests
and the production code are written together, with the tests just a few seconds ahead of the
production code.

The usual approach to writing Unit tests is to *BUILD-OPERATE-TEST* with `One assert per test`

[verse, <NAME>, a design is “simple” if it follows these rules]
. Runs all the tests
. Contains no duplication
. Expresses the intent of the programmer
. Minimizes the number of classes and methods
 

=== class organization
. Classes should be small

[Blockquote]
.class should begin with a list of variables. Public static constants, if any, should come first. Then private static variables, followed by private
instance variables. There is seldom a good reason to have a public variable.

.Public functions should follow the list of variables. We like to put the private utilities
called by a public function right after the public function itself. This follows the stepdown
rule and helps the program read like a newspaper article.

== Systems design 

. Separation of concerns (AOP concept)
. Dependency Injection (inversion of control)


=== Programming laws

. Law of demeter
. Liskov substitution principle

=== General principles
. *principle of least privilege*  - If you don’t need to name it anywhere else, you needn’t.

=== General tips

.write in the language you are writing in

<commit_msg>add abstraction rules<commit_after>

== Principles

Software entropy of the system increases over a period of time unless it is refactored


http://www.laputan.org/mud/

=== Clean code

keeping your code clean is not just cost effective; it’s a matter of
*professional survival*.

[verse, <NAME>, on clean code] 
Reduced duplication, high expressiveness, 
and early building of simple abstractions.
That’s what makes clean code for me.

== good practices
=== Method, Variable, Function, Interface, trait naming 
1. Use intention-revealing names
2. Avoid disinformation
3. Make meaningful distinctions
4. Use pronounceable names
5. Pick one word per concept
6. Add meaningful context
7. Classes and objects should have noun or noun phrase names
8. Methods should have verb or verb phrase names


=== Functions
1. keep it small (2-3 lines)
2. Do one thing
3. One level of abstraction per function
4. Apply the stepdown rule consistently
5. Avoid passing boolean arguments, rather seperate function into two
6. Keep arguments to one, two at most for functions
7. Prefer Exceptions to Returning Error Codes

`In the case of a monadic function, the function and argument should form a very nice verb/noun pair.`



=== Microservices

Microservices vs Monoliths
http://blog.arungupta.me/microservices-monoliths-noops/

Design patterns
http://blog.arungupta.me/microservice-design-patterns/

=== Guidelines on testing code 

One particularly good method to start using thrid party APIs in your code base is to use them in *Learning Tests*. 
These are normal tests which essentially start interacting with the api, but in ways you would expect. This allows you
to quickly find out the lmitations in how it might solve some of your problems.

== the three laws of TDD
---

. *First law* You may not write production code until you have written a failing unit test.
. *Second law* You may not write more of a unit test than is sufficient to fail, and not compiling
is failing.
. *Third law* You may not write more production code than is sufficient to pass the currently
failing test.

> These three laws lock you into a cycle that is perhaps thirty seconds long. The tests
and the production code are written together, with the tests just a few seconds ahead of the
production code.

The usual approach to writing Unit tests is to *BUILD-OPERATE-TEST* with `One assert per test`

[verse, Kent Beck, a design is “simple” if it follows these rules]
. Runs all the tests
. Contains no duplication
. Expresses the intent of the programmer
. Minimizes the number of classes and methods
 

=== class organization
. Classes should be small

[Blockquote]
.class should begin with a list of variables. Public static constants, if any, should come first. Then private static variables, followed by private
instance variables. There is seldom a good reason to have a public variable.

.Public functions should follow the list of variables. We like to put the private utilities
called by a public function right after the public function itself. This follows the stepdown
rule and helps the program read like a newspaper article.

== Systems design 

. Separation of concerns (AOP concept)
. Dependency Injection (inversion of control)


=== Programming laws

. Law of demeter
. Liskov substitution principle

=== General principles
. *principle of least privilege*  - If you don’t need to name it anywhere else, you needn’t.

=== General tips

.write in the language you are writing in




==== Abstraction

Properties that a system should have to best support the principle of abstraction?

. Encapsulation. It should be possible to hide the internals of a part.
. Compositionality. It should be possible to combine parts to make a new
part.
. Instantiation/invocation. It should be possible to create many instances
of a part based on a single definition. These instances “plug” themselves
into their environment (the rest of the system in which they will live) when
they are created.
{'fraction_non_alphanumeric': 0.05227701428186473, 'fraction_numerical': 0.004580975478307734, 'mean_word_length': 4.133471645919779, 'pattern_counts': {'":': 0, '<': 6, '<?xml version=': 0, '>': 8, 'https://': 0, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1631998', 'n_tokens_mistral': 1957, 'n_tokens_neox': 1844, 'n_words': 1116}