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