Open esilvia opened 6 years ago
Spaces in names is yuck. Other than that, I have no opinion.
Thanks Evon for sharing this conversation. Thanks @all for the comments and the input. Just to make my opinion known: I also think the naming of extra bytes is not part of the specifiaction. On the other hand it would be good to have an orientation how to name fields with a certain content. Therefore the Wiki seems to be a good place. About "good" names I think it is worth to avoid spaces in names when names come close to identifiers or tokens which are may also used in programming languages, databases and so on. As soon we list those names in a wiki it is not a very good argument to say "Is was like this in the past..." So I would prefer names in camel case or with "_" instead of a space.
Spaces in names is yuck. Other than that, I have no opinion.
I'm at JALBTCX this week discussing the LDP v2 that was developed in #117 and approaching publication. This includes updates to the ExtraBytes being used, and I'm trying to decide whether or not I should rename the ExtraByte fields in the v2 upgrade.
Can @abellgithub or anyone elaborate on "spaces in names is yuck"? I get that the dev community has historically avoided spaces like the plague (windows path errors, anyone?), but any sane language or library should be able to handle spaces in a char array, especially one that interacts with LAS which explicitly specifies that its char arrays are null-terminated.
Why would removing spaces be a need here? Are folks trying to use ExtraByte names as variable names or key values? Or is this not a need I should attempt to support?
My main reason to avoid spaces is that they mean you have to remember to quote or escape them any time you might want to use that name in a command line interface.
Kirk
On Thursday, November 30, 2023, Evon Silvia @.***> wrote:
Spaces in names is yuck. Other than that, I have no opinion.
I'm at JALBTCX this week discussing the LDP v2 that was developed in #117 https://github.com/ASPRSorg/LAS/issues/117 and approaching publication. This includes updates to the ExtraBytes being used, and I'm trying to decide whether or not I should rename the ExtraByte fields in the v2 upgrade.
Can @abellgithub https://github.com/abellgithub or anyone elaborate on "spaces in names is yuck"? I get that the dev community has historically avoided spaces like the plague (windows path errors, anyone?), but any sane language or library should be able to handle spaces in a char array, especially one that interacts with LAS which explicitly specifies that its char arrays are null-terminated.
Why would removing spaces be a need here? Are folks trying to use ExtraByte names as variable names or key values? Or is this not a need I should attempt to support?
— Reply to this email directly, view it on GitHub https://github.com/ASPRSorg/LAS/issues/37#issuecomment-1834564729, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA5B33KJL7GAVG6KUMDCYNTYHDY3RAVCNFSM4D36PXTKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBTGQ2TMNBXGI4Q . You are receiving this because you were mentioned.Message ID: @.***>
-- Sent from a mobile device subject to autocorrect errors.
My main reason to avoid spaces is that they mean you have to remember to quote or escape them any time you might want to use that name in a command line interface. Kirk
@kjwaters OH that makes total sense. I'll propose that change in the Bathy Working Group meeting tonight, if I get a chance.
We've discussed listing some standardized extrabytes either in the specification itself or a supplementary document. This would encourage their adoption by the community and formalize common extrabytes as a guideline to future implementations.
We need to figure out the following:
data_type
be formalized?Below is a link to what I think is a decent start to the standardized extrabytes. Once we get some agreement on a few of these I can start building a wiki page or contribute to Martin's pull request. Which one we do depends on the answer to the 4th question.
Standard ExtraBytes v1.docx