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

Below is a list of opcode names that are not strictly flatten case. I
propose the following:

- the ATS, K35, OSC one remain.
- the zdf opcodes join the aforementioned ones can also use uppercase,
e.g, ZDF1pole
- all other opcodes become flattened case, e.g. arduinoreadf, serialwritei,
turnoff2_i

Does this sound Ok? If so I will start creating aliases. I can also make a
PR for the manual so we can reduce people's exposure to the old
inconsistencies.

ATSadd

ATSaddnz

ATSbufread

ATScross

ATSinfo

ATSinterpread

ATSpartialtap

ATSread

ATSreadnz

ATSsinnoi

K35_hpf

K35_lpf

MixerClear

MixerGetLevel

MixerReceive

MixerSend

MixerSetLevel

MixerSetLevel_i

OSCbundle

OSCcount

OSCinit

OSCinitM

OSClisten

OSCraw

OSCsend

OSCsend_lo

S

arduinoRead

arduinoReadF

arduinoStart

arduinoStop

chn_S

chn_a

chn_k

cntCreate

cntCycles

cntDelete

cntDelete_i

cntRead

cntReset

cntState

count_i

diode_ladder

event_i

genarray_i

loop_ge

loop_gt

loop_le

loop_lt

maparray_i

max_k

midiout_i

nchnls_hw

print_type

printf_i

sc_lag

sc_lagud

sc_phasor

sc_trig

scoreline_i

serialBegin

serialEnd

serialFlush

serialPrint

serialRead

serialWrite

serialWrite_i

slicearray_i

sliderKawai

system_i

tab_i

tabw_i

trigExpseg

trigLinseg

trim_i

turnoff2_i

vadd_i

vaddv_i

vcopy_i

vdel_k

vdivv_i

vexp_i

vexpv_i

vmult_i

vmultv_i

vpow_i

vpowv_i

vsubv_i

zdf_1pole

zdf_1pole_mode

zdf_2pole

zdf_2pole_mode

zdf_ladder

On Sun, 2 Nov 2025 at 11:29, joachim heintz <[email protected]> wrote:

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