SonarQube Rule: Message Key guidelines

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

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:

  1. Keep our style guide, hyphens and all. This would have no change to existing code and we’d disable this SonarWay rule.
  2. 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!)

-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

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:

  1. Keep our style guide, hyphens and all. This would have no change to existing code and we’d disable this SonarWay rule.
  2. 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 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.

For more options, visit https://groups.google.com/d/optout.

Darius JazayeriPrincipal Architect - Global Health
Email
djazayeri@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

It would not help find hardcoded messages unfortunately.

I should link to a real example that sonar is finding:

http://sonar.openlmis.org/issues/search#issues=AVlpeqXiQzhzMx5vMFp9

Here we have dots, but then we also have hyphens. The sonar rule would suggest we change this from:

referencedata.error.product.wrong-dispensing-units

to:

referencedata.error.product.wrongDispensingUnits

OR possibly

referencedata.error.product.wrong.dispensing.units

Best,

Josh

···

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

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:

  1. Keep our style guide, hyphens and all. This would have no change to existing code and we’d disable this
    SonarWay rule
    .
  2. 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 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
.

For more options, visit
https://groups.google.com/d/optout
.

Darius JazayeriPrincipal Architect - Global Health
Email
djazayeri@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

Whoops, correction. Dot notation would yield something more like:

referencedata.error.product.dispensing.units.wrong

···

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

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:

  1. Keep our style guide, hyphens and all. This would have no change to existing code and we’d disable this
    SonarWay rule
    .
  2. 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 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
.

For more options, visit
https://groups.google.com/d/optout
.

Darius JazayeriPrincipal Architect - Global Health
Email
djazayeri@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

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: openlmis-dev@googlegroups.com on behalf of Josh Zamor josh.zamor@villagereach.org

Date: Wednesday, January 4, 2017 at 12:41 PM

To: Darius Jazayeri djazayer@thoughtworks.com

Cc: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] SonarQube Rule: Message Key guidelines

Whoops, correction. Dot notation would yield something more like:

referencedata.error.product.dispensing.units.wrong

On Jan 4, 2017, at 11:26 AM, Josh Zamor josh.zamor@villagereach.org wrote:

It would not help find hardcoded messages unfortunately.

I should link to a real example that sonar is finding:

http://sonar.openlmis.org/issues/search#issues=AVlpeqXiQzhzMx5vMFp9

Here we have dots, but then we also have hyphens. The sonar rule would suggest we change this from:

referencedata.error.product.wrong-dispensing-units

to:

referencedata.error.product.wrongDispensingUnits

OR possibly

referencedata.error.product.wrong.dispensing.units

Best,

Josh

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

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:

  1. Keep our style guide, hyphens and all. This would have no change to existing code and we’d disable this
    SonarWay rule
    .
  1. 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 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
.

For more options, visit
https://groups.google.com/d/optout
.

Darius Jazayeri* Principal Architect - Global Health*

Email

djazayeri@thoughtworks.com

Telephone

+1 617 383 9369

houghtWorks

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
.

For more options, visit 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
.

For more options, visit https://groups.google.com/d/optout.

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

– nick –

···

Nick Reid | nick.reid@villagereach.org

Friendly Neighborhood Spiderman, Information Systems Group

VillageReach** *** Starting at the Last Mile
*2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

CELL: +1.510.410.0020

SKYPE: nickdotreid

www.villagereach.org


From: openlmis-dev@googlegroups.com openlmis-dev@googlegroups.com on behalf of Brandon Bowersox-Johnson brandon.bowersox-johnson@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!

-Brandon

From: openlmis-dev@googlegroups.com on behalf of Josh Zamor josh.zamor@villagereach.org

Date: Wednesday, January 4, 2017 at 12:41 PM

To: Darius Jazayeri djazayer@thoughtworks.com

Cc: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] SonarQube Rule: Message Key guidelines

Whoops, correction. Dot notation would yield something more like:

referencedata.error.product.dispensing.units.wrong

On Jan 4, 2017, at 11:26 AM, Josh Zamor josh.zamor@villagereach.org wrote:

It would not help find hardcoded messages unfortunately.

I should link to a real example that sonar is finding:

http://sonar.openlmis.org/issues/search#issues=AVlpeqXiQzhzMx5vMFp9

Here we have dots, but then we also have hyphens. The sonar rule would suggest we change this from:

referencedata.error.product.wrong-dispensing-units

to:

referencedata.error.product.wrongDispensingUnits

OR possibly

referencedata.error.product.wrong.dispensing.units

