I’m loosely familiar with R. Martin’s universe of clean-code-books. 
As someone with a sw-engineering background, myself, I truely value, whenever I see stuff like this applied, in large sw-codebases. BUT, also, I totally empathize with the mathematician, who is used to having a very distinct set of short symbols for just a handful of (arbitrarily complex) parameters or operators, with (usually) a very well-defined meaning, in their particular field.
This totally opposes the sw-engineering-approach to name things in a way, where their meaning is transported explicitly by the name of those “things”.
But to answer your question, directly, I’m only aware of this: Style Guide · The Julia Language. But / and I would also like to recommend, in addition, to not worry about those (overall sensible / generic) conventions, all that much - for those parts of any piece of software, you’re coding, where one would find a (more-or-less) 1:1 - correspondence between “things” in your code and “things” in some concise notation, being used in papers, etc.
Personally, when I had to make that choice (i.e. which kind of convention to violate, basically), I usually adhered to (language-specific) sw-engineering-conventions for those parts, where code deals more with technicalities of sw (which is often a larger portion) and switch to a concise mathematical set of names, for the (often smaller portion), where the actual core of some mathematical notion is being expressed. Julia offers a whole universe, with unicode-support (for “things” named ϵ, Γ, Δ, ∇, …). If I was writing code, which would likely only be interesting to people, familiar with LateΧ and of a specific field, where “things” have concise names, noone could hold me back, from using those, for those core-parts (Edit: Especially, when that enables me to code a complicated formula in one line, as opposed to splitting it over multiple lines of code, just cause engineering-conventions would force me to assign long names to “things”).