6 replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
source | link

Keep each function as simple as possible.

Think of it in simple terms, the way a function is meant to be:

  • gets 0 to N inputs,
  • returns 0 or 1 result (possible a composite or collection),
  • and isn't tied to state.

    Programming functions should aim to be equivalent to mathematical functions

When you stick to functional programming idioms, you get rid of most of these questions you're asking yourself. Sure, your class will get bigger in terms of number of functions. But if the methods are not tied to each by internal state changes, they get easier to understand, manage and compose to achieve an end result.

Function composition

Also, try to give them appropriate accesses based on the above design decisions. Helpers will commonly easily be declared as statics (and if they don't seem to need to be private or can be reused, they could extracted to an helper class), which gives a strong hint to the other developers: this thing is meant to be independent and side-effect free.

Repeat the following mantras to aim for purity:

  • My function shall be:
    • short,
    • side-effects free,
    • realizing one and one function only.
  • My function shall be strict on output. [1]
  • My function shall be testable, and tested.
  • My function shall be readable and read like a natural language expression.
  • My function shall be documenteddocumented. [2]
  • My function shall be null-hostile.

[1] Whether it shall be strict or lenient on input depends on whether it's consumer code or library code.
[2] Self-documentation counts, comments for tricky parts count as well.


Of course, if you are in a generally non-FP-oriented code base, you won't manage to avoid shared mutable state for ever, but it's a very good, sensitive and no-BS guideline to follow. Even if you do get it wrong by over-modularizing and complexifying your class, it'll still be easier to pick up from there and refactor again than from a giant dump of code with high complexity and tight coupling.

Regarding the rules of the compositionality of your functions, these are your business rules. They are dictated by what you want to achieve, there's no automagical way of determining it for you.

Keep each function as simple as possible.

Think of it in simple terms, the way a function is meant to be:

  • gets 0 to N inputs,
  • returns 0 or 1 result (possible a composite or collection),
  • and isn't tied to state.

    Programming functions should aim to be equivalent to mathematical functions

When you stick to functional programming idioms, you get rid of most of these questions you're asking yourself. Sure, your class will get bigger in terms of number of functions. But if the methods are not tied to each by internal state changes, they get easier to understand, manage and compose to achieve an end result.

Function composition

Also, try to give them appropriate accesses based on the above design decisions. Helpers will commonly easily be declared as statics (and if they don't seem to need to be private or can be reused, they could extracted to an helper class), which gives a strong hint to the other developers: this thing is meant to be independent and side-effect free.

Repeat the following mantras to aim for purity:

  • My function shall be:
    • short,
    • side-effects free,
    • realizing one and one function only.
  • My function shall be strict on output. [1]
  • My function shall be testable, and tested.
  • My function shall be readable and read like a natural language expression.
  • My function shall be documented. [2]
  • My function shall be null-hostile.

[1] Whether it shall be strict or lenient on input depends on whether it's consumer code or library code.
[2] Self-documentation counts, comments for tricky parts count as well.


Of course, if you are in a generally non-FP-oriented code base, you won't manage to avoid shared mutable state for ever, but it's a very good, sensitive and no-BS guideline to follow. Even if you do get it wrong by over-modularizing and complexifying your class, it'll still be easier to pick up from there and refactor again than from a giant dump of code with high complexity and tight coupling.

Regarding the rules of the compositionality of your functions, these are your business rules. They are dictated by what you want to achieve, there's no automagical way of determining it for you.

Keep each function as simple as possible.

Think of it in simple terms, the way a function is meant to be:

  • gets 0 to N inputs,
  • returns 0 or 1 result (possible a composite or collection),
  • and isn't tied to state.

    Programming functions should aim to be equivalent to mathematical functions

When you stick to functional programming idioms, you get rid of most of these questions you're asking yourself. Sure, your class will get bigger in terms of number of functions. But if the methods are not tied to each by internal state changes, they get easier to understand, manage and compose to achieve an end result.

Function composition

Also, try to give them appropriate accesses based on the above design decisions. Helpers will commonly easily be declared as statics (and if they don't seem to need to be private or can be reused, they could extracted to an helper class), which gives a strong hint to the other developers: this thing is meant to be independent and side-effect free.

Repeat the following mantras to aim for purity:

  • My function shall be:
    • short,
    • side-effects free,
    • realizing one and one function only.
  • My function shall be strict on output. [1]
  • My function shall be testable, and tested.
  • My function shall be readable and read like a natural language expression.
  • My function shall be documented. [2]
  • My function shall be null-hostile.

[1] Whether it shall be strict or lenient on input depends on whether it's consumer code or library code.
[2] Self-documentation counts, comments for tricky parts count as well.


Of course, if you are in a generally non-FP-oriented code base, you won't manage to avoid shared mutable state for ever, but it's a very good, sensitive and no-BS guideline to follow. Even if you do get it wrong by over-modularizing and complexifying your class, it'll still be easier to pick up from there and refactor again than from a giant dump of code with high complexity and tight coupling.

Regarding the rules of the compositionality of your functions, these are your business rules. They are dictated by what you want to achieve, there's no automagical way of determining it for you.

5 added 270 characters in body
source | link

Keep each function as simple as possible.

Think of it in simple terms, the way a function is meant to be:

  • gets 0 to N inputs,
  • returns 0 or 1 result (possible a composite or collection),
  • and isn't tied to state.

    Programming functions should aim to be equivalent to mathematical functions

When you stick to functional programming idioms, you get rid of most of these questions you're asking yourself. Sure, your class will get bigger in terms of number of functions. But if the methods are not tied to each by internal state changes, they get easier to understand, manage and compose to achieve an end result.

Function composition

Also, try to give them appropriate accesses based on the above design decisions. Helpers will commonly easily be declared as statics (and if they don't seem to need to be private or can be reused, they could extracted to an helper class), which gives a strong hint to the other developers: this thing is meant to be independent and side-effect free.

Repeat the following mantras to aim for purity:

  • My function shall be:
    • short,
    • side-effects free,
    • realizing one and one function only.
  • My function shall be strict on output. [1]
  • My function shall be testable, and tested.
  • My function shall be readable and read like a natural language expression.
  • My function shall be documented. [2]
  • My function shall be null-hostile.

[1] Whether it shall be strict or lenient on input depends on whether it's consumer code or library code.
[2] Self-documentation counts, comments for tricky parts count as well.


Of course, if you are in a generally non-FP-oriented code base, you won't manage to avoid shared mutable state for ever, but it's a very good, sensitive and no-BS guideline to follow. Even if you do get it wrong by over-modularizing and complexifying your class, it'll still be easier to pick up from there and refactor again than from a giant dump of code with high complexity and tight coupling.

Regarding the rules of the compositionality of your functions, these are your business rules. They are dictated by what you want to achieve, there's no automagical way of determining it for you.

Keep each function as simple as possible.

Think of it in simple terms, the way a function is meant to be:

  • gets 0 to N inputs,
  • returns 0 or 1 result (possible a composite or collection),
  • and isn't tied to state.

    Programming functions should aim to be equivalent to mathematical functions

When you stick to functional programming idioms, you get rid of most of these questions you're asking yourself. Sure, your class will get bigger in terms of number of functions. But if the methods are not tied to each by internal state changes, they get easier to understand, manage and compose to achieve an end result.

Function composition

Also, try to give them appropriate accesses based on the above design decisions. Helpers will commonly easily be declared as statics (and if they don't seem to need to be private or can be reused, they could extracted to an helper class), which gives a strong hint to the other developers: this thing is meant to be independent and side-effect free.

Repeat the following mantras to aim for purity:

  • My function shall be:
    • short,
    • side-effects free,
    • realizing one and one function only.
  • My function shall be strict on output. [1]
  • My function shall be testable, and tested.
  • My function shall be readable and read like a natural language expression.
  • My function shall be documented. [2]
  • My function shall be null-hostile.

[1] Whether it shall be strict or lenient on input depends on whether it's consumer code or library code.
[2] Self-documentation counts, comments for tricky parts count as well.


Of course, if you are in a generally non-FP-oriented code base, you won't manage to avoid shared mutable state for ever, but it's a very good, sensitive and no-BS guideline to follow. Even if you do get it wrong by over-modularizing and complexifying your class, it'll still be easier to pick up from there and refactor again than from a giant dump of code with high complexity and tight coupling.

Keep each function as simple as possible.

Think of it in simple terms, the way a function is meant to be:

  • gets 0 to N inputs,
  • returns 0 or 1 result (possible a composite or collection),
  • and isn't tied to state.

    Programming functions should aim to be equivalent to mathematical functions

When you stick to functional programming idioms, you get rid of most of these questions you're asking yourself. Sure, your class will get bigger in terms of number of functions. But if the methods are not tied to each by internal state changes, they get easier to understand, manage and compose to achieve an end result.

Function composition

Also, try to give them appropriate accesses based on the above design decisions. Helpers will commonly easily be declared as statics (and if they don't seem to need to be private or can be reused, they could extracted to an helper class), which gives a strong hint to the other developers: this thing is meant to be independent and side-effect free.

Repeat the following mantras to aim for purity:

  • My function shall be:
    • short,
    • side-effects free,
    • realizing one and one function only.
  • My function shall be strict on output. [1]
  • My function shall be testable, and tested.
  • My function shall be readable and read like a natural language expression.
  • My function shall be documented. [2]
  • My function shall be null-hostile.

[1] Whether it shall be strict or lenient on input depends on whether it's consumer code or library code.
[2] Self-documentation counts, comments for tricky parts count as well.


Of course, if you are in a generally non-FP-oriented code base, you won't manage to avoid shared mutable state for ever, but it's a very good, sensitive and no-BS guideline to follow. Even if you do get it wrong by over-modularizing and complexifying your class, it'll still be easier to pick up from there and refactor again than from a giant dump of code with high complexity and tight coupling.

Regarding the rules of the compositionality of your functions, these are your business rules. They are dictated by what you want to achieve, there's no automagical way of determining it for you.

4 added 406 characters in body
source | link

Keep each function as simple as possible.

Think of it in simple terms, the way a function is meant to beway a function is meant to be:

  • gets 0 to N inputs,
  • returns 0 or 1 result (possible a composite or collection),
  • and isn't tied to state.

    and isn't tied to state.

    Programming functions should aim to be equivalent to mathematical functions

When you stick to functional programmingfunctional programming idioms, you get rid of most of these questions you're asking yourself. Sure, your class will get bigger in terms of number of functions. But if the methods are not tied to each by internal state changes, they get easier to understand, manage and composecompose to achieve an end result.

Function composition

Also, try to give them appropriate accesses based on the above design decisions. Helpers will commonly easily be declared as statics (and if they don't seem to need to be private or can be reused, they could extracted to an helper class), which gives a strong hint to the other developers: this thing is meant to be independent and side-effect free.

Repeat the following mantras to aim for purity:

  • My function shall be:
    • short,
    • side-effects free,
    • realizing one and one function only.
  • My function shall be strict on output. [1]
  • My function shall be testable, and tested.
  • My function shall be readable and read like a natural language expression.
  • My function shall be documented. [2]
  • My function shall be null-hostile.

[1] Whether it shall be strict or lenient on input depends on whether it's consumer code or library code.
[2] Self-documentation counts, comments for tricky parts count as well.


Of course, if you are in a generally non-FP-oriented code base, you won't manage to avoid shared mutable state for ever, but it's a very good, sensitive and no-BS guideline to follow. Even if you do get it wrong by over-modularizing and complexifying your class, it'll still be easier to pick up from there and refactor again than from a giant dump of code with high complexity and tight coupling.

Keep each function as simple as possible.

Think of it in simple terms, the way a function is meant to be:

  • gets 0 to N inputs,
  • returns 0 or 1 result (possible a composite or collection),
  • and isn't tied to state.

When you stick to functional programming idioms, you get rid of most of these questions you're asking yourself. Sure, your class will get bigger in terms of number of functions. But if the methods are not tied to each by internal state changes, they get easier to understand, manage and compose to achieve an end result.

Also, try to give them appropriate accesses based on the above design decisions. Helpers will commonly easily be declared as statics (and if they don't seem to need to be private or can be reused, they could extracted to an helper class), which gives a strong hint to the other developers: this thing is meant to be independent and side-effect free.

Repeat the following mantras:

  • My function shall be:
    • short,
    • side-effects free,
    • realizing one and one function only.
  • My function shall be strict on output. [1]
  • My function shall be testable, and tested.
  • My function shall be readable and read like a natural language expression.
  • My function shall be documented. [2]
  • My function shall be null-hostile.

[1] Whether it shall be strict or lenient on input depends on whether it's consumer code or library code.
[2] Self-documentation counts, comments for tricky parts count as well.


Of course, if you are in a generally non-FP-oriented code base, you won't manage to avoid shared mutable state for ever, but it's a very good, sensitive and no-BS guideline to follow. Even if you do get it wrong by over-modularizing and complexifying your class, it'll still be easier to pick up from there and refactor again than from a giant dump of code with high complexity and tight coupling.

Keep each function as simple as possible.

Think of it in simple terms, the way a function is meant to be:

  • gets 0 to N inputs,
  • returns 0 or 1 result (possible a composite or collection),
  • and isn't tied to state.

    Programming functions should aim to be equivalent to mathematical functions

When you stick to functional programming idioms, you get rid of most of these questions you're asking yourself. Sure, your class will get bigger in terms of number of functions. But if the methods are not tied to each by internal state changes, they get easier to understand, manage and compose to achieve an end result.

Function composition

Also, try to give them appropriate accesses based on the above design decisions. Helpers will commonly easily be declared as statics (and if they don't seem to need to be private or can be reused, they could extracted to an helper class), which gives a strong hint to the other developers: this thing is meant to be independent and side-effect free.

Repeat the following mantras to aim for purity:

  • My function shall be:
    • short,
    • side-effects free,
    • realizing one and one function only.
  • My function shall be strict on output. [1]
  • My function shall be testable, and tested.
  • My function shall be readable and read like a natural language expression.
  • My function shall be documented. [2]
  • My function shall be null-hostile.

[1] Whether it shall be strict or lenient on input depends on whether it's consumer code or library code.
[2] Self-documentation counts, comments for tricky parts count as well.


Of course, if you are in a generally non-FP-oriented code base, you won't manage to avoid shared mutable state for ever, but it's a very good, sensitive and no-BS guideline to follow. Even if you do get it wrong by over-modularizing and complexifying your class, it'll still be easier to pick up from there and refactor again than from a giant dump of code with high complexity and tight coupling.

3 added 28 characters in body
source | link
2 added 263 characters in body
source | link
1
source | link