1972年に、3人の人気のあるコンピューター科学者が、構造的プログラミングという本を書きました。
最新の調査のすべての構造化データは、プリミティブまたは非構造化タイプに属する非構造化コンポーネントから構築する必要があります。 これらの非構造化型の一部（たとえば、実数や整数）は、プログラミング言語またはコンピューターのハードウェア（およそのハードウェア）で与えられたものと見なすことができます。 これらのプリミティブ型は理論的にはすべての場合に適していますが、変数値の潜在的な境界とそのような各値の解釈に関する意図を明確にするために、プログラマーが独自の非構造化型を指定するのを支援する強力な実用的な理由があります; そして、効果的なパフォーマンスのその後の設計を可能にします。
（...）この型は列挙（列挙に注意）と呼ばれ、型名の標準表記と、型名と各代替値との関連付けを推奨します。
`
タイプスーツ=（クラブ、ダイヤモンド、ハート、スペード）;
（...）
タイプ年= 1900 ... 1960;
タイプ座標= 0 ... 1023;
`
（...）したがって、 a ... bがaからbまでの値の範囲を示すルールを導入します。 これは、 aおよびbが属するタイプのサブレンジ/サブグループとして知られています（...）
（ 英語 ）
Ole-Johan Dahl、Edsger W. Dijkstra、CAR Hoare、構造化プログラミング、APIC Studies in Data Processing、No。 8、1972、p。97
一部の言語は、 AdaやDelphiなどのサブグループタイプを実際にサポートしています。 ただし、JavaやC＃などの最新の一般的な言語は、非構造化プライベートサブグループタイプを直接サポートしていません。
これに加えて、型宣言とその実際の意味の間には大きな誤解があります。 たとえば、.NETでは、 配列は[-2 ^ 31、2 ^ 31]の範囲のインデックスとしてIntegerを受け入れるため、インデックス値として-1、-2、...のサポートを宣言します。 同時に、負でない数のみが許可されます。 [0、2 ^ 31]。 正直で明快なコードを作成するには、 配列[NonnegativeInteger]表記が必要です。
さらに、一般的に使用される構造化タイプと非構造化タイプは数字に限定されません。 今日、電子メールは多くの場合、 文字列型として表されます。
function void SendEmail(String email, String emailBody){ ... }
実際には
function void SendEmail(EmailAddress email, String emailBody){ ... }
EmailAddressクラス/構造のすべてのオブジェクトが常にtrueであると仮定すると、 IsEmail（）ヘルパーまたはDataAnnotations属性（.NET）で毎回行をチェックする必要がなくなります。 文字列からの便利な変換のために、 EmailAddress TryConvert（文字列メール）関数関数を持っている場合があります。
明らかな改善のための他の典型的な場所：
- 名前
同じ制限、おそらく256文字以下の特殊文字と少なくとも1文字のプログラム全体で、名前と姓のString型の名前をチェックすることは、プログラマーが実際に意味するものであるclass / structure Nameに置き換えることができます。
- クラス連絡先メッセージ、注文コメント、フィードバックメッセージなどの一般的なルールを含む説明
- 尺度：度、座標、重量など
- 日時
年、月、日、時間、および分の2147483648（2 ^ 31）までの数値は、実際の使用では便利ではないと思われ、多くのシステムでは、これらのタイプに大きな数値を使用するとエラーがスローされます。
- お金
マイナス100ドルの紙幣はありませんが、100ドルの負債の概念があるかもしれません。
Design by Contractsでは、ほとんどのチェックをコンパイル時に実行できます。 他のシステムとの互換性のために、プライベート型はIntegerやStringなどのプリミティブ型および単純型から構築され、これらの型から変換可能である必要があります。