Best,

Josh

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

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:

  1. Keep our style guide, hyphens and all. This would have no change to existing code and we’d disable this
    SonarWay rule
    .
  1. 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 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
.

For more options, visit
https://groups.google.com/d/optout
.

Darius Jazayeri* Principal Architect - Global Health*

Email

djazayeri@thoughtworks.com

Telephone

+1 617 383 9369

houghtWorks

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
.

For more options, visit 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
.

For more options, visit 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
.

For more options, visit https://groups.google.com/d/optout.

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.

···

sbrudzinski@soldevelo.com
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

– nick –

** Nick Reid** | nick.reid@villagereach.org

              *                  Friendly Neighborhood <strike>Spiderman</strike>, Information Systems Group*

VillageReach** *** Starting at the Last Mile

             *                   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:

referencedata.error.product.dispensing.units.wrong

                  On Jan 4, 2017, at 11:26 AM, Josh Zamor <josh.zamor@villagereach.org                      > wrote:
                    It would not help find hardcoded messages unfortunately.
                      I should link to a real example that sonar is finding:

http://sonar.openlmis.org/issues/search#issues=AVlpeqXiQzhzMx5vMFp9

                      Here we have dots, but then we also have hyphens.  The sonar rule would suggest we change this from:

referencedata.error.product.wrong-dispensing-units

to:

referencedata.error.product.wrongDispensingUnits

OR possibly

referencedata.error.product.wrong.dispensing.units

Best,

Josh

                            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:
  1.                                       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).
    
  1.                                       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](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](https://groups.google.com/d/optout).

** Darius Jazayeri*** Principal Architect - Global Health*

Email

djazayeri@thoughtworks.com

Telephone

                                            +1 617 383 9369

houghtWorks

                  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).

openlmis-dev@googlegroups.comopenlmis-dev@googlegroups.combrandon.bowersox-johnson@villagereach.org
Sent:
To:
Subject:openlmis-dev@googlegroups.comjosh.zamor@villagereach.org
Date:
To: djazayer@thoughtworks.com
Cc: openlmis-dev@googlegroups.com
Subject:

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.

Chongsun Ahn | chongsun.ahn@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

···

sbrudzinski@soldevelo.com
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

– nick –

Nick Reid | nick.reid@villagereach.org

Friendly Neighborhood Spiderman, Information Systems Group

VillageReach** *** Starting at the Last Mile
*2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

CELL: +1.510.410.0020

SKYPE: nickdotreid

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:

referencedata.error.product.dispensing.units.wrong

On Jan 4, 2017, at 11:26 AM, Josh Zamor josh.zamor@villagereach.org wrote:

It would not help find hardcoded messages unfortunately.

I should link to a real example that sonar is finding:

http://sonar.openlmis.org/issues/search#issues=AVlpeqXiQzhzMx5vMFp9

Here we have dots, but then we also have hyphens. The sonar rule would suggest we change this from:

referencedata.error.product.wrong-dispensing-units

to:

referencedata.error.product.wrongDispensingUnits

OR possibly

referencedata.error.product.wrong.dispensing.units

Best,

Josh

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

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:

  1. Keep our style guide, hyphens and all. This would have no change to existing code and we’d disable this SonarWay rule.
  1. 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.

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.

For more options, visit https://groups.google.com/d/optout.

Darius JazayeriPrincipal Architect - Global Health

Email

djazayeri@thoughtworks.com

Telephone

+1 617 383 9369

houghtWorks

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.

For more options, visit 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.

For more options, visit 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.

For more options, visit 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.

For more options, visit https://groups.google.com/d/optout.
openlmis-dev@googlegroups.com openlmis-dev@googlegroups.com brandon.bowersox-johnson@villagereach.org
Sent:
To:
Subject: openlmis-dev@googlegroups.com josh.zamor@villagereach.org
**Date: **
**To: ** djazayer@thoughtworks.com
**Cc: ** openlmis-dev@googlegroups.com
**Subject: **


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.
For more options, visit https://groups.google.com/d/optout.

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?

-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.

Chongsun Ahn | chongsun.ahn@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

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.

<Soldevelo_logo_EPS_CMYK.png>

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

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

– nick –

Nick Reid | nick.reid@villagereach.org

Friendly Neighborhood Spiderman, Information Systems Group

VillageReach** *** Starting at the Last Mile
*2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

CELL: +1.510.410.0020

SKYPE: nickdotreid

www.villagereach.org


