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

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