# Design Patterns for OCaml **URL:** \ **Category:** Learning\ **Tags:** ocaml, tutorial\ **Created:** [August 30, 2023, 3:55pm UTC](https://discuss.ocaml.org/t/design-patterns-for-ocaml/12930 "2023-08-30T15:55:41Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![shubhamkumar13](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/shubhamkumar13/32/2486_2.png) [@shubhamkumar13](https://discuss.ocaml.org/u/shubhamkumar13)\ **Post date:** [August 30, 2023, 3:55pm UTC](https://discuss.ocaml.org/t/design-patterns-for-ocaml/12930/1 "2023-08-30T15:55:41Z")
I didn’t find many resources for writing idiomatic readable ocaml code. The only one resource that I have found is : [https://people.csail.mit.edu/dnj/teaching/6898/projects/vicente-wagner.pdf](https://people.csail.mit.edu/dnj/teaching/6898/projects/vicente-wagner.pdf) But it talks about writing code using gof patterns. And it’s inclination is more towards object oriented style and uses classes more than functions, records and modules. Any resources related to writing more readable, composable and less side effecty code. ---
**Author:** ![jumpnbrownweasel](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jumpnbrownweasel/32/3062_2.png) [@jumpnbrownweasel](https://discuss.ocaml.org/u/jumpnbrownweasel)\ **Post date:** [August 30, 2023, 4:27pm UTC](https://discuss.ocaml.org/t/design-patterns-for-ocaml/12930/2 "2023-08-30T16:27:43Z")
There are some general guidelines here. [https://ocaml.org/docs/guidelines](https://ocaml.org/docs/guidelines) More specific to your question: [https://ocaml.org/docs/guidelines#when-to-use-mutables](https://ocaml.org/docs/guidelines#when-to-use-mutables) ---
**Author:** ![Alizter](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/alizter/32/3735_2.png) [@Alizter](https://discuss.ocaml.org/u/Alizter)\ **Post date:** [August 30, 2023, 8:28pm UTC](https://discuss.ocaml.org/t/design-patterns-for-ocaml/12930/3 "2023-08-30T20:28:13Z")
Our contribution guidelines for Dune contain a section on the kind of style that we encourage: [https://github.com/ocaml/dune/blob/main/doc/hacking.rst#general-guidelines](https://github.com/ocaml/dune/blob/main/doc/hacking.rst#general-guidelines) It’s obviously specific to the Dune code base so you will have to filter out ones that don’t make sense generally. ---
**Author:** ![bluddy](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/bluddy/32/104_2.png) [@bluddy](https://discuss.ocaml.org/u/bluddy)\ **Post date:** [August 31, 2023, 1:00am UTC](https://discuss.ocaml.org/t/design-patterns-for-ocaml/12930/4 "2023-08-31T01:00:50Z")
> [@Alizter](#): > > Our contribution guidelines for Dune contain a section on the kind of style that we encourage: I’m reading the dune guidelines, and I think they’re too opinionated to be useful elsewhere. My advice for readable code is the same as most other languages: use clear variable names. Use familiar patterns where possible (map, fold) rather than rolling your own functions. Separate out complex functionality into a function with a clear name. Write unit tests. Don’t be afraid to refactor to a more meaningful naming scheme. Try to go back and read your code and learn what works and what doesn’t for the _reader_. We are all readers of code more than writers – this is what’s important ultimately. My advice specifically in OCaml is to avoid side effects as much as possible, and separate them out from pure code (as if you were writing haskell). This has very important effects (no pun intended) on your code. Pure code can only modify one or two things at a time, and that forces you to simplify your code – you have no other choice. ---
**Author:** ![EricGT](https://avatars.discourse-cdn.com/v4/letter/e/f1d935/32.png) [@EricGT](https://discuss.ocaml.org/u/EricGT)\ **Post date:** [August 31, 2023, 10:08am UTC](https://discuss.ocaml.org/t/design-patterns-for-ocaml/12930/5 "2023-08-31T10:08:23Z")
Not sure if this is what you seek or maybe you already know this but worth a mention for others that may find this topic. > **[Pure-Fun - Purely Functional Data Structures for OCaml](https://mmottl.github.io/pure-fun/)** > > Purely functional data structures for OCaml, translated from Chris Okasaki's book [WorldCat](https://www.worldcat.org/title/1041378204) ---
**Author:** ![lukstafi](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/lukstafi/32/3442_2.png) [@lukstafi](https://discuss.ocaml.org/u/lukstafi)\ **Post date:** [August 31, 2023, 11:36am UTC](https://discuss.ocaml.org/t/design-patterns-for-ocaml/12930/6 "2023-08-31T11:36:44Z")
> [@bluddy](#): > > I think they’re too opinionated to be useful elsewhere > [@bluddy](#): > > My advice specifically in OCaml is to avoid side effects as much as possible, and separate them out from pure code While I’m very sinful in this regard, I strongly support OCaml beginners practice such discipline religiously for, say, three months. ---
**Author:** ![bluddy](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/bluddy/32/104_2.png) [@bluddy](https://discuss.ocaml.org/u/bluddy)\ **Post date:** [August 31, 2023, 4:09pm UTC](https://discuss.ocaml.org/t/design-patterns-for-ocaml/12930/7 "2023-08-31T16:09:09Z")
> [@lukstafi](#): > > While I’m very sinful in this regard, I strongly support OCaml beginners practice such discipline religiously for, say, three months It’s not about following it religiously. I think you get the most out of the language by following this advice in a general sense. The language is at its strongest when using functional paradigms. For performance-oriented reasons, these paradigms need to be broken sometimes. But every time you switch to mutation or other side effects, you’re trading code safety for performance or convenience. Monads are an option sometimes, but they come with their own costs. ---
**Author:** ![UnixJunkie](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/unixjunkie/32/638_2.png) [@UnixJunkie](https://discuss.ocaml.org/u/UnixJunkie)\ **Post date:** [September 1, 2023, 1:19am UTC](https://discuss.ocaml.org/t/design-patterns-for-ocaml/12930/8 "2023-09-01T01:19:19Z")
A big program is just a collection of small functions. Make each function do just one thing (but do it well). Once you have a bunch of functions operating on the same thing, put them in a module. ---
**Author:** ![bluddy](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/bluddy/32/104_2.png) [@bluddy](https://discuss.ocaml.org/u/bluddy)\ **Post date:** [September 1, 2023, 10:26pm UTC](https://discuss.ocaml.org/t/design-patterns-for-ocaml/12930/9 "2023-09-01T22:26:05Z")
Also, you will need some way to store your state in most programs. Since global state is generally frowned upon, that’s not a good option except for a few exceptions like debug state. OOP carries its state around inside the objects, with the massive downside that it’s very hard to know which functions modify or access which parts of an object’s state. In functional programming you will generally create a record that contains other records, each one to do with another part of your program state. It’s a good idea in general that each one of these record types should have its own module dealing with its needs and contents.