From: openlmis-dev@googlegroups.com openlmis-dev@googlegroups.com on behalf of Brandon Bowersox-Johnsonbrandon.bowersox-johnson@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!

-Brandon

**From: **openlmis-dev@googlegroups.com on behalf of Josh Zamor josh.zamor@villagereach.org

**Date: **Wednesday, January 4, 2017 at 12:41 PM

**To: **Darius Jazayeri djazayer@thoughtworks.com

**Cc: **OpenLMIS Dev openlmis-dev@googlegroups.com

**Subject: **Re: [openlmis-dev] SonarQube Rule: Message Key guidelines

Whoops, correction. Dot notation would yield something more like:

referencedata.error.product.dispensing.units.wrong

On Jan 4, 2017, at 11:26 AM, Josh Zamor josh.zamor@villagereach.org wrote:

It would not help find hardcoded messages unfortunately.

I should link to a real example that sonar is finding:

http://sonar.openlmis.org/issues/search#issues=AVlpeqXiQzhzMx5vMFp9

Here we have dots, but then we also have hyphens. The sonar rule would suggest we change this from:

referencedata.error.product.wrong-dispensing-units

to:

referencedata.error.product.wrongDispensingUnits

OR possibly

referencedata.error.product.wrong.dispensing.units

Best,

Josh

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

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:

  1. Keep our style guide, hyphens and all. This would have no change to existing code and we’d disable this SonarWay rule.
  2. 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.

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.

For more options, visit https://groups.google.com/d/optout.

Darius JazayeriPrincipal Architect - Global Health

Email

djazayeri@thoughtworks.com

Telephone

+1 617 383 9369

houghtWorks

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.

For more options, visit 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.

For more options, visit 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.

For more options, visit 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.

For more options, visit 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/ab9db6db-d7b4-4dcd-6ce6-3da6c261b1f1%40soldevelo.com.

For more options, visit 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.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/84ACE850-F362-45DF-A168-4DF945938C31%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

Darius JazayeriPrincipal Architect - Global Health
Email
djazayeri@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

Hi Darius,

with "less dots" I meant any approach of not replacing hyphens with dots.

Regards,

Sebastian.

···

sbrudzinski@soldevelo.com
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?

-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.
                            Chongsun Ahn | chongsun.ahn@villagereach.org
  •                              Software Development Engineer*
    

Village****Reach* *Starting at the Last Mile

                              2900 Eastlake Ave. E, Suite 230,  Seattle, WA 98102, USA

DIRECT: 1.206.512.1536
**CELL: **1.206.910.0973
FAX: 1.206.860.6972

                            SKYPE: chongsun.ahn.vr
                            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.

<Soldevelo_logo_EPS_CMYK.png>

                        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

– nick –

Nick Reid | nick.reid@villagereach.org

                                    *                                        Friendly Neighborhood <strike>Spiderman</strike>                                        , Information Systems Group*

VillageReach** ***
Starting at the Last Mile

                                   *                                         2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

                                  CELL: +1.510.410.0020

                                                                            SKYPE: nickdotreid

                                    [](http://www.villagereach.org/)

From: openlmis-dev@googlegroups.com on behalf of Brandon Bowersox-Johnsonbrandon.bowersox-johnson@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!

-Brandon

**From: **openlmis-dev@googlegroups.com on behalf of Josh Zamor josh.zamor@villagereach.org

                                  **Date: **                                      Wednesday, January 4, 2017 at 12:41 PM

                                  **To: **                                      Darius Jazayeri <djazayer@thoughtworks.com>

                                  **Cc: **                                      OpenLMIS Dev <openlmis-dev@googlegroups.com>

                                  **Subject: **                                      Re: [openlmis-dev] SonarQube Rule: Message Key guidelines
                              Whoops, correction.  Dot notation would yield something more like:

referencedata.error.product.dispensing.units.wrong

                                        On Jan 4, 2017, at 11:26 AM, Josh Zamor <                                            > wrote:
                                          It would not help find hardcoded messages unfortunately. 
                                            I should link to a real example that sonar is finding:

                                            Here we have dots, but then we also have hyphens.  The sonar rule would suggest we change this from:

referencedata.error.product.wrong-dispensing-units

to:

referencedata.error.product.wrongDispensingUnits

OR possibly

referencedata.error.product.wrong.dispensing.units

Best,

Josh

                                                  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)
  1.                                                       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).
    
  2.                                                       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

houghtWorks

                                        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

ThoughtWorks

  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).

