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 the package name (or at least a noun or verb part of a
package name) in each identifier provided by the package. (This isn't a
perfect approach considering of a large distributed flat namespace of
provides of all the third-party packages, and you don't have to do it
every time, but I think it's usually pretty good balance of a number of
goals.)
Also, for other reasons, consider making provided procedures named as
English sentences. (Remember that Racket procedures are evaluated
imperatively.)
For example, If your package is named `frisky` (a cat), you might
provide procedures such as `feed-frisky`, `display-frisky`, and
`animate-frisky`.
For another example, let's say someone else makes a package that
augments package `frisky`, and calls their package `frisky-laser`, and
might provide procedures like `play-with-frisky-with-laser`.
This reduces name collisions, often reads pretty easily, is a good
convention to pick for naming consistency, and gives some imperfect
sense of various identifiers' packages when glancing at a block of
reusing code.
(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`. What I mentioned above is my current default convention
for Racket when I don't think of good reason to do it differently, and
am not experimenting/playing with doing it differently as an exercise.)
(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 specialness, and to avoid the frequent naming collisions
when you want to provide encapsulating behavior around struct field
accessors.)
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
