SonarQube Rule: Message Key guidelines

32 views
Skip to first unread message

Josh Zamor

unread,
Jan 4, 2017, 12:26:02 PM1/4/17
to OpenLMIS Dev
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.

Darius Jazayeri

unread,
Jan 4, 2017, 1:59:49 PM1/4/17
to Josh Zamor, OpenLMIS Dev
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

--
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 openlm...@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
ThoughtWorks

Josh Zamor

unread,
Jan 4, 2017, 2:26:17 PM1/4/17
to Darius Jazayeri, OpenLMIS Dev
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

Josh Zamor

unread,
Jan 4, 2017, 3:41:26 PM1/4/17
to Darius Jazayeri, OpenLMIS Dev
Whoops, correction.  Dot notation would yield something more like: 

referencedata.error.product.dispensing.units.wrong



To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

Brandon Bowersox-Johnson

unread,
Jan 4, 2017, 6:15:46 PM1/4/17
to OpenLMIS Dev

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

referencedata.error.product.dispensing.units.wrong

 

 

 

--

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.



 

--

 

Darius JazayeriPrincipal Architect - Global Health

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...@googlegroups.com.
To post to this group, send email to openlm...@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...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.

Nick Reid

unread,
Jan 5, 2017, 8:56:04 AM1/5/17
to Brandon Bowersox-Johnson, OpenLMIS Dev

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...@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: openlm...@googlegroups.com <openlm...@googlegroups.com> on behalf of Brandon Bowersox-Johnson <brandon.bowe...@villagereach.org>
Sent: Wednesday, January 4, 2017 3:15:43 PM
To: OpenLMIS Dev

Sebastian Brudziński

unread,
Jan 9, 2017, 6:02:23 PM1/9/17
to openlm...@googlegroups.com
Hello.

I'm OK with both options. My personal preference is no hyphens and camelCase, rather than multiple dots. I think keys with many dots are a little less readable and with less dots we can create a nice, hierarchical/logical structure.

Kind regards,
Sebastian.


--

Sebastian Brudziński
Software Developer / Team Leader
sbrud...@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

Chongsun Ahn

unread,
Jan 9, 2017, 6:14:01 PM1/9/17
to OpenLMIS Dev
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.

Software Development Engineer
 
VillageReach 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, Twitter and our Blog

On Jan 9, 2017, at 3:02 PM, Sebastian Brudziński <sbrud...@soldevelo.com> wrote:

Hello.

I'm OK with both options. My personal preference is no hyphens and camelCase, rather than multiple dots. I think keys with many dots are a little less readable and with less dots we can create a nice, hierarchical/logical structure. 

Kind regards,
Sebastian.

-- 
Sebastian Brudziński
Software Developer / Team Leader 
sbrud...@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
referencedata.error.product.dispensing.units.wrong
 
 
 
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.

Darius Jazayeri

unread,
Jan 9, 2017, 6:42:54 PM1/9/17
to Chongsun Ahn, OpenLMIS Dev
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 <chongs...@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.

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

referencedata.error.product.dispensing.units.wrong
 
 
 
 
-- 
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.


 
-- 
 
Darius JazayeriPrincipal Architect - Global Health
Telephone
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.
-- 
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.
-- 
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.
-- 
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.

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

--
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 openlm...@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
ThoughtWorks

Sebastian Brudziński

unread,
Jan 10, 2017, 3:54:41 AM1/10/17
to openlm...@googlegroups.com
Hi Darius,

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

Regards,
Sebastian.

--

Sebastian Brudziński
Software Developer / Team Leader
sbrud...@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

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

Łukasz Lewczyński

unread,
Jan 10, 2017, 4:24:57 AM1/10/17
to openlm...@googlegroups.com

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

Josh Zamor

unread,
Jan 10, 2017, 4:12:53 PM1/10/17
to 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

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.
Hey all,



--
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 openlm...@googlegroups.com.

Brandon Bowersox-Johnson

unread,
Jan 10, 2017, 6:31:02 PM1/10/17
to OpenLMIS Dev

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: <openlm...@googlegroups.com> on behalf of Josh Zamor <josh....@villagereach.org>
Date: Tuesday, January 10, 2017 at 1:12 PM
To: OpenLMIS Dev <openlm...@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.

Hey all,

 

Chongsun Ahn | chongs...@villagereach.org

Nick Reid | nick...@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: openlm...@googlegroups.com <openlmis-d...@googlegroups.com> on behalf of Brandon Bowersox-Johnson<brandon.bowe...@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

 

 


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

To: Darius Jazayeri <djaz...@thoughtworks.com>
Cc: OpenLMIS Dev <openlm...@googlegroups.com>

referencedata.error.product.dispensing.units.wrong

 

 

 

1.