www.villagereach.orgsbrudzinski@soldevelo.comwww.villagereach.orgdev@googlegroups.comjosh.zamor@villagereach.orghttp://sonar.openlmis.org/issues/search#issues=AVlpeqXiQzhzMx5vMFp9djazayer@thoughtworks.comjosh.zamor@villagereach.orghttp://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:[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

https://groups.google.com/d/msgid/openlmis-dev/84ACE850-F362-45DF-A168-4DF945938C31%40villagereach.org.djazayeri@thoughtworks.comhttps://groups.google.com/d/msgid/openlmis-dev/CAOKb-R6TGa4uQ_jZ4%3D_1acLqyieU80mHKXQ9ZUQxyUWGu-STsw%40mail.gmail.com
https://groups.google.com/d/optout

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

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

llewczynski@soldevelo.com
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

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 .

sbrudzinski@soldevelo.com
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?

-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.
                              Chongsun Ahn | chongsun.ahn@villagereach.org
  •                                Software Development Engineer*
    

Village****Reach* *Starting at the Last Mile

                                2900 Eastlake Ave. E, Suite 230,  Seattle, WA 98102, USA

DIRECT: 1.206.512.1536
**CELL: **1.206.910.0973
FAX: 1.206.860.6972

                              SKYPE: chongsun.ahn.vr
                              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.

<Soldevelo_logo_EPS_CMYK.png>

                          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

– nick –

Nick Reid | nick.reid@villagereach.org

                                      *                                          Friendly Neighborhood <strike>Spiderman</strike>                                          , Information Systems Group*

VillageReach** *** Starting at the Last Mile

                                     *                                           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!

-Brandon

**From: **openlmis-dev@googlegroups.com on behalf of Josh Zamor josh.zamor@villagereach.org

                                    **Date: **                                        Wednesday, January 4, 2017 at 12:41 PM

                                    **To: **                                        Darius Jazayeri <djazayer@thoughtworks.com>

                                    **Cc: **                                        OpenLMIS Dev <openlmis-dev@googlegroups.com>

                                    **Subject: **                                        Re: [openlmis-dev] SonarQube Rule: Message Key guidelines
                                Whoops, correction.  Dot notation would yield something more like:

referencedata.error.product.dispensing.units.wrong

                                          On Jan 4, 2017, at 11:26 AM, Josh Zamor <> wrote:
                                            It would not help find hardcoded messages unfortunately. 
                                              I should link to a real example that sonar is finding:
                                              Here we have dots, but then we also have hyphens.  The sonar rule would suggest we change this from:

referencedata.error.product.wrong-dispensing-units

to:

referencedata.error.product.wrongDispensingUnits

                                              OR possibly

referencedata.error.product.wrong.dispensing.units

Best,

Josh

                                                    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:
  1.                                                       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).
    
  2.                                                       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

houghtWorks

                                          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

ThoughtWorks

    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).

www.villagereach.orgsbrudzinski@soldevelo.comwww.villagereach.orgdev@googlegroups.com brandon.bowersox-johnson@villagereach.org
Sent:
To:
Subject: josh.zamor@villagereach.orghttp://sonar.openlmis.org/issues/search#issues=AVlpeqXiQzhzMx5vMFp9djazayer@thoughtworks.comjosh.zamor@villagereach.orghttp://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:[](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

https://groups.google.com/d/msgid/openlmis-dev/84ACE850-F362-45DF-A168-4DF945938C31%40villagereach.org.djazayeri@thoughtworks.comhttps://groups.google.com/d/msgid/openlmis-dev/CAOKb-R6TGa4uQ_jZ4%3D_1acLqyieU80mHKXQ9ZUQxyUWGu-STsw%40mail.gmail.com
https://groups.google.com/d/optout

openlmis-dev+unsubscribe@googlegroups.com
openlmis-dev@googlegroups.com
https://groups.google.com/d/msgid/openlmis-dev/5874A14F.5080100%40soldevelo.com
https://groups.google.com/d/optout

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.)

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?

-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.
                              Chongsun Ahn | chongsun.ahn@villagereach.org
  •                                Software Development Engineer*
    

Village****Reach* *Starting at the Last Mile

                                2900 Eastlake Ave. E, Suite 230,  Seattle, WA 98102, USA

DIRECT: 1.206.512.1536
**CELL: **1.206.910.0973
FAX: 1.206.860.6972

                              SKYPE: chongsun.ahn.vr

www.villagereach.org

                              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.

<Soldevelo_logo_EPS_CMYK.png>

                          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

– nick –

Nick Reid | nick.reid@villagereach.org

                                      *                                          Friendly Neighborhood <strike>Spiderman</strike>                                          , Information Systems Group*

