search

gonum / hdf5

hdf5 is a wrapper for the HDF5 library
BSD 3-Clause "New" or "Revised" License
131 stars 33 forks source link

all: moves to camel case naming #38

Open donkahlero opened 6 years ago

donkahlero commented 6 years ago

Hi guys, I had a stab at https://github.com/gonum/hdf5/issues/37 and renamed the variables. Took me a bit longer than expected as so many variables are affected and maybe I did not even catch them all...

Nevertheless, some points are still up for discussion and I hope we can discuss them as part of this PR:

What shall we do about the Datatype vs. DataType issue? I saw that @sbinet had once a stab at this. I still suggest that we move what is called Datatype to DataType as part of this PR and then rethink later if we want to move to what you said in https://github.com/gonum/hdf5/pull/9, @kortschak. The same goes for Dataspace which should maybe also be called DataSpace?

Id vs. ID. Right now I moved everything to Id, but I am not quite sure if ID is the better way. The go standard lib uses the prior while golint suggest the latter. Any opinion?

_go_types in h5t_types.go. Should we rename e.g. _go_int8_t to goInt8T?

ALL_CAPS_VARS as we have them in h5t_shim.go should stay as they are, right?

kortschak commented 6 years ago

This will answer some of your questions.

Data Type is two words, so it can be made DataType, though do think Type is better.

Dataspace is a single compound word, so it should remain (English is weird).

ID should be ID - as described in the wiki.

For the reflect.Type values, s/_go_(.*)_t/\1Type/g.

It seems reasonable to keep the T_ vars and consts as they are.

donkahlero commented 6 years ago

Good comments, @kortschak! Thx!

I found one more thing that I really dislike. We have some mix-up in the test cases when it comes to fname vs. fName. I suggest we move everything to the latter?

Furthermore, I suggest that we also rename dsname in the test-cases to dsName?