I believe OP is referring to the paragraph about
play-with-frisky-with-laser being their default style and their sincere
recommendation for Racket code style.
It also seems to be the style that most closely matches core APIs.
On August 29, 2017 at 11:23:51, David Storrs (david.sto...@gmail.com)
On Tue, Aug 29, 2017 at 6:12 AM, Neil Van Dyke wrote:
>
>
> (Of course, other general conventions also have their merits, in various
> languages and environments. For example `FrskyLsr_szGetColor()`. And
> `com.example.FriskyLaser.FriskyLaserPlayBehavior.play` and unqualified
> form `play`. Wh
It's also worth considering that you can munge the names when you
provide -- and your users can munge them on require.
See filtered-out and filtered-in -- as well as the more commonly used
conveniences built on them, like prefix-{in out}, rename-{in out}, and
so on.
I think sometimes the goodnes
On Tue, Aug 29, 2017 at 11:12 AM, Neil Van Dyke
wrote:
>
> (Someday, I will have time to release a package that changes how
> `define-struct`/`struct` identifiers are generated, to use `.` or `:`. To
> at least have the appearance of being more idiomatic, to hint at the
> various other specialne
I recommend trying to develop most non-core Racket modules as if you
might want to share them as small reusable third-party open source
packages in the near future. Which has implications for naming.
For reusable third-party Racket packages, right now, I recommend usually
trying to include th
The style guide Jack mentions is not really about the /library's/ name, but
rather about the data type of the main (usually the first) argument, as
saide. For example you could have a library called `my-wonderful-lib' that
experts `vector-splendify', which takes a vector as its first argument.
On
6 matches
Mail list logo