活発な街道沿いという無防備な場所に位置しているため、三十年戦争の時代のシュランゲン住民は甚大な被害を受けた。1622年にクリスティアン・フォン・ブラウンシュヴァイクがシュランゲンとリップシュプリンゲを占領した。1634年には、村の 7軒の家屋が暴徒化した兵士によって焼き払われた。1646年、この村はハンス・クリストフ・フォン・ケーニヒスマルクが率いるスウェーデンとヴァイマルの軍勢に襲われた。これにより、シュランゲンとコールシュテットは長らく廃村となった。生き延びた農民たちは、わずかに残った家畜とともに森の中に逃げ込んだ。戦争の犠牲にならなかった人々も、重度の天然痘、ペスト、チフスによって命を落とした。1648年の終戦後、放棄された農場や廃屋にわずかな人が住むだけであった。4年後にもシュランゲンには約 30軒の空き家があった。七年戦争でも、シュランゲンは両軍勢の交戦地域に再びなった。シュランゲンとリップシュプリンゲとの間のデーディングハウゼンの荒れ地に数千の兵士が宿営した。周辺住民は食料の提供だけでなく、輸送業務や土木工事の手伝いも要求された。
シュランゲンは、単に重要な街道沿いに位置していただけでなく、リッペ伯領とパーダーボルン司教領との領邦国境にあたっていた。リップシュプリンゲに近い国境沿いの古い集会場で、リッペ伯の使者とパーダーボルン司教の使者が国境紛争に関する協議を繰り返した（リップシュプリンゲの和議）。1558年のシュランゲン条約でベルンハルト8世伯はパーダーボルン司教からピルモント＝シュピーゲルベルク伯領をレーエンとして授けられた。しかしその代償として、プロテスタントのリッペ伯領における宗教上の重要な諸権利をカトリックの司教に譲渡しなければならなかった。「宗教的熱狂が支配した時代に領主は、自分の国ではカトリック系住民に対する寛容を示した。協定に基づき、旧教徒の誰一人として、その信仰を理由に弾圧されたり圧力をかけられたりしなかった。修道院や宗教団体は、最後の信者が亡くなるまで存続していた。パーダーボルンに対する納税義務に対して拘束力があれば、この条約はその後の規範となったであろう。」17世紀初めのパーダーボルンでの対抗宗教改革の際には、多くのプロテスタント信者がシュランゲンの教会に避難した。司教によって派遣されたイエズス会士は痩せた耕地を嘆き、シュランゲン沼を呪った。
多くの出土品が、シュラーゲン周辺には新石器時代に定住がなされたことを示している。青銅器時代からは、リッペ地方の境界付近にあたるシュトローエタールに芝の墳丘墓群が形成された。現在の改革派教会の場所から聖キリアンを守護聖人とする9世紀の基礎建築が発掘されたことは、この時代にはすでにシュランゲンが建設されていたことを示している。この古いロマネスク教会は、古い街道の交差点に面していた。シュラーゲンは、コールシュテットやエスターホルツ＝ハウステンベックとともにパーダーボルン司教マインヴェルクの伝記に登場する。修道女オーダ・ツー・ゲゼークが、Lanchel（シュランゲン）、Astanholte（エスターホルツ）、Colstidi（コールシュテット）の相続した土地をパーダーボルンの教会に寄贈したというものである。フェーデで特徴付けられる中世後期のシュランゲン周辺地域の土地所有者は明らかでない。地元の農民たちは、パーダーボルン司教と聖堂参事会へも納税が義務づけられていた。コルヴァイ修道院、ブースドルフ修道院、ゴーキルヒェン修道院、ノイエンヘールゼ修道院、ハルデハウゼン修道院も時折古文書に登場する。この他にシュヴァーレンベルク伯、リッペ家、その他の世俗領主にも税を支払う必要があった。
シュランゲンは、北西から時計回りに、リッペ郡のアウグストドルフ、デトモルト、ホルン＝バート・マインベルク、パーダーボルン郡のアルテンベーケン、リップシュプリンゲ、ヘーフェルホーフ、ギュータースロー郡のシュロス・ホルテ＝シュトゥーケンブロックと境を接している。
表明とエラー処理ルーチンを区別することには意味がある。表明は論理的にありえない状況をチェックするのに使うべきである。もし、「ありえない」ことが起きたとしたら、根本的に何かが間違っていたということである。エラー処理は通常発生しうるエラーを処理する（もちろん、一部の状況はほとんど「ありえない」かもしれない）。表明をあらゆるエラー処理に使用するのは賢明ではない。表明ではエラーからの復旧が考慮されておらず、表明違反は無条件でプログラムを停止させてしまう場合がほとんどである。表明はユーザー向けのエラーメッセージも表示しない。エラー処理に表明を使っているC言語の例を以下に示す。int *ptr = malloc(sizeof(int) * 10);assert(ptr != NULL);// use ptrここで、プログラマは malloc が NULL を返す場合があることに気づいている（メモリを確保できなかった場合）。オペレーティングシステムは malloc が常に成功することは保証していない。したがってプログラムはメモリ確保失敗に対処すべきである。この例では表明は最良の選択ではないだろう。というのも、malloc の失敗は論理的にありえないことではないからである。実際には滅多に発生しないが、設計上考慮すべき可能性である。しかし、このような表明にも利点がある。つまり、プログラマが自分の意思で malloc のエラーに対処するコードを書かない選択をしたことを他の人々に知らしめているのである。表明の引数である式の副作用に依存するという間違いをすることもある。表明は条件の評価（バグがないことの確認）に使われるものであって、全く実行されないこともあることを常に念頭に置いておく必要がある。最終的にプログラムに問題がないと判断すれば表明を抑止する可能性がある。例えば、次のようなC言語のプログラムがあるとする。  int *ptr;  assert(ptr = malloc(sizeof(int) * 10)); // malloc() が失敗すると NULL を返す。しかし、この文は NDEBUG シンボルを定義してコンパイルすると実行されなくなる。  // NDEBUG を定義してコンパイルすると、この時点で ptr は設定されていないことになる。  // ptr を使用する。  ...一見すると、malloc の値を ptr に代入して、同時に NULL かどうかをチェックするという賢いコーディングに見えるかもしれない。しかし、malloc 呼び出しと ptr への代入は副作用を伴い、その副作用はプログラム本体で必須なものである。コンパイル時に NDEBUG というシンボルを定義すると assert() は除去されるので、malloc() が呼び出されなくなり、ptr が初期化されずに使われることになる。結果として未定義動作を引き起こす。