Re: [Csnd-dev] language cleanup...

We also have shedkwhen and ftsamplebank, which are also ok, I think. I
think if we introduce snake case, or any other convention, we need to go
all in. Snake case should add an underscore between each word. Following
such a scheme would lead to hundreds of opcodes being renamed, e.g.,
ft_len, butter_lp, moog_ladder, pd_half, etc. I'm not against it, but I
think it must be a complete buy in. Otherwise we end up with a slightly
better system, but one that retains some strange inconsistencies.

I have to tip my hat to the core developers at this stage. This
conversation wouldn't be happening if they hadn't spent so much time
cleaning up the core system and updating/rewriting the parser. It's a great
place we are in now! ☺️

On Fri 31 Oct 2025, 17:17 joachim heintz, <[email protected]> wrote:

> i totally agree with rory about the importance of such a cleanup.
> as to lowercase or snake_case, i'd say:
> - in most cases we can keep lowercase
> - if the readability is hurted, underscores can be added.
>
> for instance: ampdb, mtof, bformenc, butbp, pvsynth are good.
> osclisten even is ok, i think.
>
> just to note that for the german keyboard the underscore is not as
> elegant as for the english one.
>
> On 31/10/2025 16:46, Steven Yi wrote:
> > I generally prefer snake_case myself these days for Csound coding.
> > Perhaps it's because my brain switches somewhat to C conventions when
> > I get to time with Csound. Some of the coding in Csound for snake_case
> > has to do with the lack of namespaces and import system, so families
> > of code are denoted with things like zdf_ladder, zdf_2pole, etc. which
> > might be implemented as zdf::ladder or zdf::2pole in other languages.
> >
> > On Fri, Oct 31, 2025 at 9:36 AM Rory Walsh <[email protected]> wrote:
> >>
> >> I agree that they are more readable, but I think switching to
> lowerCamelCase or snake_case would be a huge undertaking. I'm interested to
> hear what others think.
> >>
> >> On Fri, 31 Oct 2025 at 11:30, Dave Seidel <[email protected]>
> wrote:
> >>>
> >>> As a user, more consistency in naming would be very nice. I don't have
> a strong preference for any particular form, having had to adapt to all of
> them at one time or another over the course of my erstwhile career, but I
> guess I have somewhat of a reference for either lowerCamelCase or
> snake_case, as both offer better readability (IMO) than flatcase.
> >>>
> >>> - Dave
> >>>
> >>> On Fri, Oct 31, 2025 at 5:47 AM Rory Walsh <[email protected]> wrote:
> >>>>
> >>>> It would be nice to iron out some inconsistencies in the language
> before releasing Csound 7. One of these is the scattershot approach to
> opcode names. Right now we have lowerCamelCase, snake_case, snake+camel
> case, and the traditional flatcase. It would be nice to choose one, create
> aliases for all existing opcodes (if this is doable that is), and mark the
> others as deprecated.
> >>>>
> >>>> Another thing that came up yesterday in a different discussion is the
> number of version 2 opcodes, diskin2, flooper2, etc. We can now easily
> overload opcodes, which gives us the option of removing the version 2
> variants and overloading the originals instead, although we’d need to audit
> the opcodes first to see if they all have different parameter signatures.
> >>>>
> >>>> Something else that was mentioned was the use of uppercase for
> booleans. bi, bk, booli, boolk, etc., all seem like better fits. Another
> long-standing inconsistency is the uppercase S for strings. If I’m not
> mistaken, we could finally change this to :s and keep it in line with other
> variable types.
> >>>>
> >>>> Consistency has a real impact on usability and teaching, making code
> easier to read and maintain. I think it would be great to try to address
> this now. I don't mind doing most of the donkey work. We just need to come
> to some kind of agreement.
> >>>>
> >>>> Rory.
> >>>>
> >>>>
> >>>> p.s. I'm posting this to the dev-list, but I think this is something
> the end-users might also like to have some input on...
>