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.

Reply via email to