Editing Programming guidelines (section)

=== Types ===

* Prefer proper data types over type synonyms or tuples even if you have to do more constructing and unpacking. This will make it easier to supply class instances later on. Don't put class constraints on a data type, constraints belong only to the functions that manipulate the data.

* Using type synonyms consistently is difficult over a longer time, because this is not checked by the compiler. (The types shown by the compiler may be unpredictable: i.e. <code>FilePath</code>, <code>String</code> or <code>[Char]</code>.)

* Take care if your data type has many variants (unless it is an enumeration type). Don't repeat common parts in every variant since this will cause code duplication.

:Bad (to handle arguments in sync):

::<haskell>
data Mode f p = Box f p | Diamond f p
</haskell>

:Good (to handle arguments only once):

::<haskell>
data BoxOrDiamond = Box | Diamond

data Mode f p = Mode BoxOrDiamond f p
</haskell>


* Consider (bad):

::<haskell>
data Tuple a b = Tuple a b | Undefined
</haskell>

:versus (better):

::<haskell>
data Tuple a b = Tuple a b
</haskell>

:and using:

::<haskell>
Maybe (Tuple a b)
</haskell>

:(or another monad) whenever an undefined result needs to be propagated