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

I'm sure that's true. As I said, I don't have a strong preference, having
had to adapt to different standards a number times. I will support whatever
consensus emerges.

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...
>>>
>>