Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I'm designing a library that binds to html elements on a page. In this particular case the input[type='checkbox'] will be checked if the likeItem property returns true and unchecked if the likeItem property returns false. What's the best practice for naming properties?
input { check: likeItem }
or
input { checked: likeItem }
This would also apply to other things like enable/enabled, disable/disabled, etc.
For semantic reasons and best practice use checked.
input { checked: isTrue } will be processed after the input is checked. So, for me, I think checked get better this context.
This really depends on what you do if the property returns false. If the input happens to be checked, and you send input { checked: isFalse }, I would expect that the library will uncheck the checkbox - set it's checked property to false(even though the checked attribute in HTML doesn't uses present/absent and not true/false).
But if the input is checked, and you send input { check: isFalse }, I would expect that the library will not uncheck the checkbox, and that it'll remain checked! check is a verb, which means an action, so { check: isFalse } means either "call check with false"(which I don't think is the case here, since a function named check should not accept a boolean argument - if it does it should have been named setChecked or something) or "don't call check". So if the checkbox is unchecked sending { check: isFalse } will do nothing and the checkbox will remain unchecked, and if the checkbox is checked it'll still do nothing and the checkbox will remain checked. If you want to uncheck you should send input { uncheck: isTrue }.