VillageReach** *** Starting at the Last Mile

                                     *                                           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)

From: openlmis-dev@googlegroups.com openlmis-dev@googlegroups.com on behalf of Brandon Bowersox-Johnsonbrandon.bowersox-johnson@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!

-Brandon

**From: **openlmis-dev@googlegroups.com on behalf of Josh Zamor josh.zamor@villagereach.org

                                    **Date: **                                        Wednesday, January 4, 2017 at 12:41 PM

                                    **To: **                                        Darius Jazayeri <djazayer@thoughtworks.com>

                                    **Cc: **                                        OpenLMIS Dev <openlmis-dev@googlegroups.com>

                                    **Subject: **                                        Re: [openlmis-dev] SonarQube Rule: Message Key guidelines
                                Whoops, correction.  Dot notation would yield something more like:

referencedata.error.product.dispensing.units.wrong

                                          On Jan 4, 2017, at 11:26 AM, Josh Zamor <josh.zamor@villagereach.org                                              > wrote:
                                            It would not help find hardcoded messages unfortunately. 
                                              I should link to a real example that sonar is finding:

http://sonar.openlmis.org/issues/search#issues=AVlpeqXiQzhzMx5vMFp9

                                              Here we have dots, but then we also have hyphens.  The sonar rule would suggest we change this from:

referencedata.error.product.wrong-dispensing-units

to:

referencedata.error.product.wrongDispensingUnits

                                              OR possibly

referencedata.error.product.wrong.dispensing.units

Best,

Josh

                                                    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:
  1.                                                       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).
    
  2.                                                       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*

Email

djazayeri@thoughtworks.com

Telephone

+1 617 383 9369

houghtWorks

                                          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).

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/84ACE850-F362-45DF-A168-4DF945938C31%40villagereach.org.

Darius Jazayeri* Principal Architect - Global Health*
Email
djazayeri@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

    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.

-Brandon

···

From: openlmis-dev@googlegroups.com on behalf of Josh Zamor josh.zamor@villagereach.org

Date: Tuesday, January 10, 2017 at 1:12 PM

To: OpenLMIS Dev openlmis-dev@googlegroups.com

Subject: Re: [openlmis-dev] SonarQube Rule: Message Key guidelines

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

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

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?

-Darius

On Mon, Jan 9, 2017 at 3:13 PM, Chongsun Ahn chongsun.ahn@villagereach.org wrote:

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.

Chongsun Ahn | chongsun.ahn@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook, **Twitter ** and our Blog

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.

<Soldevelo_logo_EPS_CMYK.png>

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

Place of registration: Regional Court for the City of GdanskKRS: 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

– nick –

Nick Reid | nick.reid@villagereach.org

Friendly Neighborhood Spiderman, Information Systems Group

**VillageReach *** Starting at the Last Mile
*2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

CELL: +1.510.410.0020

SKYPE: nickdotreid

www.villagereach.org


From: openlmis-dev@googlegroups.com <openlmis-dev@googlegroups.com > on behalf of Brandon Bowersox-Johnsonbrandon.bowersox-johnson@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!

-Brandon

**From: **openlmis-dev@googlegroups.com on behalf of Josh Zamor josh.zamor@villagereach.org

**Date: **Wednesday, January 4, 2017 at 12:41 PM

**To: **Darius Jazayeri djazayer@thoughtworks.com

**Cc: **OpenLMIS Dev openlmis-dev@googlegroups.com

**Subject: **Re: [openlmis-dev] SonarQube Rule: Message Key guidelines

Whoops, correction. Dot notation would yield something more like:

referencedata.error.product.dispensing.units.wrong

On Jan 4, 2017, at 11:26 AM, Josh Zamor josh.zamor@villagereach.org wrote:

It would not help find hardcoded messages unfortunately.

I should link to a real example that sonar is finding:

http://sonar.openlmis.org/issues/search#issues=AVlpeqXiQzhzMx5vMFp9

Here we have dots, but then we also have hyphens. The sonar rule would suggest we change this from:

referencedata.error.product.wrong-dispensing-units

to:

referencedata.error.product.wrongDispensingUnits

OR possibly

referencedata.error.product.wrong.dispensing.units

Best,

Josh

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

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:

  1. 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).
    
  1. 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.

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.

For more options, visit https://groups.google.com/d/optout.

Darius JazayeriPrincipal Architect - Global Health

Email

djazayeri@thoughtworks.com

Telephone

+1 617 383 9369

oughtWorks

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.

