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

Dave Seidel <[email protected]> Fri, 31 Oct 2025 07:25:22 -0400
Newsgroups gmane.comp.audio.csound.devel
Message-ID <CAMnrweAs3ttFiRz=gHDtM0y-8Lx8FrzJ=qAVf8Ua2CqqbZ5AqA@mail.gmail.com>
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...
>