@@ -141,39 +141,11 @@ $ stack haddock --no-haddock-deps
141141
142142For design documentation see the `design` directory.
143143
144−## Coding
144+## Coding Guidelines
145145
146−### Style
146+### Coding Style
147147
148−As long as possible please try to match the style of the file or the
149−surrounding code. For haskell coding style guidelines, please [see this style
150−guide](https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md).
151−Specifically,
152−
153−* Please use 4 spaces for indentation.
154−* Do not let the code go beyond 80 columns
155−
156−Indent the `where` clause as follows:
157−
158−```
159−f x = ...
160− where
161−
162− f1 = ...
163−```
164−
165−In general, we avoid using a prime on the variable names, e.g. we use `step1`
166−instead of `step'`. Numbered indexing is better because it is easier on the
167−eyes and we can represent multiple generations of the variables without adding
168−more characters e.g. we can write `step2` instead of `step''`.
169−
170−Use shorter variable names for shorter scopes, use longer variable names for
171−bigger scopes.
172−
173−Imports:
174−
175−* Import symbols explicitly by names as long as possible
176−* Import qualified is there are too many symbols to be imported
148+Please see [the Haskell coding style guide](https://github.com/composewell/haskell-dev/blob/master/coding-style.rst).
177149
178150### StreamD coding style
179151
@@ -205,35 +177,6 @@ has a bigger scope and `state` has the biggest scope.
205177
206178For better fusion we try to keep a single yield point in the state machine.
207179
208−### Organization
209−
210−Use this simple rule to organize functions in a file: `Define before first
211−use`. In other words, use the `bottom up style` to organize functions.
212−
213−One big benefit of this rule is easier type error debugging. Using a single
214−block comment, at any point in the file up to the end of the file, you can cut
215−the tail and still cleanly compile the remaining head portion of the file.
216−
217−It is very helpful when we make significant changes to the file. We can start
218−compiling a minimal head portion of the file and keep expanding the head by
219−just moving the start of commented block further down. This keeps the scope of
220−type inference minimal and type errors can be discovered incrementally by
221−increasing the scope a little bit at a time. If you use type signatures on all
222−top level declarations then you do not even need to comment out the code. This
223−organization results in a better order of type errors which makes it easier to
224−fix them and when necessary, use elimination method by commenting out some code.
225−
226−Similarly when you put modules in the cabal file in dependency order you can
227−do the same there, just comment out a tail of the module list and your library
228−will still compile.
229−
230−Note that this rule does not apply in choosing `let` vs `where` clauses. Use of
231−`let`s leads to bottom up and use of `where`s leads to top down style. But we
232−do not encourage `let` over `where`, you can freely use `where` clauses.
233−
234−Also note that this is not possible in mutually recursive code. The mutually
235−recursive code has to be considered a single block.
236−
237180### Tricky Parts
238181
239182The state-passing through each API is currently fragile. Every time we run a