For more options, visit 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.

For more options, visit 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.

For more options, visit 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.

For more options, visit 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/ab9db6db-d7b4-4dcd-6ce6-3da6c261b1f1%40soldevelo.com.

For more options, visit 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/84ACE850-F362-45DF-A168-4DF945938C31%40villagereach.org.

For more options, visit
https://groups.google.com/d/optout
.

Darius JazayeriPrincipal Architect - Global Health

Email

djazayeri@thoughtworks.com

Telephone

+1 617 383 9369

houghtWorks

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
.

For more options, visit
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
.

For more options, visit
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/83fbda6c-7cd7-42d4-aaf8-be130711bd6e%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

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.

Chongsun Ahn | chongsun.ahn@villagereach.org<mailto:chongsun.ahn@villagereach.org>
Software Development Engineer

VillageReach<http://villagereach.org/> Starting at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
DIRECT: 1.206.512.1536 CELL: 1.206.910.0973 FAX: 1.206.860.6972
SKYPE: chongsun.ahn.vr
www.villagereach.org<http://www.villagereach.org>
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<mailto: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<mailto:openlmis-dev@googlegroups.com>> on behalf of Josh Zamor <josh.zamor@villagereach.org<mailto:josh.zamor@villagereach.org>>
Date: Tuesday, January 10, 2017 at 1:12 PM
To: OpenLMIS Dev <openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>>
Subject: Re: [openlmis-dev] SonarQube Rule: Message Key guidelines

Agreed that there's nothing inherently wrong with hyphens or the style guide<https://github.com/OpenLMIS/openlmis-template-service/blob/master/STYLE-GUIDE.md> 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

