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