search

microsoft / yardl

Tooling for streaming instrument data
https://microsoft.github.io/yardl/
MIT License
29 stars 5 forks source link

confusing naming of functions/members #93

Open KrisThielemans opened 8 months ago

KrisThielemans commented 8 months ago

There is some renaming of members going on in the generated code, but it is not consistent

ScannerInformation: !record
  fields:
    tofBinEdges: !array
  computedFields:
    numberOfTOFBins: size(tofBinEdges)-1

leads to tof_bin_edges member in both C++ and Python, but NumberOfTOFBins() (note capital N) in C++ while number_of_tof_bins() in Python

Personally I'd try to avoid any renaming, but maybe that is difficult when covering multiple languages. We could enforce naming in the yardl model?

johnstairs commented 8 months ago

The idea was to follow (parts of) the Google C++ style guide. But we could also do snake_case everywhere like the standard library.

johnstairs commented 7 months ago

@KrisThielemans, would you support adopting snake_case everywhere for C++ like the standard library?

KrisThielemans commented 7 months ago

My personal preference is to keep the names as per the yardl file. Why are we renaming this at all? (are there tools that can parse JSON and enforce naming conventions?)

If we have to rename, then it has to be consistent within language (which I suppose we are now), and I'd try to make it consistent between languages (which we are now). snake_case is fine for me. (In STIR/SIRF, we use CamelCase for classes, and snake_case for methods/variables, but any convention is fine of course)