[https://groups.google.com/group/openlmis-dev/attach/1db6a67fbad46/Soldevelo_logo_EPS_CMYK.png?part=0.1.1&authuser=1]<http://soldevelo.com/>

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com<mailto: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.

--

[https://groups.google.com/group/openlmis-dev/attach/1db6a67fbad46/?part=0.1.2&authuser=1]<http://soldevelo.com/>

Sebastian Brudziński
Software Developer / Team Leader
sbrudzinski@soldevelo.com<mailto: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.)

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?

-Darius

On Mon, Jan 9, 2017 at 3:13 PM, Chongsun Ahn <chongsun.ahn@villagereach.org<mailto:chongsun.ahn@villagereach.org>> wrote:
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.

Chongsun Ahn | chongsun.ahn@villagereach.org<mailto:chongsun.ahn@villagereach.org>
Software Development Engineer

VillageReach<http://villagereach.org/> Starting at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
DIRECT: 1.206.512.1536 CELL: 1.206.910.0973 FAX: 1.206.860.6972
SKYPE: chongsun.ahn.vr
www.villagereach.org<http://www.villagereach.org/>
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<mailto: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.

--
<Soldevelo_logo_EPS_CMYK.png><http://soldevelo.com/>
Sebastian Brudziński
Software Developer / Team Leader
sbrudzinski@soldevelo.com<mailto: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 GdanskKRS: 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

-- nick --

Nick Reid | nick.reid@villagereach.org<mailto:nick.reid@villagereach.org>
Friendly Neighborhood Spiderman, Information Systems Group

VillageReach<http://www.villagereach.org/> Starting at the Last Mile
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: openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com> <openlmis-<mailto:openlmis-dev@googlegroups.com>dev@googlegroups.com<mailto:dev@googlegroups.com>> on behalf of Brandon Bowersox-Johnson<brandon.bowersox-johnson@villagereach.org><mailto:brandon.bowersox-johnson@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!

-Brandon

From: <openlmis-dev@googlegroups.com><mailto:openlmis-dev@googlegroups.com> on behalf of Josh Zamor <josh.zamor@villagereach.org><mailto:josh.zamor@villagereach.org>
Date: Wednesday, January 4, 2017 at 12:41 PM
To: Darius Jazayeri <djazayer@thoughtworks.com><mailto:djazayer@thoughtworks.com>
Cc: OpenLMIS Dev <openlmis-dev@googlegroups.com><mailto:openlmis-dev@googlegroups.com>
Subject: Re: [openlmis-dev] SonarQube Rule: Message Key guidelines

Whoops, correction. Dot notation would yield something more like:

referencedata.error.product.dispensing.units.wrong

On Jan 4, 2017, at 11:26 AM, Josh Zamor <josh.zamor@villagereach.org<mailto:josh.zamor@villagereach.org>> wrote:

It would not help find hardcoded messages unfortunately.

I should link to a real example that sonar is finding:

http://sonar.openlmis.org/issues/search#issues=AVlpeqXiQzhzMx5vMFp9

Here we have dots, but then we also have hyphens. The sonar rule would suggest we change this from:

referencedata.error.product.wrong-dispensing-units

to:

referencedata.error.product.wrongDispensingUnits
OR possibly
referencedata.error.product.wrong.dispensing.units

Best,
Josh

On Jan 4, 2017, at 10:59 AM, Darius Jazayeri <djazayer@thoughtworks.com<mailto: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<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:

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:
1. 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>.
2. 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<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<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visit 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/>.com/d/optout.

--

Darius JazayeriPrincipal Architect - Global Health
Email
djazayeri@thoughtworks.com<mailto:djazayeri@thoughtworks.com>
Telephone
+1 617 383 9369
[oughtWorks]<http://www.thoughtworks.com/?utm_campaign=darius-jazayeri-signature&utm_medium=email&utm_source=thoughtworks-email-signature-generator>

--
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<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visit 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/>.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<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visit 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/>.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<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visit 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/>.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<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visit 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/>.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<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visit 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/>.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<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/84ACE850-F362-45DF-A168-4DF945938C31%40villagereach.org<http://40villagereach.org/>.

For more options, visit https://groups.google.com/d/optout.

--

Darius JazayeriPrincipal Architect - Global Health
Email
djazayeri@thoughtworks.com<mailto:djazayeri@thoughtworks.com>
Telephone
+1 617 383 9369
[houghtWorks]<http://www.thoughtworks.com/?utm_campaign=darius-jazayeri-signature&utm_medium=email&utm_source=thoughtworks-email-signature-generator>
--
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<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto: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.
For more options, visit 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<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto:openlmis-dev@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/5874A14F.5080100%40soldevelo.com.
For more options, visit 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<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto: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<https://groups.google.com/d/msgid/openlmis-dev/83fbda6c-7cd7-42d4-aaf8-be130711bd6e%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit 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<mailto:openlmis-dev+unsubscribe@googlegroups.com>.
To post to this group, send email to openlmis-dev@googlegroups.com<mailto: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<https://groups.google.com/d/msgid/openlmis-dev/14604057-297B-47F6-AA1E-E8A0D3C512AC%40villagereach.org?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

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: http://sonar.openlmis.org/coding_rules#rule_key=jproperties%3Akey-naming-convention

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.

Chongsun Ahn | chongsun.ahn@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

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 josh.zamor@villagereach.org

**Date: **Tuesday, January 10, 2017 at 1:12 PM

**To: **OpenLMIS Dev openlmis-dev@googlegroups.com

**Subject: **Re: [openlmis-dev] SonarQube Rule: Message Key guidelines

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

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

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

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?

-Darius

On Mon, Jan 9, 2017 at 3:13 PM, Chongsun Ahn chongsun.ahn@villagereach.org wrote:

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.

Chongsun Ahn | chongsun.ahn@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook, **Twitter ** and our Blog

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.

<Soldevelo_logo_EPS_CMYK.png>

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

Place of registration: Regional Court for the City of GdanskKRS: 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

– nick –

Nick Reid | nick.reid@villagereach.org

Friendly Neighborhood Spiderman, Information Systems Group

**VillageReach *** Starting at the Last Mile
*2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

CELL: +1.510.410.0020

SKYPE: nickdotreid

www.villagereach.org


From: openlmis-dev@googlegroups.com <openlmis-dev@googlegroups.com > on behalf of Brandon Bowersox-Johnsonbrandon.bowersox-johnson@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!

-Brandon

**From: **openlmis-dev@googlegroups.com on behalf of Josh Zamor josh.zamor@villagereach.org

**Date: **Wednesday, January 4, 2017 at 12:41 PM

**To: **Darius Jazayeri djazayer@thoughtworks.com

**Cc: **OpenLMIS Dev openlmis-dev@googlegroups.com

**Subject: **Re: [openlmis-dev] SonarQube Rule: Message Key guidelines

Whoops, correction. Dot notation would yield something more like:

referencedata.error.product.dispensing.units.wrong

On Jan 4, 2017, at 11:26 AM, Josh Zamor <josh.zamor@villagereach.org > wrote:

It would not help find hardcoded messages unfortunately.

I should link to a real example that sonar is finding:

http://sonar.openlmis.org/issues/search#issues=AVlpeqXiQzhzMx5vMFp9

Here we have dots, but then we also have hyphens. The sonar rule would suggest we change this from:

referencedata.error.product.wrong-dispensing-units

to:

referencedata.error.product.wrongDispensingUnits

OR possibly

referencedata.error.product.wrong.dispensing.units

Best,

Josh

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

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:

  1.  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). 
    
  1.  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.

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.

