3 ms·

When I see things like this: setcfg({'framework': 'React'}) I immediately think to myself that the designer of the API either (a) values tiny function nam

When I see things like this: setcfg({'framework': 'React'}) I immediately think to myself that the designer of the API either (a) values tiny function names over understandable ones, or (b) hasn't given naming enough thought to be consistent. Either way, it's not a good sign and turns me off from investigating further.

whichdan 7y ago
https://github.com/peterluhub/xsm/blob/master/xsm.js https://github.com/peterluhub/xsm/blob/master/xsm.js The package only exposes 9 functions, and the naming is mostly consistent. There's no benefit to publicly nitpicking function names in something with such a small API.
- rat9988 7y ago
  Honestly, no need to put much thought in gp's comment. He just wants to show off that he is an experienced engineer that values good code and readability. Edit: for those who disagree and downvote. Not only gp's comment doesn't adress the core issue and is a direct attack to the developer, but it cannot even be accepted as valid and helpful criticism. His point b says that it is possible that the developer doesn't value consistency, while his point a says he might be consistent with short naming. These remarks make it look more like random possible remark than ones that are really specific about this project.
mythz 7y ago
Whilst I'm not a fan of the name, I'm more discouraged that it needs to specify a fx at all which suggests that the library hasn't come up with a generic solution for all fx's but rather a library of quirks to abstract over a limited set of fx's. Since it only has hard-coded support for 3 frameworks, there's no benefit to using magic strings, it would be preferable to use a typed API like: XSM.useReact({ ... }) Where you can provide fx-specific options for each fx it supports. It also hides all the config options available behind a generic API which you have to dive into the impl [1] to see what options are available and what args each config option supports. Everyone would be far better off bringing all config options to the API Surface area, you could easily type-check all options in TypeScript which ensures correct usage of the API and let you know of any additions/removal or breaking changes. [1] https://github.com/peterluhub/xsm/blob/master/xsm.js https://github.com/peterluhub/xsm/blob/master/xsm.js
nulagrithom 7y ago
It's short for set configuration. Maybe that just escaped you from some reason, but I would think it's perfectly understandable for just about anyone. Curious if anyone else here had a hard time parsing it...
peterluhub 7y ago
I have changed setcfg to setup and make setcfg an alias of setup. Not that I agree with you, but I do want people like you take a closer look. We must not judge something by its name or look, rather must judge on its merits.

whichdan 7y ago

https://github.com/peterluhub/xsm/blob/master/xsm.js https://github.com/peterluhub/xsm/blob/master/xsm.js The package only exposes 9 functions, and the naming is mostly consistent. There's no benefit to publicly nitpicking function names in something with such a small API.

rat9988 7y ago
Honestly, no need to put much thought in gp's comment. He just wants to show off that he is an experienced engineer that values good code and readability. Edit: for those who disagree and downvote. Not only gp's comment doesn't adress the core issue and is a direct attack to the developer, but it cannot even be accepted as valid and helpful criticism. His point b says that it is possible that the developer doesn't value consistency, while his point a says he might be consistent with short naming. These remarks make it look more like random possible remark than ones that are really specific about this project.

mythz 7y ago

Whilst I'm not a fan of the name, I'm more discouraged that it needs to specify a fx at all which suggests that the library hasn't come up with a generic solution for all fx's but rather a library of quirks to abstract over a limited set of fx's. Since it only has hard-coded support for 3 frameworks, there's no benefit to using magic strings, it would be preferable to use a typed API like: XSM.useReact({ ... }) Where you can provide fx-specific options for each fx it supports. It also hides all the config options available behind a generic API which you have to dive into the impl [1] to see what options are available and what args each config option supports. Everyone would be far better off bringing all config options to the API Surface area, you could easily type-check all options in TypeScript which ensures correct usage of the API and let you know of any additions/removal or breaking changes. [1] https://github.com/peterluhub/xsm/blob/master/xsm.js https://github.com/peterluhub/xsm/blob/master/xsm.js

nulagrithom 7y ago

It's short for set configuration. Maybe that just escaped you from some reason, but I would think it's perfectly understandable for just about anyone. Curious if anyone else here had a hard time parsing it...

peterluhub 7y ago

I have changed setcfg to setup and make setcfg an alias of setup. Not that I agree with you, but I do want people like you take a closer look. We must not judge something by its name or look, rather must judge on its merits.