search

TuringLang / AbstractPPL.jl

Common types and interfaces for probabilistic programming
http://turinglang.org/AbstractPPL.jl/
MIT License
27 stars 7 forks source link

`snake_case` for `logdensity` #37

Closed ParadaCarleton closed 3 years ago

ParadaCarleton commented 3 years ago

Not 100% sure if we're sticking with the Blue style guide which is the standard for most Turing things. If we are, though, logdensity should be log_density. I'd suggest using that, since snake_case is the standard across most style guides.

devmotion commented 3 years ago

I think we should follow the example of logpdf and loglikelihood and keep logdensity. This would also be in line with the Julia style guide which generally recommends to squash words if it is readable.

cscherrer commented 3 years ago

I haven't been tracking this very closely, but there's a LogDensityProblems.logdensity that's not usually user-facing from a PPL, and MeasureBase.logdensity that's extremely user-facing (exported from Soss). How does this relate to those?

devmotion commented 3 years ago

Currently it's just another function of the same name.

ParadaCarleton commented 3 years ago

I think we should follow the example of logpdf and loglikelihood and keep logdensity. This would also be in line with the Julia style guide which generally recommends to squash words if it is readable.

I agree with us wanting to keep consistency between these; all the log* methods should be either in squash or camel case. The question is which one we should pick.

Julia style guide accepts either squash or snake, but Blue (and pretty much every other guide) requires snake.

devmotion commented 3 years ago

either in squash or camel case.

The convention is to use camel case only for types and modules (both in the Julia style guide and Blue style).

Also I am pretty sure StatsBase.loglikelihood and Distributions.logpdf won't be renamed anytime soon, so it seems consistency can be achieved only with logdensity.

Blue (and pretty much every other guide) requires snake.

In my experience, in practice many Julia packages that follow Blue style still use squashed function names when appropriate. Possibly due to the contradicting recommendation in the Julia style guide, possibly because it can't be enforced by JuliaFormatter, possibly because it's not a strict requirement but only a recommendation (Blue style even tells users that "most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply").

phipsgabler commented 3 years ago

Blue style even tells users that "most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply"

No matter how much of a fan of Blue style I am or not, I think this is the key issue. All of the related functions within the relevant packages, starting from Distributions and StatsXYZ, are using this convention, and I think we shouldn't break the expectation.

ParadaCarleton commented 3 years ago

Makes sense then if other places use it, I think. Mostly I've been confused by this a couple times because of the default assumption that things are in snake case, but if the functions are in squash case everywhere else, breaking that convention would cause more trouble than it's worth.