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

Rory Walsh <[email protected]> Fri, 31 Oct 2025 13:36:36 +0000
Newsgroups gmane.comp.audio.csound.devel
Message-ID <CAMJR=HO4VY9RVPvkQ3eebWQfPPqovVEDbcmc3PJ9_YBojd1O=w@mail.gmail.com>
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...
>>
>