For more options, visit https://groups.google.com/d/optout.

Darius JazayeriPrincipal Architect - Global Health

Email

djazayeri@thoughtworks.com

Telephone

+1 617 383 9369

oughtWorks

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.

For more options, visit 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.

For more options, visit 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.

For more options, visit 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.

For more options, visit 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/ab9db6db-d7b4-4dcd-6ce6-3da6c261b1f1%40soldevelo.com.

For more options, visit 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/84ACE850-F362-45DF-A168-4DF945938C31%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

Darius JazayeriPrincipal Architect - Global Health

Email

djazayeri@thoughtworks.com

Telephone

+1 617 383 9369

houghtWorks

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.

For more options, visit 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.

For more options, visit 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/83fbda6c-7cd7-42d4-aaf8-be130711bd6e%40googlegroups.com.

For more options, visit 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/14604057-297B-47F6-AA1E-E8A0D3C512AC%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

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.

···

https://openlmis.atlassian.net/browse/OLMIS-1252
On Wednesday, 11 January 2017 23:56:09 UTC+1, Josh Zamor wrote:

    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

https://github.com/OpenLMIS/openlmis-template-service/blob/master/STYLE-GUIDE.md#i18n-naming-conventions

http://sonar.openlmis.org/coding_rules#rule_key=jproperties%3Akey-naming-convention

        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.
                        Chongsun Ahn | chongsun.ahn@villagereach.org
  •                          Software Development Engineer*
    

Village****Reach* *Starting at the Last Mile

                        2900 Eastlake Ave. E, Suite 230,  Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

                        SKYPE: chongsun.ahn.vr
                        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.)

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?

-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.
                                                      Chongsun Ahn | chongsun.ahn@villagereach.org
  •                                                      Software Development Engineer*
    

Village****Reach* ** Starting at the Last Mile*

                                                      2900 Eastlake Ave. E, Suite 230,  Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: ** 1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

                                                      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.

<Soldevelo_logo_EPS_CMYK.png>

** 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/)



                                              Place of registration: Regional Court for the City of GdanskKRS: 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
                                                      -- nick --

** Nick Reid** | nick.reid@villagereach.org

                                                      *                                                          Friendly Neighborhood <s>Spiderman</s>                                                          , Information Systems Group*

**VillageReach *** Starting at the Last Mile

                                                     *                                                           2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

                                                      CELL: +1.510.410.0020

                                                                                                                SKYPE: nickdotreid

                                                      [](http://www.villagereach.org/)

From: openlmis-dev@googlegroups.com <openlmis-dev@googlegroups.com > on behalf of Brandon Bowersox-Johnsonbrandon.bowersox-johnson@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!

-Brandon

**From: **openlmis-dev@googlegroups.com on behalf of Josh Zamor josh.zamor@villagereach.org

                                                      **Date: **                                                          Wednesday, January 4, 2017 at 12:41 PM

                                                      **To: **                                                          Darius Jazayeri <djazayer@thoughtworks.com>

                                                      **Cc: **                                                          OpenLMIS Dev <openlmis-dev@googlegroups.com>

                                                      **Subject: **                                                          Re: [openlmis-dev] SonarQube Rule: Message Key guidelines
                                                      Whoops, correction.  Dot notation would yield something more like: 

referencedata.error.product.dispensing.units.wrong

                                                      On Jan 4, 2017, at 11:26 AM, Josh Zamor <                                                          > wrote:
                                                      It would not help find hardcoded messages unfortunately.
                                                      I should link to a real example that sonar is finding:

issu

                                                      Here we have dots, but then we also have hyphens.  The sonar rule would suggest we change this from:

referencedata.error.product.wrong-dispensing-units

to:

referencedata.error.product.wrongDispensingUnits

                                                      OR possibly

referencedata.error.product.wrong.dispensing.units

Best,

Josh

                                                      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
  1.                                                           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). 
    
  1.                                                           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

oughtWorks

                                                      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*

Email

djazayeri@thoughtworks.com

Telephone

+1 617 383 9369

houghtWorks

                            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).

www.villagereach.orgjosh.zamor@villagereach.org
**Date: **
**To: **openlmis-dev@googlegroups.com>

                      **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)

https://groups.google.com/d/optout
plal@soldevelo.com