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

plus one for what you say about tipping the hat ... =)

On 31/10/2025 23:53, Rory Walsh wrote:
> We also have shedkwhen and ftsamplebank, which are also ok, I think. I 
> think if we introduce snake case, or any other convention, we need to go 
> all in. Snake case should add an underscore between each word. Following 
> such a scheme would lead to hundreds of opcodes being renamed, e.g., 
> ft_len, butter_lp, moog_ladder, pd_half, etc. I'm not against it, but I 
> think it must be a complete buy in. Otherwise we end up with a slightly 
> better system, but one that retains some strange inconsistencies.
> 
> I have to tip my hat to the core developers at this stage. This 
> conversation wouldn't be happening if they hadn't spent so much time 
> cleaning up the core system and updating/rewriting the parser. It's a 
> great place we are in now! ☺️
> 
> On Fri 31 Oct 2025, 17:17 joachim heintz, <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>     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]
>     <mailto:[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]
>     <mailto:[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]
>     <mailto:[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...
>