To not forget our Sonar service in the new year, I looked at some of the newest issues it was identifying this morning and found the following with regards to our message keys:
In most places it looks like we break the SonarWay rule by including hyphens(-) in our message keys. This minor rule suggests that these are more complex / less readable than they should be. A hyphen example is in-fact in our style guide, so it’s certainly reasonable that we have them. In the past sprint we’ve established a common Message pattern that we’d like Services to use and the UI of course also has message strings. In future sprints we’ll be ensuring we have all hard-coded messages converted to translatable messages for our 3.0 release at the end of February, so now’s a good time to make a quick decision on this SonarQube rule.
The options you can vote on:
Keep our style guide, hyphens and all. This would have no change to existing code and we’d disable this SonarWay rule.
Change our message keys to conform to the SonarWay rule, and update our style guide. If we did this, we’d correct nearly 1 day of (minor) tech debt across all the Services according to SonarQube.
Let me know your thoughts on this minor issue in a reply here. And if you haven’t checked out our SonarQube or looked at the Technical Debt page recently, please do so.
In other projects I’ve always seen dots, not hyphens, in message keys.
(I would vote for changing to dots, though I have no opinion about how much of a priority this is. If changing allows sonar to catch hardcoded messages, that would be great!)
To not forget our Sonar service in the new year, I looked at some of the newest issues it was identifying this morning and found the following with regards to our message keys:
In most places it looks like we break the SonarWay rule by including hyphens(-) in our message keys. This minor rule suggests that these are more complex / less readable than they should be. A hyphen example is in-fact in our style guide, so it’s certainly reasonable that we have them. In the past sprint we’ve established a common Message pattern that we’d like Services to use and the UI of course also has message strings. In future sprints we’ll be ensuring we have all hard-coded messages converted to translatable messages for our 3.0 release at the end of February, so now’s a good time to make a quick decision on this SonarQube rule.
The options you can vote on:
Keep our style guide, hyphens and all. This would have no change to existing code and we’d disable this SonarWay rule.
Change our message keys to conform to the SonarWay rule, and update our style guide. If we did this, we’d correct nearly 1 day of (minor) tech debt across all the Services according to SonarQube.
Let me know your thoughts on this minor issue in a reply here. And if you haven’t checked out our SonarQube or looked at the Technical Debt page recently, please do so.
–
You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.
To not forget our Sonar service in the new year, I looked at some of the newest issues it was identifying this morning and found the following with regards to our message keys:
In most places it looks like we break the SonarWay rule by including hyphens(-) in our message keys. This minor rule suggests that these are more complex / less readable than they should be. A hyphen example is in-fact in our
style guide , so it’s certainly reasonable that we have them. In the past sprint we’ve established a common Message pattern that we’d like Services to use and the UI of course also has message strings. In future sprints we’ll be ensuring we have all hard-coded messages converted to translatable messages for our 3.0 release at the end of February, so now’s a good time to make a quick decision on this SonarQube rule.
The options you can vote on:
Keep our style guide, hyphens and all. This would have no change to existing code and we’d disable this
SonarWay rule.
Change our message keys to conform to the SonarWay rule, and update our
style guide. If we did this, we’d correct nearly 1 day of (minor) tech debt across all the Services according to SonarQube.
Let me know your thoughts on this minor issue in a reply here. And if you haven’t checked out our SonarQube or looked at the Technical Debt page recently, please do so.
–
You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.
To not forget our Sonar service in the new year, I looked at some of the newest issues it was identifying this morning and found the following with regards to our message keys:
In most places it looks like we break the SonarWay rule by including hyphens(-) in our message keys. This minor rule suggests that these are more complex / less readable than they should be. A hyphen example is in-fact in our
style guide , so it’s certainly reasonable that we have them. In the past sprint we’ve established a common Message pattern that we’d like Services to use and the UI of course also has message strings. In future sprints we’ll be ensuring we have all hard-coded messages converted to translatable messages for our 3.0 release at the end of February, so now’s a good time to make a quick decision on this SonarQube rule.
The options you can vote on:
Keep our style guide, hyphens and all. This would have no change to existing code and we’d disable this
SonarWay rule.
Change our message keys to conform to the SonarWay rule, and update our
style guide. If we did this, we’d correct nearly 1 day of (minor) tech debt across all the Services according to SonarQube.
Let me know your thoughts on this minor issue in a reply here. And if you haven’t checked out our SonarQube or looked at the Technical Debt page recently, please do so.
–
You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.
I vote for option 2, changing to the dot notation (no hyphens).
FWIW, I had looked into what it might take to customize this Sonar rule (to allow hyphens as our current style guide does). It seemed like a real pain to create our own rule. There is not an off-the-shelf rule with a regex that allows the hyphens, and there was not a setting where we could just re-configure the regex. We are currently using the SonarWay ruleset, and we haven’t modified it at all. Modifying it means we would have to “fork” the ruleset to start making our own local modifications. But by “forking” the ruleset it appeared as though we would always have to manually do effort to incorporate the new SonarWay default rules as those evolve over time. If I understood Sonar’s docs correctly, I think we’d be better off changing our style guide to fit the industry convention rather than forking the ruleset and going through all that trouble. Phew!
In other projects I’ve always seen dots, not hyphens, in message keys.
(I would vote for changing to dots, though I have no opinion about how much of a priority this is. If changing allows sonar to catch hardcoded messages, that would be great!)
To not forget our Sonar service in the new year, I looked at some of the newest issues it was identifying this morning and found the following with regards to our message keys:
In most places it looks like we break the SonarWay rule by including hyphens(-) in our message keys. This minor rule suggests that these are more complex / less readable than they should be. A hyphen example is in-fact in our
style guide , so it’s certainly reasonable that we have them. In the past sprint we’ve established a common Message pattern that we’d like Services to use and the UI of course also has message strings. In future sprints we’ll be ensuring we have all hard-coded messages converted to translatable messages for our 3.0 release at the end of February, so now’s a good time to make a quick decision on this SonarQube rule.
The options you can vote on:
Keep our style guide, hyphens and all. This would have no change to existing code and we’d disable this
SonarWay rule.
Change our message keys to conform to the SonarWay rule, and update our
style guide. If we did this, we’d correct nearly 1 day of (minor) tech debt across all the Services according to SonarQube.
Let me know your thoughts on this minor issue in a reply here. And if you haven’t checked out our SonarQube or looked at the Technical Debt page recently, please do so.
–
You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.
I vote for option 2, changing to the dot notation (no hyphens).
FWIW, I had looked into what it might take to customize this Sonar rule (to allow hyphens as our current style guide does). It seemed like a real pain to create our own rule. There is not an off-the-shelf rule with a regex that allows the hyphens, and there was not a setting where we could just re-configure the regex. We are currently using the SonarWay ruleset, and we haven’t modified it at all. Modifying it means we would have to “fork” the ruleset to start making our own local modifications. But by “forking” the ruleset it appeared as though we would always have to manually do effort to incorporate the new SonarWay default rules as those evolve over time. If I understood Sonar’s docs correctly, I think we’d be better off changing our style guide to fit the industry convention rather than forking the ruleset and going through all that trouble. Phew!
In other projects I’ve always seen dots, not hyphens, in message keys.
(I would vote for changing to dots, though I have no opinion about how much of a priority this is. If changing allows sonar to catch hardcoded messages, that would be great!)
To not forget our Sonar service in the new year, I looked at some of the newest issues it was identifying this morning and found the following with regards to our message keys:
In most places it looks like we break the SonarWay rule by including hyphens(-) in our message keys. This minor rule suggests that these are more complex / less readable than they should be. A hyphen example is in-fact in our
style guide , so it’s certainly reasonable that we have them. In the past sprint we’ve established a common Message pattern that we’d like Services to use and the UI of course also has message strings. In future sprints we’ll be ensuring we have all hard-coded messages converted to translatable messages for our 3.0 release at the end of February, so now’s a good time to make a quick decision on this SonarQube rule.
The options you can vote on:
Keep our style guide, hyphens and all. This would have no change to existing code and we’d disable this
SonarWay rule.
Change our message keys to conform to the SonarWay rule, and update our
style guide. If we did this, we’d correct nearly 1 day of (minor) tech debt across all the Services according to SonarQube.
Let me know your thoughts on this minor issue in a reply here. And if you haven’t checked out our SonarQube or looked at the Technical Debt page recently, please do so.
–
You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.
I'm OK with both options. My personal preference is no hyphens and camelCase, rather than multiple dots. I think keys with many dots are a little less readable and with less dots we can create a nice, hierarchical/logical structure.
Kind regards,
Sebastian.
* 2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: +1.510.410.0020
SKYPE: nickdotreid
[www.villagereach.org](http://www.villagereach.org/)
From:
on behalf of Brandon Bowersox-Johnson Wednesday, January 4, 2017 3:15:43 PM OpenLMIS Dev Re: [openlmis-dev] SonarQube Rule: Message Key guidelines
I vote for option 2, changing to the dot notation (no hyphens).
FWIW, I had looked into what it might take to customize this Sonar rule (to allow hyphens as our current style guide does). It seemed like a real pain to create our own rule. There is not an off-the-shelf rule with a regex that allows the hyphens, and there was not a setting where we could just re-configure the regex. We are currently using the SonarWay ruleset, and we haven’t modified it at all. Modifying it means we would have to “fork” the ruleset to start making our own local modifications. But by “forking” the ruleset it appeared as though we would always have to manually do effort to incorporate the new SonarWay default rules as those evolve over time. If I understood Sonar’s docs correctly, I think we’d be better off changing our style guide to fit the industry convention rather than forking the ruleset and going through all that trouble. Phew!
-Brandon
**From:
**
on behalf of Josh Zamor Wednesday, January 4, 2017 at 12:41 PM Darius Jazayeri OpenLMIS Dev Re: [openlmis-dev] SonarQube Rule: Message Key guidelines
Whoops, correction. Dot notation would yield something more like:
On Jan 4, 2017, at 10:59 AM, Darius Jazayeri <djazayer@thoughtworks.com > wrote:
In other projects I've always seen dots, not hyphens, in message keys.
(I would vote for changing to dots, though I have no opinion about how much of a priority this is. If changing allows sonar to catch hardcoded messages, that would be great!)
-Darius
On Wed, Jan 4, 2017 at 9:26 AM, Josh Zamor <josh.zamor@villagereach.org > wrote:
To not forget our Sonar service in the new year, I looked at some of the newest issues it was identifying this morning and found the following with regards to our message keys:
[http://sonar.openlmis.org/coding_rules#rule_key=jproperties%3Akey-naming-convention](http://sonar.openlmis.org/coding_rules#rule_key=jproperties%3Akey-naming-convention)
In most places it looks like we break the SonarWay rule by including hyphens(-) in our message keys. This minor rule suggests that these are more complex / less readable than they should be. A hyphen example is in-fact in our [
style guide](https://github.com/OpenLMIS/openlmis-template-service/blob/master/STYLE-GUIDE.md#i18n-naming-conventions) , so it's certainly reasonable that we have them. In the past sprint we've established a common Message pattern that we'd like Services to use and the UI of course also has message strings. In future sprints we'll be ensuring we have all hard-coded messages converted to translatable messages for our 3.0 release at the end of February, so now's a good time to make a quick decision on this SonarQube rule.
The options you can vote on:
Keep our style guide, hyphens and all. This would have no change to existing code and we'd disable this [
SonarWay rule](http://sonar.openlmis.org/coding_rules#rule_key=jproperties%3Akey-naming-convention).
Change our message keys to conform to the SonarWay rule, and update our [
style guide](https://github.com/OpenLMIS/openlmis-template-service/blob/master/STYLE-GUIDE.md) . If we did this, we'd correct nearly 1 day of (minor) tech debt across all the Services according to SonarQube.
Let me know your thoughts on this minor issue in a reply here. And if you haven't checked out our [SonarQube](http://sonar.openlmis.org/)
or looked at the [Technical Debt](https://openlmis.atlassian.net/wiki/x/YQAOBg)
page recently, please do so.
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to
openlmis-dev@googlegroups.com.
To view this discussion on the web visit [https://groups.google.com/d/msgid/openlmis-dev/4FA428FF-4962-4AED-92B4-4D5F0D2FB04A%40villagereach.org](https://groups.google.com/d/msgid/openlmis-dev/4FA428FF-4962-4AED-92B4-4D5F0D2FB04A%40villagereach.org?utm_medium=email&utm_source=footer).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to
openlmis-dev@googlegroups.com.
To view this discussion on the web visit [https://groups.google.com/d/msgid/openlmis-dev/4D9B138B-C645-40BE-9943-486080DDE032%40villagereach.org](https://groups.google.com/d/msgid/openlmis-dev/4D9B138B-C645-40BE-9943-486080DDE032%40villagereach.org?utm_medium=email&utm_source=footer).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to
openlmis-dev@googlegroups.com.
To view this discussion on the web visit [https://groups.google.com/d/msgid/openlmis-dev/81D287F2-3141-4BA5-8740-AE16892BE1D7%40villagereach.org](https://groups.google.com/d/msgid/openlmis-dev/81D287F2-3141-4BA5-8740-AE16892BE1D7%40villagereach.org?utm_medium=email&utm_source=footer).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [https://groups.google.com/d/msgid/openlmis-dev/BN6PR02MB2625745297B71EEDC444134794600%40BN6PR02MB2625.namprd02.prod.outlook.com](https://groups.google.com/d/msgid/openlmis-dev/BN6PR02MB2625745297B71EEDC444134794600%40BN6PR02MB2625.namprd02.prod.outlook.com?utm_medium=email&utm_source=footer).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
The reason why I prefer using hyphens over simply dots is so that dots are not being used for multiple purposes (categorization AND multi-word phrasing). With something like referencedata.error.product.wrong.dispensing.units; we are having dots do double duty, which makes the key harder to understand. This is why we had dots for categorization and hyphens for multiple words in a phrase. We could try to solve that using camelCase instead of hyphens, but I would prefer not to simply use dots.
Shalom,
Chongsun
–
There are 10 kinds of people in this world; those who understand binary, and those who don’t.
From: on behalf of Brandon Bowersox-Johnson Wednesday, January 4, 2017 3:15:43 PM OpenLMIS Dev Re: [openlmis-dev] SonarQube Rule: Message Key guidelines
I vote for option 2, changing to the dot notation (no hyphens).
FWIW, I had looked into what it might take to customize this Sonar rule (to allow hyphens as our current style guide does). It seemed like a real pain to create our own rule. There is not an off-the-shelf rule with a regex that allows the hyphens, and there was not a setting where we could just re-configure the regex. We are currently using the SonarWay ruleset, and we haven’t modified it at all. Modifying it means we would have to “fork” the ruleset to start making our own local modifications. But by “forking” the ruleset it appeared as though we would always have to manually do effort to incorporate the new SonarWay default rules as those evolve over time. If I understood Sonar’s docs correctly, I think we’d be better off changing our style guide to fit the industry convention rather than forking the ruleset and going through all that trouble. Phew!
-Brandon
**From: ** on behalf of Josh Zamor Wednesday, January 4, 2017 at 12:41 PM Darius Jazayeri OpenLMIS Dev Re: [openlmis-dev] SonarQube Rule: Message Key guidelines
Whoops, correction. Dot notation would yield something more like:
In other projects I’ve always seen dots, not hyphens, in message keys.
(I would vote for changing to dots, though I have no opinion about how much of a priority this is. If changing allows sonar to catch hardcoded messages, that would be great!)
To not forget our Sonar service in the new year, I looked at some of the newest issues it was identifying this morning and found the following with regards to our message keys:
In most places it looks like we break the SonarWay rule by including hyphens(-) in our message keys. This minor rule suggests that these are more complex / less readable than they should be. A hyphen example is in-fact in our style guide , so it’s certainly reasonable that we have them. In the past sprint we’ve established a common Message pattern that we’d like Services to use and the UI of course also has message strings. In future sprints we’ll be ensuring we have all hard-coded messages converted to translatable messages for our 3.0 release at the end of February, so now’s a good time to make a quick decision on this SonarQube rule.
The options you can vote on:
Keep our style guide, hyphens and all. This would have no change to existing code and we’d disable this SonarWay rule.
Change our message keys to conform to the SonarWay rule, and update our style guide. If we did this, we’d correct nearly 1 day of (minor) tech debt across all the Services according to SonarQube.
Let me know your thoughts on this minor issue in a reply here. And if you haven’t checked out ourSonarQube or looked at the Technical Debt page recently, please do so.
–
You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.
The usual standard is that dots are not supposed to replace spaces, but they’re supposed to indicate a hierarchy of messages. (Camel-case is how you replace spaces in Java land.)
This instead (assuming we’re grouping all the product-related errors under referencedata.product):
referencedata.product.error.wrongDispensingUnits
Or else this could be
referencedata.product.dispensingUnits.error (if this is the only applicable error)
referencedata.product.dispensingUnits.error.wrong (if you also need parallel-level errors like "required")
(For referencedata it’s pretty clean to approach it as service.entity.property[.error].messageCodeInCamelCase but this may not work as nicely for more workflow-oriented services.)
Sebastian, when you said “less dots” did you mean “some dots but not as many”? And how would you suggest we do this example?
I’m OK with both options. My personal preference is no hyphens and camelCase, rather than multiple dots. I think keys with many dots are a little less readable and with less dots we can create a nice, hierarchical/logical structure.
I vote for option 2, changing to the dot notation (no hyphens).
FWIW, I had looked into what it might take to customize this Sonar rule (to allow hyphens as our current style guide does). It seemed like a real pain to create our own rule. There is not an off-the-shelf rule with a regex that allows the hyphens, and there was not a setting where we could just re-configure the regex. We are currently using the SonarWay ruleset, and we haven’t modified it at all. Modifying it means we would have to “fork” the ruleset to start making our own local modifications. But by “forking” the ruleset it appeared as though we would always have to manually do effort to incorporate the new SonarWay default rules as those evolve over time. If I understood Sonar’s docs correctly, I think we’d be better off changing our style guide to fit the industry convention rather than forking the ruleset and going through all that trouble. Phew!
In other projects I’ve always seen dots, not hyphens, in message keys.
(I would vote for changing to dots, though I have no opinion about how much of a priority this is. If changing allows sonar to catch hardcoded messages, that would be great!)
To not forget our Sonar service in the new year, I looked at some of the newest issues it was identifying this morning and found the following with regards to our message keys:
In most places it looks like we break the SonarWay rule by including hyphens(-) in our message keys. This minor rule suggests that these are more complex / less readable than they should be. A hyphen example is in-fact in our style guide , so it’s certainly reasonable that we have them. In the past sprint we’ve established a common Message pattern that we’d like Services to use and the UI of course also has message strings. In future sprints we’ll be ensuring we have all hard-coded messages converted to translatable messages for our 3.0 release at the end of February, so now’s a good time to make a quick decision on this SonarQube rule.
The options you can vote on:
Keep our style guide, hyphens and all. This would have no change to existing code and we’d disable this SonarWay rule.
Change our message keys to conform to the SonarWay rule, and update our style guide. If we did this, we’d correct nearly 1 day of (minor) tech debt across all the Services according to SonarQube.
Let me know your thoughts on this minor issue in a reply here. And if you haven’t checked out ourSonarQube or looked at the Technical Debt page recently, please do so.
–
You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.
The reason why I prefer using hyphens over simply dots is so that dots are not being used for multiple purposes (categorization AND multi-word phrasing). With something like referencedata.error.product. wrong.dispensing.units; we are having dots do double duty, which makes the key harder to understand. This is why we had dots for categorization and hyphens for multiple words in a phrase. We could try to solve that using camelCase instead of hyphens, but I would prefer not to simply use dots.
–
You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.
The usual standard is that dots are not supposed to replace spaces, but they're supposed to indicate a hierarchy of messages. (Camel-case is how you replace spaces in Java land.)
This instead (assuming we're grouping all the product-related errors under referencedata.product):
referencedata.product.error.wrongDispensingUnits
Or else this could be
referencedata.product.dispensingUnits. error (if this is the only applicable error)
referencedata.product.dispensingUnits. error.wrong (if you also need parallel-level errors like "required")
(For referencedata it's pretty clean to approach it as service.entity.property[.error].messageCodeInCamelCase but this may not work as nicely for more workflow-oriented services.)
Sebastian, when you said "less dots" did you mean "some dots but not as many"? And how would you suggest we do this example?
-Darius
On Mon, Jan 9, 2017 at 3:13 PM, Chongsun Ahn <chongsun.ahn@villagereach.org>
wrote:
Hey all,
Shalom,
Chongsun
--
There are 10 kinds of people in this world; those who understand binary, and those who don’t.
Connect on **[Facebook](https://www.facebook.com/pages/VillageReach/103205113922)****,** **[Twitter](https://twitter.com/VillageReach)**** **and our **[Blog](http://villagereach.org/see-our-blog/thoughts-from-the-last-mile/)**
On Jan 9, 2017, at 3:02 PM, Sebastian Brudziński <sbrudzinski@soldevelo.com > wrote:
Hello.
I'm OK with both options. My personal preference is no hyphens and camelCase, rather than multiple dots. I think keys with many dots are a little less readable and with less dots we can create a nice, hierarchical/logical structure.
Kind regards,
Sebastian.
Sebastian Brudziński
Software Developer / Team Leader
SolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41Al. Zwycięstwa 96/9881-451, Gdynia
[http://www.soldevelo.com](http://www.soldevelo.com/)
Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN
On 05.01.2017 14:55, Nick Reid wrote:
I’ll second option 2
Question: Are we standardizing on using multiple dots or camelCase? — I'd like to get this decision made so the UI work gets done once and not twice
**Sent:** Wednesday, January 4, 2017 3:15:43 PM
**To:** OpenLMIS Dev
**Subject:** Re: [openlmis-dev] SonarQube Rule: Message Key guidelines
I vote for option 2, changing to the dot notation (no hyphens).
FWIW, I had looked into what it might take to customize this Sonar rule (to allow hyphens as our current style guide does). It seemed like a real pain to create our own rule. There is not an off-the-shelf rule with a regex that allows the hyphens, and there was not a setting where we could just re-configure the regex. We are currently using the SonarWay ruleset, and we haven’t modified it at all. Modifying it means we would have to “fork” the ruleset to start making our own local modifications. But by “forking” the ruleset it appeared as though we would always have to manually do effort to incorporate the new SonarWay default rules as those evolve over time. If I understood Sonar’s docs correctly, I think we’d be better off changing our style guide to fit the industry convention rather than forking the ruleset and going through all that trouble. Phew!
On Jan 4, 2017, at 10:59 AM, Darius Jazayeri < > wrote:
In other projects I've always seen dots, not hyphens, in message keys.
(I would vote for changing to dots, though I have no opinion about how much of a priority this is. If changing allows sonar to catch hardcoded messages, that would be great!)
-Darius
On Wed, Jan 4, 2017 at 9:26 AM, Josh Zamor <> wrote:
To not forget our Sonar service in the new year, I looked at some of the newest issues it was identifying this morning and found the following with regards to our message keys:
[](http://sonar.openlmis.org/coding_rules#rule_key=jproperties%3Akey-naming-convention)
Keep our style guide, hyphens and all. This would have no change to existing code and we'd disable this [ SonarWay rule](http://sonar.openlmis.org/coding_rules#rule_key=jproperties%3Akey-naming-convention).
Change our message keys to conform to the SonarWay rule, and update our [ style guide](https://github.com/OpenLMIS/openlmis-template-service/blob/master/STYLE-GUIDE.md) . If we did this, we'd correct nearly 1 day of (minor) tech debt across all the Services according to SonarQube.
Let me know your thoughts on this minor issue in a reply here. And if you haven't checked out our[SonarQube](http://sonar.openlmis.org/)
or looked at the [Technical Debt](https://openlmis.atlassian.net/wiki/x/YQAOBg)
page recently, please do so.
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google.com/d/msgid/openlmis-dev/e2163176-b134-4dcf-8918-48f568198679%40googlegroups.com?utm_medium=email&utm_source=footer).
For more options, visit [](https://groups.google.com/d/optout).
–
Darius Jazayeri* Principal Architect - Global Health*
Email
Telephone
+1 617 383 9369
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google.com/d/msgid/openlmis-dev/4FA428FF-4962-4AED-92B4-4D5F0D2FB04A%40villagereach.org?utm_medium=email&utm_source=footer).
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google.com/d/msgid/openlmis-dev/4D9B138B-C645-40BE-9943-486080DDE032%40villagereach.org?utm_medium=email&utm_source=footer).
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google.com/d/msgid/openlmis-dev/81D287F2-3141-4BA5-8740-AE16892BE1D7%40villagereach.org?utm_medium=email&utm_source=footer).
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google.com/d/msgid/openlmis-dev/BN6PR02MB2625745297B71EEDC444134794600%40BN6PR02MB2625.namprd02.prod.outlook.com?utm_medium=email&utm_source=footer).
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google.com/d/msgid/openlmis-dev/ab9db6db-d7b4-4dcd-6ce6-3da6c261b1f1%40soldevelo.com?utm_medium=email&utm_source=footer).
The reason why I prefer using hyphens over simply dots is so that dots are not being used for multiple purposes (categorization AND multi-word phrasing). With something like referencedata.error.product. wrong.dispensing.units; we are having dots do double duty, which makes the key harder to understand. This is why we had dots for categorization and hyphens for multiple words in a phrase. We could try to solve that using camelCase instead of hyphens, but I would prefer not to simply use dots.
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to .
To view this discussion on the web visit
–
Darius Jazayeri* Principal Architect - Global Health*
Email
Telephone
+1 617 383 9369
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R6TGa4uQ_jZ4%3D_1acLqyieU80mHKXQ9ZUQxyUWGu-STsw%40mail.gmail.com?utm_medium=email&utm_source=footer) . For more options, visit .
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
In most places it looks like we break the SonarWay rule by including hyphens(-) in our message keys. This minor rule suggests that these are more complex / less readable than they should be. A hyphen example is in-fact in our [ style guide](https://github.com/OpenLMIS/openlmis-template-service/blob/master/STYLE-GUIDE.md#i18n-naming-conventions) , so it's certainly reasonable that we have them. In the past sprint we've established a common Message pattern that we'd like Services to use and the UI of course also has message strings. In future sprints we'll be ensuring we have all hard-coded messages converted to translatable messages for our 3.0 release at the end of February, so now's a good time to make a quick decision on this SonarQube rule.
The options you can vote on:[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/e2163176-b134-4dcf-8918-48f568198679%40googlegroups.com.[https://groups.google](https://groups.google)com/d/optout.djazayeri@thoughtworks.com[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/4FA428FF-4962-4AED-92B4-4D5F0D2FB04A%40villagereach.org.
For more options, visit [](https://groups.google.com/d/optout).[https://groups.google](https://groups.google)com/d/optout.[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/4D9B138B-C645-40BE-9943-486080DDE032%40villagereach.org.
For more options, visit [](https://groups.google.com/d/optout).[https://groups.google](https://groups.google)com/d/optout.
[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/81D287F2-3141-4BA5-8740-AE16892BE1D7%40villagereach.org.
For more options, visit [](https://groups.google.com/d/optout).[https://groups.google](https://groups.google)com/d/optout.
[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/BN6PR02MB2625745297B71EEDC444134794600%40BN6PR02MB2625.namprd02.prod.outlook.com.
For more options, visit [](https://groups.google.com/d/optout).[https://groups.google](https://groups.google)com/d/optout.
[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/ab9db6db-d7b4-4dcd-6ce6-3da6c261b1f1%40soldevelo.com.
For more options, visit [](https://groups.google.com/d/optout).[https://groups.google](https://groups.google)com/d/optout.
openlmis-dev@googlegroups.com
From what I see the sonar rule allows to use camelCase in keys in properties file. Also for me dots and camelCase are more related with Java but I see spring properties use hyphens (*spring.jpa.hibernate.naming.implicit-strategy* ) and underscores (*spring.jpa.properties.hibernate.hbm2ddl.import_files*)
.
Regards,
Łukasz
···
Łukasz Lewczyński
Software Developer
SolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41 Al. Zwycięstwa 96/98 81-451, Gdynia
[http://www.soldevelo.com](http://www.SolDevelo.com)
Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN
with "less dots" I meant any approach of not replacing hyphens with dots.
Regards,
Sebastian.
--
Sebastian Brudziński
Software Developer / Team Leader
SolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41 Al. Zwycięstwa 96/98 81-451, Gdynia
[http://www.soldevelo.com](http://www.SolDevelo.com)
Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN
-- You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to . To post to this group, send email to . To view this discussion on the web visit . For more options, visit .
The usual standard is that dots are not supposed to replace spaces, but they're supposed to indicate a hierarchy of messages. (Camel-case is how you replace spaces in Java land.)
This instead (assuming we're grouping all the product-related errors under referencedata.product):
referencedata.product.error.wrongDispensingUnits
Or else this could be
referencedata.product.dispensingUnits. error (if this is the only applicable error)
referencedata.product.dispensingUnits. error.wrong (if you also need parallel-level errors like "required")
(For referencedata it's pretty clean to approach it as service.entity.property[.error].messageCodeInCamelCase but this may not work as nicely for more workflow-oriented services.)
Sebastian, when you said "less dots" did you mean "some dots but not as many"? And how would you suggest we do this example?
-Darius
On Mon, Jan 9, 2017 at 3:13 PM, Chongsun Ahn <chongsun.ahn@villagereach.org>
wrote:
Hey all,
Shalom,
Chongsun
--
There are 10 kinds of people in this world; those who understand binary, and those who don’t.
Connect on **[Facebook](https://www.facebook.com/pages/VillageReach/103205113922)****,** **[Twitter](https://twitter.com/VillageReach)**** **and our **[Blog](http://villagereach.org/see-our-blog/thoughts-from-the-last-mile/)**
On Jan 9, 2017, at 3:02 PM, Sebastian Brudziński <sbrudzinski@soldevelo.com > wrote:
Hello.
I'm OK with both options. My personal preference is no hyphens and camelCase, rather than multiple dots. I think keys with many dots are a little less readable and with less dots we can create a nice, hierarchical/logical structure.
Kind regards,
Sebastian.
Sebastian Brudziński
Software Developer / Team Leader
SolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41Al. Zwycięstwa 96/9881-451, Gdynia
[http://www.soldevelo.com](http://www.soldevelo.com/)
Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN
On 05.01.2017 14:55, Nick Reid wrote:
I’ll second option 2
Question: Are we standardizing on using multiple dots or camelCase? — I'd like to get this decision made so the UI work gets done once and not twice
* 2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: +1.510.410.0020
SKYPE: nickdotreid
From:openlmis-dev@googlegroups.com on behalf of Brandon Bowersox-Johnson Wednesday, January 4, 2017 3:15:43 PM OpenLMIS Dev Re: [openlmis-dev] SonarQube Rule: Message Key guidelines
I vote for option 2, changing to the dot notation (no hyphens).
FWIW, I had looked into what it might take to customize this Sonar rule (to allow hyphens as our current style guide does). It seemed like a real pain to create our own rule. There is not an off-the-shelf rule with a regex that allows the hyphens, and there was not a setting where we could just re-configure the regex. We are currently using the SonarWay ruleset, and we haven’t modified it at all. Modifying it means we would have to “fork” the ruleset to start making our own local modifications. But by “forking” the ruleset it appeared as though we would always have to manually do effort to incorporate the new SonarWay default rules as those evolve over time. If I understood Sonar’s docs correctly, I think we’d be better off changing our style guide to fit the industry convention rather than forking the ruleset and going through all that trouble. Phew!
On Jan 4, 2017, at 10:59 AM, Darius Jazayeri <> wrote:
In other projects I've always seen dots, not hyphens, in message keys.
(I would vote for changing to dots, though I have no opinion about how much of a priority this is. If changing allows sonar to catch hardcoded messages, that would be great!)
-Darius
On Wed, Jan 4, 2017 at 9:26 AM, Josh Zamor <> wrote:
To not forget our Sonar service in the new year, I looked at some of the newest issues it was identifying this morning and found the following with regards to our message keys:
Keep our style guide, hyphens and all. This would have no change to existing code and we'd disable this [ SonarWay rule](http://sonar.openlmis.org/coding_rules#rule_key=jproperties%3Akey-naming-convention).
Change our message keys to conform to the SonarWay rule, and update our [ style guide](https://github.com/OpenLMIS/openlmis-template-service/blob/master/STYLE-GUIDE.md) . If we did this, we'd correct nearly 1 day of (minor) tech debt across all the Services according to SonarQube.
Let me know your thoughts on this minor issue in a reply here. And if you haven't checked out our[SonarQube](http://sonar.openlmis.org/) or looked at the [Technical Debt](https://openlmis.atlassian.net/wiki/x/YQAOBg) page recently, please do so.
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit .
For more options, visit .
–
Darius Jazayeri* Principal Architect - Global Health*
Email
Telephone
+1 617 383 9369
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit .
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit .
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit .
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit .
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit .
The reason why I prefer using hyphens over simply dots is so that dots are not being used for multiple purposes (categorization AND multi-word phrasing). With something like referencedata.error.product. wrong.dispensing.units; we are having dots do double duty, which makes the key harder to understand. This is why we had dots for categorization and hyphens for multiple words in a phrase. We could try to solve that using camelCase instead of hyphens, but I would prefer not to simply use dots.
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to .
To view this discussion on the web visit
–
Darius Jazayeri* Principal Architect - Global Health*
Email
Telephone
+1 617 383 9369
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit . For more options, visit .
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
In most places it looks like we break the SonarWay rule by including hyphens(-) in our message keys. This minor rule suggests that these are more complex / less readable than they should be. A hyphen example is in-fact in our [ style guide](https://github.com/OpenLMIS/openlmis-template-service/blob/master/STYLE-GUIDE.md#i18n-naming-conventions) , so it's certainly reasonable that we have them. In the past sprint we've established a common Message pattern that we'd like Services to use and the UI of course also has message strings. In future sprints we'll be ensuring we have all hard-coded messages converted to translatable messages for our 3.0 release at the end of February, so now's a good time to make a quick decision on this SonarQube rule.
The options you can vote on:[](https://groups.google)[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/e2163176-b134-4dcf-8918-48f568198679%40googlegroups.com.[](https://groups.google)[https://groups.google](https://groups.google)com/d/optout.djazayeri@thoughtworks.com[](https://groups.google)[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/4FA428FF-4962-4AED-92B4-4D5F0D2FB04A%40villagereach.org.
For more options, visit .[](https://groups.google)[https://groups.google](https://groups.google)com/d/optout.[](https://groups.google)[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/4D9B138B-C645-40BE-9943-486080DDE032%40villagereach.org.
For more options, visit .[](https://groups.google)[https://groups.google](https://groups.google)com/d/optout.
[](https://groups.google)[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/81D287F2-3141-4BA5-8740-AE16892BE1D7%40villagereach.org.
For more options, visit .[](https://groups.google)[https://groups.google](https://groups.google)com/d/optout.
[](https://groups.google)[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/BN6PR02MB2625745297B71EEDC444134794600%40BN6PR02MB2625.namprd02.prod.outlook.com.
For more options, visit .[](https://groups.google)[https://groups.google](https://groups.google)com/d/optout.
[](https://groups.google)[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/ab9db6db-d7b4-4dcd-6ce6-3da6c261b1f1%40soldevelo.com.
For more options, visit .[](https://groups.google)[https://groups.google](https://groups.google)com/d/optout.
openlmis-dev@googlegroups.com
Agreed that there’s nothing inherently wrong with hyphens or the style guide as is.
The original question was: what should we do with this SonarQube rule? disable the rule (option 1) or amend our style guide and current strings to match the SonarQube rule (option 2).
It started to sound as if consensus was building behind option 2, conform to the sonar rule. If I quickly hack the style guide, that’d look like:
I’m happy with this change. Any concerns? If so we’ll of course have to followup with work to identify and change any existing code (should be small effort).
Then it seems a new thread is starting: what’s the proper hierarchy to lay out in the style guide. We can jump into that next, but lets first put to rest the SonarRule / hyphen question.
···
On Tuesday, January 10, 2017 at 1:24:57 AM UTC-8, llewczynski wrote:
Hi all,
From what I see the sonar rule allows to use camelCase in keys in properties file. Also for me dots and camelCase are more related with Java but I see spring properties use hyphens (*spring.jpa.hibernate.naming.implicit-strategy* ) and underscores (*spring.jpa.properties.hibernate.hbm2ddl.import_files*
) .
Regards,
Łukasz
Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com
SolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41 Al. Zwycięstwa 96/98 81-451, Gdynia
[http://www.soldevelo.com](http://www.SolDevelo.com)
Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN
On 01/10/2017 09:54 AM, Sebastian Brudziński wrote:
Hi Darius,
with "less dots" I meant any approach of not replacing hyphens with dots.
Regards,
Sebastian.
--
Sebastian Brudziński
Software Developer / Team Leader
sbrudzinski@soldevelo.com
SolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41 Al. Zwycięstwa 96/98 81-451, Gdynia
[http://www.soldevelo.com](http://www.SolDevelo.com)
Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN
On 10.01.2017 00:42, Darius Jazayeri wrote:
The usual standard is that dots are not supposed to replace spaces, but they're supposed to indicate a hierarchy of messages. (Camel-case is how you replace spaces in Java land.)
This instead (assuming we're grouping all the product-related errors under referencedata.product):
referencedata.product.error.wrongDispensingUnits
Or else this could be
referencedata.product.dispensingUnits. error (if this is the only applicable error)
referencedata.product.dispensingUnits. error.wrong (if you also need parallel-level errors like "required")
(For referencedata it's pretty clean to approach it as service.entity.property[. error].messageCodeInCamelCase but this may not work as nicely for more workflow-oriented services.)
Sebastian, when you said "less dots" did you mean "some dots but not as many"? And how would you suggest we do this example?
-Darius
On Mon, Jan 9, 2017 at 3:13 PM, Chongsun Ahn <chongsun.ahn@villagereach.org> > > > wrote:
Hey all,
Shalom,
Chongsun
--
There are 10 kinds of people in this world; those who understand binary, and those who don’t.
Connect on **[Facebook](https://www.facebook.com/pages/VillageReach/103205113922)****,** **[Twitter](https://twitter.com/VillageReach)**** **and our **[Blog](http://villagereach.org/see-our-blog/thoughts-from-the-last-mile/)**
On Jan 9, 2017, at 3:02 PM, Sebastian Brudziński <sbrudzinski@soldevelo.com > wrote:
Hello.
I'm OK with both options. My personal preference is no hyphens and camelCase, rather than multiple dots. I think keys with many dots are a little less readable and with less dots we can create a nice, hierarchical/logical structure.
Kind regards,
Sebastian.
Sebastian Brudziński
Software Developer / Team Leader
sbrudzinski@soldevelo.com
SolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41Al. Zwycięstwa 96/9881-451, Gdynia
[http://www.soldevelo.com](http://www.soldevelo.com/)
Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN
On 05.01.2017 14:55, Nick Reid wrote:
I’ll second option 2
Question: Are we standardizing on using multiple dots or camelCase? — I'd like to get this decision made so the UI work gets done once and not twice
* 2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: +1.510.410.0020
SKYPE: nickdotreid
[](http://www.villagereach.org)[www.villagereach.org](http://www.villagereach.org)
**Sent:** Wednesday, January 4, 2017 3:15:43 PM
**To:** OpenLMIS Dev
**Subject:** Re: [openlmis-dev] SonarQube Rule: Message Key guidelines
I vote for option 2, changing to the dot notation (no hyphens).
FWIW, I had looked into what it might take to customize this Sonar rule (to allow hyphens as our current style guide does). It seemed like a real pain to create our own rule. There is not an off-the-shelf rule with a regex that allows the hyphens, and there was not a setting where we could just re-configure the regex. We are currently using the SonarWay ruleset, and we haven’t modified it at all. Modifying it means we would have to “fork” the ruleset to start making our own local modifications. But by “forking” the ruleset it appeared as though we would always have to manually do effort to incorporate the new SonarWay default rules as those evolve over time. If I understood Sonar’s docs correctly, I think we’d be better off changing our style guide to fit the industry convention rather than forking the ruleset and going through all that trouble. Phew!
On Jan 4, 2017, at 10:59 AM, Darius Jazayeri <djazayer@thoughtworks.com > wrote:
In other projects I've always seen dots, not hyphens, in message keys.
(I would vote for changing to dots, though I have no opinion about how much of a priority this is. If changing allows sonar to catch hardcoded messages, that would be great!)
-Darius
On Wed, Jan 4, 2017 at 9:26 AM, Josh Zamor <josh.zamor@villagereach.org > wrote:
To not forget our Sonar service in the new year, I looked at some of the newest issues it was identifying this morning and found the following with regards to our message keys:
[](http://sonar.openlmis.org/)[http://sonar.openlmis.org/](http://sonar.openlmis.org/)coding_rules#rule_key=jproperties%3Akey-naming-convention
In most places it looks like we break the SonarWay rule by including hyphens(-) in our message keys. This minor rule suggests that these are more complex / less readable than they should be. A hyphen example is in-fact in our [ style guide](https://github.com/OpenLMIS/openlmis-template-service/blob/master/STYLE-GUIDE.md#i18n-naming-conventions) , so it's certainly reasonable that we have them. In the past sprint we've established a common Message pattern that we'd like Services to use and the UI of course also has message strings. In future sprints we'll be ensuring we have all hard-coded messages converted to translatable messages for our 3.0 release at the end of February, so now's a good time to make a quick decision on this SonarQube rule.
The options you can vote on:
Keep our style guide, hyphens and all. This would have no change to existing code and we'd disable this [ SonarWay rule](http://sonar.openlmis.org/coding_rules#rule_key=jproperties%3Akey-naming-convention).
Change our message keys to conform to the SonarWay rule, and update our [ style guide](https://github.com/OpenLMIS/openlmis-template-service/blob/master/STYLE-GUIDE.md) . If we did this, we'd correct nearly 1 day of (minor) tech debt across all the Services according to SonarQube.
Let me know your thoughts on this minor issue in a reply here. And if you haven't checked out our[SonarQube](http://sonar.openlmis.org/) or looked at the [Technical Debt](https://openlmis.atlassian.net/wiki/x/YQAOBg) page recently, please do so.
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google)[https://groups.google](https://groups.google).com/d/msgid/openlmis-dev/e2163176-b134-4dcf-8918-48f568198679%[40googlegroups.com](http://40googlegroups.com).
For more options, visit [](https://groups.google)[https://groups.google](https://groups.google).com/d/optout.
–
Darius Jazayeri* Principal Architect - Global Health*
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google)[https://groups.google](https://groups.google).com/d/msgid/openlmis-dev/4FA428FF-4962-4AED-92B4-4D5F0D2FB04A%[40villagereach.org](http://40villagereach.org).
For more options, visit [](https://groups.google)[https://groups.google](https://groups.google).com/d/optout.
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google)[https://groups.google](https://groups.google).com/d/msgid/openlmis-dev/4D9B138B-C645-40BE-9943-486080DDE032%[40villagereach.org](http://40villagereach.org).
For more options, visit [](https://groups.google)[https://groups.google](https://groups.google).com/d/optout.
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google)[https://groups.google](https://groups.google).com/d/msgid/openlmis-dev/81D287F2-3141-4BA5-8740-AE16892BE1D7%[40villagereach.org](http://40villagereach.org).
For more options, visit [](https://groups.google)[https://groups.google](https://groups.google).com/d/optout.
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google)[https://groups.google](https://groups.google).com/d/msgid/openlmis-dev/BN6PR02MB2625745297B71EEDC444134794600%[40BN6PR02MB2625.namprd02.prod.outlook.com](http://40BN6PR02MB2625.namprd02.prod.outlook.com).
For more options, visit [](https://groups.google)[https://groups.google](https://groups.google).com/d/optout.
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google)[https://groups.google](https://groups.google).com/d/msgid/openlmis-dev/ab9db6db-d7b4-4dcd-6ce6-3da6c261b1f1%[40soldevelo.com](http://40soldevelo.com).
For more options, visit [](https://groups.google)[https://groups.google](https://groups.google).com/d/optout.
The reason why I prefer using hyphens over simply dots is so that dots are not being used for multiple purposes (categorization AND multi-word phrasing). With something like referencedata.error.product. wrong.dispensing.units; we are having dots do double duty, which makes the key harder to understand. This is why we had dots for categorization and hyphens for multiple words in a phrase. We could try to solve that using camelCase instead of hyphens, but I would prefer not to simply use dots.
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R6TGa4uQ_jZ4%3D_1acLqyieU80mHKXQ9ZUQxyUWGu-STsw%40mail.gmail.com)[https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R6TGa4uQ_jZ4%3D_1acLqyieU80mHKXQ9ZUQxyUWGu-STsw%40mail.gmail.com](https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R6TGa4uQ_jZ4%3D_1acLqyieU80mHKXQ9ZUQxyUWGu-STsw%40mail.gmail.com).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google.com/d/msgid/openlmis-dev/5874A14F.5080100%40soldevelo.com?utm_medium=email&utm_source=footer)[https://groups.google.com/d/msgid/openlmis-dev/5874A14F.5080100%40soldevelo.com](https://groups.google.com/d/msgid/openlmis-dev/5874A14F.5080100%40soldevelo.com).
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
I think your pull request (option 2) makes good sense.
I also suggest you add a sentence “Keys cannot include hyphens or other punctuation”.
I think we got a good variety of input on it, and the consensus leaned towards option 2. Whatever final decision you make, I believe everyone will feel that their voice was heard.
Agreed that there’s nothing inherently wrong with hyphens or the
style guide as is.
The original question was: what should we do with this SonarQube rule? disable the rule (option 1) or amend our style guide and current strings to match the SonarQube rule (option 2).
It started to sound as if consensus was building behind option 2, conform to the sonar rule. If I quickly hack the style guide, that’d look like:
I’m happy with this change. Any concerns? If so we’ll of course have to followup with work to identify and change any existing code (should be small effort).
Then it seems a new thread is starting: what’s the proper hierarchy to lay out in the style guide. We can jump into that next, but lets first put to rest the SonarRule / hyphen question.
On Tuesday, January 10, 2017 at 1:24:57 AM UTC-8, llewczynski wrote:
Hi all,
From what I see the sonar rule allows to use camelCase in keys in properties file. Also for me dots and camelCase are more related with Java but I see spring properties use hyphens (spring.jpa.hibernate.naming.implicit-strategy) and underscores (spring.jpa.properties.hibernate.hbm2ddl.import_files ) .
Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN
On 10.01.2017 00:42, Darius Jazayeri wrote:
The usual standard is that dots are not supposed to replace spaces, but they’re supposed to indicate a hierarchy of messages. (Camel-case is how you replace spaces in Java land.)
This instead (assuming we’re grouping all the product-related errors under referencedata.product):
referencedata.product.error.wrongDispensingUnits
Or else this could be
referencedata.product.dispensingUnits.error (if this is the only applicable error)
referencedata.product.dispensingUnits.error.wrong (if you also need parallel-level errors like "required")
(For referencedata it’s pretty clean to approach it as service.entity.property[.error].messageCodeInCamelCase but this may not work as nicely for more workflow-oriented services.)
Sebastian, when you said “less dots” did you mean “some dots but not as many”? And how would you suggest we do this example?
The reason why I prefer using hyphens over simply dots is so that dots are not being used for multiple purposes (categorization AND multi-word phrasing). With something like referencedata.error.product.wrong.dispensing.units; we are having dots do double duty, which makes the key harder to understand. This is why we had dots for categorization and hyphens for multiple words in a phrase. We could try to solve that using camelCase instead of hyphens, but I would prefer not to simply use dots.
Shalom,
Chongsun
–
There are 10 kinds of people in this world; those who understand binary, and those who don’t.
I’m OK with both options. My personal preference is no hyphens and camelCase, rather than multiple dots. I think keys with many dots are a little less readable and with less dots we can create a nice, hierarchical/logical structure.
I vote for option 2, changing to the dot notation (no hyphens).
FWIW, I had looked into what it might take to customize this Sonar rule (to allow hyphens as our current style guide does). It seemed like a real pain to create our own rule. There is not an off-the-shelf rule with a regex that allows the hyphens, and there was not a setting where we could just re-configure the regex. We are currently using the SonarWay ruleset, and we haven’t modified it at all. Modifying it means we would have to “fork” the ruleset to start making our own local modifications. But by “forking” the ruleset it appeared as though we would always have to manually do effort to incorporate the new SonarWay default rules as those evolve over time. If I understood Sonar’s docs correctly, I think we’d be better off changing our style guide to fit the industry convention rather than forking the ruleset and going through all that trouble. Phew!
In other projects I’ve always seen dots, not hyphens, in message keys.
(I would vote for changing to dots, though I have no opinion about how much of a priority this is. If changing allows sonar to catch hardcoded messages, that would be great!)
To not forget our Sonar service in the new year, I looked at some of the newest issues it was identifying this morning and found the following with regards to our message keys:
In most places it looks like we break the SonarWay rule by including hyphens(-) in our message keys. This minor rule suggests that these are more complex / less readable than they should be. A hyphen example is in-fact in our style guide , so it’s certainly reasonable that we have them. In the past sprint we’ve established a common Message pattern that we’d like Services to use and the UI of course also has message strings. In future sprints we’ll be ensuring we have all hard-coded messages converted to translatable messages for our 3.0 release at the end of February, so now’s a good time to make a quick decision on this SonarQube rule.
The options you can vote on:
Keep our style guide, hyphens and all. This would have no change to existing code and we'd disable this [ SonarWay rule](http://sonar.openlmis.org/coding_rules#rule_key=jproperties%3Akey-naming-convention).
Change our message keys to conform to the SonarWay rule, and update our [ style guide](https://github.com/OpenLMIS/openlmis-template-service/blob/master/STYLE-GUIDE.md). If we did this, we'd correct nearly 1 day of (minor) tech debt across all the Services according to SonarQube.
Let me know your thoughts on this minor issue in a reply here. And if you haven’t checked out ourSonarQube or looked at the Technical Debt page recently, please do so.
–
You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.
I think your pull request (option 2) makes good sense.
I also suggest you add a sentence “Keys cannot include hyphens or other punctuation”.
I think we got a good variety of input on it, and the consensus leaned towards option 2. Whatever final decision you make, I believe everyone will feel that their voice was heard.
The original question was: what should we do with this SonarQube rule? disable the rule (option 1) or amend our style guide and current strings to match the SonarQube rule (option 2).
It started to sound as if consensus was building behind option 2, conform to the sonar rule. If I quickly hack the style guide, that'd look like:
I'm happy with this change. Any concerns? If so we'll of course have to followup with work to identify and change any existing code (should be small effort).
Then it seems a new thread is starting: what's the proper hierarchy to lay out in the style guide. We can jump into that next, but lets first put to rest the SonarRule / hyphen question.
On Tuesday, January 10, 2017 at 1:24:57 AM UTC-8, llewczynski wrote:
Hi all,
From what I see the sonar rule allows to use camelCase in keys in properties file. Also for me dots and camelCase are more related with Java but I see spring properties use hyphens (spring.jpa.hibernate.naming.implicit-strategy) and underscores (spring.jpa.properties.hibernate.hbm2ddl.import_files) .
Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN
On 10.01.2017 00:42, Darius Jazayeri wrote:
The usual standard is that dots are not supposed to replace spaces, but they're supposed to indicate a hierarchy of messages. (Camel-case is how you replace spaces in Java land.)
Not this:
referencedata.error.product.wrong.dispensing.units
This instead (assuming we're grouping all the product-related errors under referencedata.product):
referencedata.product.error.wrongDispensingUnits
Or else this could be
referencedata.product.dispensingUnits.error (if this is the only applicable error)
referencedata.product.dispensingUnits.error.wrong (if you also need parallel-level errors like "required")
(For referencedata it's pretty clean to approach it as service.entity.property[.error].messageCodeInCamelCase but this may not work as nicely for more workflow-oriented services.)
Sebastian, when you said "less dots" did you mean "some dots but not as many"? And how would you suggest we do this example?
The reason why I prefer using hyphens over simply dots is so that dots are not being used for multiple purposes (categorization AND multi-word phrasing). With something like referencedata.error.product.wrong.dispensing.units; we are having dots do double duty, which makes the key harder to understand. This is why we had dots for categorization and hyphens for multiple words in a phrase. We could try to solve that using camelCase instead of hyphens, but I would prefer not to simply use dots.
Shalom,
Chongsun
--
There are 10 kinds of people in this world; those who understand binary, and those who don’t.
I'm OK with both options. My personal preference is no hyphens and camelCase, rather than multiple dots. I think keys with many dots are a little less readable and with less dots we can create a nice, hierarchical/logical structure.
I vote for option 2, changing to the dot notation (no hyphens).
FWIW, I had looked into what it might take to customize this Sonar rule (to allow hyphens as our current style guide does). It seemed like a real pain to create our own rule. There is not an off-the-shelf rule with a regex that allows the hyphens, and there was not a setting where we could just re-configure the regex. We are currently using the SonarWay ruleset, and we haven’t modified it at all. Modifying it means we would have to “fork” the ruleset to start making our own local modifications. But by “forking” the ruleset it appeared as though we would always have to manually do effort to incorporate the new SonarWay default rules as those evolve over time. If I understood Sonar’s docs correctly, I think we’d be better off changing our style guide to fit the industry convention rather than forking the ruleset and going through all that trouble. Phew!
In other projects I've always seen dots, not hyphens, in message keys.
(I would vote for changing to dots, though I have no opinion about how much of a priority this is. If changing allows sonar to catch hardcoded messages, that would be great!)
-Darius
On Wed, Jan 4, 2017 at 9:26 AM, Josh Zamor <josh.zamor@villagereach.org<mailto:josh.zamor@villagereach.org>> wrote:
To not forget our Sonar service in the new year, I looked at some of the newest issues it was identifying this morning and found the following with regards to our message keys:
In most places it looks like we break the SonarWay rule by including hyphens(-) in our message keys. This minor rule suggests that these are more complex / less readable than they should be. A hyphen example is in-fact in our style guide<https://github.com/OpenLMIS/openlmis-template-service/blob/master/STYLE-GUIDE.md#i18n-naming-conventions>, so it's certainly reasonable that we have them. In the past sprint we've established a common Message pattern that we'd like Services to use and the UI of course also has message strings. In future sprints we'll be ensuring we have all hard-coded messages converted to translatable messages for our 3.0 release at the end of February, so now's a good time to make a quick decision on this SonarQube rule.
I’m interested in this discussion on hierarchy - should it stay as .<[error|message]>., or do we need the style guide to lay out a tighter or different convention? This is something that SonarQube will help much less with, so I’m wondering where the desire to tighten things up comes from?
Best,
Josh
···
On Wednesday, January 11, 2017 at 10:29:11 AM UTC-8, chongsun.ahn wrote:
Forbidding hyphens and using camelCase for multiple words is fine with me.
Shalom,
Chongsun
–
There are 10 kinds of people in this world; those who understand binary, and those who don’t.
I think your pull request (option 2) makes good sense.
I also suggest you add a sentence “Keys cannot include hyphens or other punctuation”.
I think we got a good variety of input on it, and the consensus leaned towards option 2. Whatever final decision you make, I believe everyone will feel that their voice was heard.
Agreed that there’s nothing *inherently *wrong with hyphens or the style guide as is.
The original question was: what should we do with this SonarQube rule? disable the rule (option 1) or amend our style guide and current strings to match the SonarQube rule (option 2).
It started to sound as if consensus was building behind option 2, conform to the sonar rule. If I quickly hack the style guide, that’d look like:
I’m happy with this change. Any concerns? If so we’ll of course have to followup with work to identify and change any existing code (should be small effort).
Then it seems a new thread is starting: what’s the proper hierarchy to lay out in the style guide. We can jump into that next, but lets first put to rest the SonarRule / hyphen question.
On Tuesday, January 10, 2017 at 1:24:57 AM UTC-8, llewczynski wrote:
Hi all,
From what I see the sonar rule allows to use camelCase in keys in properties file. Also for me dots and camelCase are more related with Java but I see spring properties use hyphens (spring.jpa.hibernate.naming.implicit-strategy ) and underscores (spring.jpa.properties.hibernate.hbm2ddl.import_files) .
Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN
On 10.01.2017 00:42, Darius Jazayeri wrote:
The usual standard is that dots are not supposed to replace spaces, but they’re supposed to indicate a hierarchy of messages. (Camel-case is how you replace spaces in Java land.)
This instead (assuming we’re grouping all the product-related errors under referencedata.product):
referencedata.product.error.wrongDispensingUnits
Or else this could be
referencedata.product.dispensingUnits.error (if this is the only applicable error)
referencedata.product.dispensingUnits.error.wrong (if you also need parallel-level errors like "required")
(For referencedata it’s pretty clean to approach it as service.entity.property[.error].messageCodeInCamelCase but this may not work as nicely for more workflow-oriented services.)
Sebastian, when you said “less dots” did you mean “some dots but not as many”? And how would you suggest we do this example?
The reason why I prefer using hyphens over simply dots is so that dots are not being used for multiple purposes (categorization AND multi-word phrasing). With something like referencedata.error.product. wrong.dispensing.units; we are having dots do double duty, which makes the key harder to understand. This is why we had dots for categorization and hyphens for multiple words in a phrase. We could try to solve that using camelCase instead of hyphens, but I would prefer not to simply use dots.
Shalom,
Chongsun
–
There are 10 kinds of people in this world; those who understand binary, and those who don’t.
I’m OK with both options. My personal preference is no hyphens and camelCase, rather than multiple dots. I think keys with many dots are a little less readable and with less dots we can create a nice, hierarchical/logical structure.
I vote for option 2, changing to the dot notation (no hyphens).
FWIW, I had looked into what it might take to customize this Sonar rule (to allow hyphens as our current style guide does). It seemed like a real pain to create our own rule. There is not an off-the-shelf rule with a regex that allows the hyphens, and there was not a setting where we could just re-configure the regex. We are currently using the SonarWay ruleset, and we haven’t modified it at all. Modifying it means we would have to “fork” the ruleset to start making our own local modifications. But by “forking” the ruleset it appeared as though we would always have to manually do effort to incorporate the new SonarWay default rules as those evolve over time. If I understood Sonar’s docs correctly, I think we’d be better off changing our style guide to fit the industry convention rather than forking the ruleset and going through all that trouble. Phew!
In other projects I’ve always seen dots, not hyphens, in message keys.
(I would vote for changing to dots, though I have no opinion about how much of a priority this is. If changing allows sonar to catch hardcoded messages, that would be great!)
To not forget our Sonar service in the new year, I looked at some of the newest issues it was identifying this morning and found the following with regards to our message keys:
In most places it looks like we break the SonarWay rule by including hyphens(-) in our message keys. This minor rule suggests that these are more complex / less readable than they should be. A hyphen example is in-fact in our style guide , so it’s certainly reasonable that we have them. In the past sprint we’ve established a common Message pattern that we’d like Services to use and the UI of course also has message strings. In future sprints we’ll be ensuring we have all hard-coded messages converted to translatable messages for our 3.0 release at the end of February, so now’s a good time to make a quick decision on this SonarQube rule.
The options you can vote on:
Keep our style guide, hyphens and all. This would have no change to existing code and we'd disable this [ SonarWay rule](http://sonar.openlmis.org/coding_rules#rule_key=jproperties%3Akey-naming-convention).
Change our message keys to conform to the SonarWay rule, and update our [ style guide](https://github.com/OpenLMIS/openlmis-template-service/blob/master/STYLE-GUIDE.md). If we did this, we'd correct nearly 1 day of (minor) tech debt across all the Services according to SonarQube.
Let me know your thoughts on this minor issue in a reply here. And if you haven’t checked out ourSonarQube or looked at the Technical Debt page recently, please do so.
–
You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.
I think, that comments in OLMIS-1252 () may be a good start of the discussion, since me, Nick and Ben spent some time talking about possible hierarchies there.
Those changes to the style guide are now incorporated into the document:
From now on we should not be using punctuation other than periods/dots in message keys. Please circulate and start working this way. SonarQube shows us the Tech Debt on this issue: I'm interested in this discussion on hierarchy - should it stay as <serviceName>.<[error|message]>.<moreStuffHere>, or do we need the style guide to lay out a tighter or different convention? This is something that SonarQube will help much less with, so I'm wondering where the desire to tighten things up comes from? Best, Josh On Wednesday, January 11, 2017 at 10:29:11 AM UTC-8, chongsun.ahn wrote:
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google.com/d/msgid/openlmis-dev/b7860a5f-79f8-410b-8a86-96932ef9fd32%40googlegroups.com?utm_medium=email&utm_source=footer) . For more options, visit .
–
Paweł Lal
Junior Software Developer
/ +48 600 030 259
SolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41 Al. Zwycięstwa 96/98 81-451, Gdynia
[http://www.soldevelo.com](http://www.SolDevelo.com)
Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN
Forbidding hyphens and using camelCase for multiple words is fine with me.
Shalom,
Chongsun
--
There are 10 kinds of people in this world; those who understand binary, and those who don’t.
Connect on **[Facebook](https://www.facebook.com/pages/VillageReach/103205113922)****,** **[Twitter](https://twitter.com/VillageReach)**** **and our **[Blog](http://villagereach.org/see-our-blog/thoughts-from-the-last-mile/)**
On Jan 10, 2017, at 3:30 PM, Brandon Bowersox-Johnson <brandon.bowersox-johnson@villagereach.org > wrote:
I think your pull request (option 2) makes good sense.
I also suggest you add a sentence “Keys cannot include hyphens or other punctuation”.
I think we got a good variety of input on it, and the consensus leaned towards option 2. Whatever final decision you make, I believe everyone will feel that their voice was heard.
-Brandon
**From: **<openlmis-dev@googlegroups.com > on behalf of Josh Zamor < > Tuesday, January 10, 2017 at 1:12 PM OpenLMIS Dev <
Agreed that there’s nothing *inherently * wrong with hyphens or the style guide as is.
The original question was: what should we do with this SonarQube rule? disable the rule (option 1) or amend our style guide and current strings to match the SonarQube rule (option 2).
It started to sound as if consensus was building behind option 2, conform to the sonar rule. If I quickly hack the style guide, that'd look like:
[https://github.com/OpenLMIS/openlmis-template-service/pull/13](https://github.com/OpenLMIS/openlmis-template-service/pull/13)
I'm happy with this change. Any concerns? If so we'll of course have to followup with work to identify and change any existing code (should be small effort).
Then it seems a new thread is starting: what's the proper hierarchy to lay out in the style guide. We can jump into that next, but lets first put to rest the SonarRule / hyphen question.
On Tuesday, January 10, 2017 at 1:24:57 AM UTC-8, llewczynski wrote:
Hi all,
>From what I see the sonar rule allows to use camelCase in keys in properties file. Also for me dots and camelCase are more related with Java but I see spring properties use hyphens (*spring.jpa.hibernate.naming.implicit-strategy* ) and underscores (*spring.jpa.properties.hibernate.hbm2ddl.import_files* ) .
Regards,
Łukasz
** Łukasz Lewczyński**
Software Developer
llewczynski@soldevelo.com
SolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41 Al. Zwycięstwa 96/98 81-451, Gdynia
[http://www.soldevelo.com](http://www.soldevelo.com/)
Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN
On 01/10/2017 09:54 AM, Sebastian Brudziński wrote:
Hi Darius,
with "less dots" I meant any approach of not replacing hyphens with dots.
Regards,
Sebastian.
--
** Sebastian Brudziński**
Software Developer / Team Leader
sbrudzinski@soldevelo.com
SolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41 Al. Zwycięstwa 96/98 81-451, Gdynia
[http://www.soldevelo.com](http://www.soldevelo.com/)
Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN
On 10.01.2017 00:42, Darius Jazayeri wrote:
The usual standard is that dots are not supposed to replace spaces, but they're supposed to indicate a hierarchy of messages. (Camel-case is how you replace spaces in Java land.)
This instead (assuming we're grouping all the product-related errors under referencedata.product):
referencedata.product.error.wrongDispensingUnits
Or else this could be
referencedata.product. dispensingUnits.error (if this is the only applicable error)
referencedata.product. dispensingUnits.error.wrong (if you also need parallel-level errors like "required")
(For referencedata it's pretty clean to approach it as service.entity.property[. error].messageCodeInCamelCase but this may not work as nicely for more workflow-oriented services.)
Sebastian, when you said "less dots" did you mean "some dots but not as many"? And how would you suggest we do this example?
-Darius
On Mon, Jan 9, 2017 at 3:13 PM, Chongsun Ahn <
Hey all,
The reason why I prefer using hyphens over simply dots is so that dots are not being used for multiple purposes (categorization AND multi-word phrasing). With something like referencedata.error.product. wrong.dispensing.units; we are having dots do double duty, which makes the key harder to understand. This is why we had dots for categorization and hyphens for multiple words in a phrase. We could try to solve that using camelCase instead of hyphens, but I would prefer not to simply use dots.
Shalom,
Chongsun
--
There are 10 kinds of people in this world; those who understand binary, and those who don’t.
Connect on **[Facebook](https://www.facebook.com/pages/VillageReach/103205113922),** **[Twitter](https://twitter.com/VillageReach) ** and our **[Blog](http://villagereach.org/see-our-blog/thoughts-from-the-last-mile/)**
On Jan 9, 2017, at 3:02 PM, Sebastian Brudziński < > wrote:
Hello.
I'm OK with both options. My personal preference is no hyphens and camelCase, rather than multiple dots. I think keys with many dots are a little less readable and with less dots we can create a nice, hierarchical/logical structure.
Kind regards,
Sebastian.
**Sent:** Wednesday, January 4, 2017 3:15:43 PM
**To:** OpenLMIS Dev
**Subject:** Re: [openlmis-dev] SonarQube Rule: Message Key guidelines
I vote for option 2, changing to the dot notation (no hyphens).
FWIW, I had looked into what it might take to customize this Sonar rule (to allow hyphens as our current style guide does). It seemed like a real pain to create our own rule. There is not an off-the-shelf rule with a regex that allows the hyphens, and there was not a setting where we could just re-configure the regex. We are currently using the SonarWay ruleset, and we haven’t modified it at all. Modifying it means we would have to “fork” the ruleset to start making our own local modifications. But by “forking” the ruleset it appeared as though we would always have to manually do effort to incorporate the new SonarWay default rules as those evolve over time. If I understood Sonar’s docs correctly, I think we’d be better off changing our style guide to fit the industry convention rather than forking the ruleset and going through all that trouble. Phew!
On Jan 4, 2017, at 10:59 AM, Darius Jazayeri < > wrote:
In other projects I've always seen dots, not hyphens, in message keys.
(I would vote for changing to dots, though I have no opinion about how much of a priority this is. If changing allows sonar to catch hardcoded messages, that would be great!)
-Darius
On Wed, Jan 4, 2017 at 9:26 AM, Josh Zamor < > wrote:
To not forget our Sonar service in the new year, I looked at some of the newest issues it was identifying this morning and found the following with regards to our message keys:
[](http://sonar.openlmis.org/)codi
Keep our style guide, hyphens and all. This would have no change to existing code and we'd disable this [ SonarWay rule](http://sonar.openlmis.org/coding_rules#rule_key=jproperties%3Akey-naming-convention).
Change our message keys to conform to the SonarWay rule, and update our [ style guide](https://github.com/OpenLMIS/openlmis-template-service/blob/master/STYLE-GUIDE.md) . If we did this, we'd correct nearly 1 day of (minor) tech debt across all the Services according to SonarQube.
Let me know your thoughts on this minor issue in a reply here. And if you haven't checked out our[SonarQube](http://sonar.openlmis.org/) or looked at the [ Technical Debt](https://openlmis.atlassian.net/wiki/x/YQAOBg) page recently, please do so.
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google/).
–
** Darius Jazayeri*** Principal Architect - Global Health*
Email
Telephone
+1 617 383 9369
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google/).
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google/).
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google/).
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google/).
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google/).
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google.com/d/).
For more options, visit [](https://groups.google.com/d/optout).
–
Darius Jazayeri* Principal Architect - Global Health*
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R6TGa4uQ_jZ4%3D_1acLqyieU80mHKXQ9ZUQxyUWGu-STsw%40mail.gmail.com).
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google.com/d/msgid/openlmis-dev/5874A14F.5080100%40soldevelo.com).
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google.com/d/msgid/openlmis-dev/83fbda6c-7cd7-42d4-aaf8-be130711bd6e%40googlegroups.com?utm_medium=email&utm_source=footer).
–
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlmis-dev@googlegroups.com.
To view this discussion on the web visit [](https://groups.google.com/d/msgid/openlmis-dev/14604057-297B-47F6-AA1E-E8A0D3C512AC%40villagereach.org?utm_medium=email&utm_source=footer).
**Subject: ** Re: [openlmis-dev] SonarQube Rule: Message Key guidelineschongsun.ahn@villagereach.org > wrote:[www.villagereach.org](http://www.villagereach.org)sbrudzinski@soldevelo.comsbrudzinski@soldevelo.com[http://www.soldevelo.com](http://www.soldevelo.com)[www.villagereach.org](http://www.villagereach.org)josh.zamor@villagereach.org[http://sonar.openlmis.org/](http://sonar.openlmis.org/)es/search#issues=AVlpeqXiQzhzMx5vMFp9djazayer@thoughtworks.comjosh.zamor@villagereach.org[http://sonar.openlmis.org/](http://sonar.openlmis.org/)ng_rules#rule_key=jproperties%3Akey-naming-convention
In most places it looks like we break the SonarWay rule by including hyphens(-) in our message keys. This minor rule suggests that these are more complex / less readable than they should be. A hyphen example is in-fact in our [ style guide](https://github.com/OpenLMIS/openlmis-template-service/blob/master/STYLE-GUIDE.md#i18n-naming-conventions) , so it's certainly reasonable that we have them. In the past sprint we've established a common Message pattern that we'd like Services to use and the UI of course also has message strings. In future sprints we'll be ensuring we have all hard-coded messages converted to translatable messages for our 3.0 release at the end of February, so now's a good time to make a quick decision on this SonarQube rule.
The options you can vote on:[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/e2163176-b134-4dcf-8918-48f568198679%[40googlegroups.com](http://40googlegroups.com/).
For more options, visit [](https://groups.google/).[https://groups.google](https://groups.google)com/d/optout.djazayeri@thoughtworks.com[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/4FA428FF-4962-4AED-92B4-4D5F0D2FB04A%[40villagereach.org](http://40villagereach.org/).
For more options, visit [](https://groups.google/).[https://groups.google](https://groups.google)com/d/optout.[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/4D9B138B-C645-40BE-9943-486080DDE032%[40villagereach.org](http://40villagereach.org/).
For more options, visit [](https://groups.google/).[https://groups.google](https://groups.google)com/d/optout.[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/81D287F2-3141-4BA5-8740-AE16892BE1D7%[40villagereach.org](http://40villagereach.org/).
For more options, visit [](https://groups.google/).[https://groups.google](https://groups.google)com/d/optout.[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/BN6PR02MB2625745297B71EEDC444134794600%[40BN6PR02MB2625.namprd02.prod.outlook.com](http://40bn6pr02mb2625.namprd02.prod.outlook.com/).
For more options, visit [](https://groups.google/).[https://groups.google](https://groups.google)com/d/optout.[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/ab9db6db-d7b4-4dcd-6ce6-3da6c261b1f1%[40soldevelo.com](http://40soldevelo.com/).
For more options, visit [](https://groups.google/).[https://groups.google](https://groups.google)com/d/optout.[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/84ACE850-F362-45DF-A168-4DF945938C31%[40villagereach.org](http://40villagereach.org/).[https://groups.google](https://groups.google)com/d/optout.[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/CAOKb-R6TGa4uQ_jZ4%3D_1acLqyieU80mHKXQ9ZUQxyUWGu-STsw%40mail.gmail.com.
For more options, visit [](https://groups.google.com/d/optout).[https://groups.google](https://groups.google)com/d/optout.[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/5874A14F.5080100%40soldevelo.com.
For more options, visit [](https://groups.google.com/d/optout).[https://groups.google](https://groups.google)com/d/optout.[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/83fbda6c-7cd7-42d4-aaf8-be130711bd6e%40googlegroups.com.
For more options, visit [](https://groups.google.com/d/optout).[https://groups.google](https://groups.google)com/d/optout.
[https://groups.google](https://groups.google)com/d/msgid/openlmis-dev/14604057-297B-47F6-AA1E-E8A0D3C512AC%40villagereach.org.
For more options, visit [](https://groups.google.com/d/optout).[https://groups.google](https://groups.google)com/d/optout.
[https://groups.google.com/d/msgid/openlmis-dev/b7860a5f-79f8-410b-8a86-96932ef9fd32%40googlegroups.com](https://groups.google.com/d/msgid/openlmis-dev/b7860a5f-79f8-410b-8a86-96932ef9fd32%40googlegroups.com)
