<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: PL/SQL Cop for Trivadis Coding Guidelines Version 3.2	</title>
	<atom:link href="https://www.salvis.com/blog/2017/02/06/plsql-cop-for-trivadis-plsql-sql-coding-guidelines-version-3-2/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.salvis.com/blog/2017/02/06/plsql-cop-for-trivadis-plsql-sql-coding-guidelines-version-3-2/</link>
	<description>Database-centric development</description>
	<lastBuildDate>Tue, 07 Nov 2023 22:12:28 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.4</generator>
<atom:link rel="hub" href="https://pubsubhubbub.appspot.com"/>
<atom:link rel="hub" href="https://pubsubhubbub.superfeedr.com"/>
<atom:link rel="hub" href="https://websubhub.com/hub"/>
<atom:link rel="self" href="https://www.salvis.com/blog/2017/02/06/plsql-cop-for-trivadis-plsql-sql-coding-guidelines-version-3-2/feed/"/>
	<item>
		<title>
		By: Philipp Salvisberg		</title>
		<link>https://www.salvis.com/blog/2017/02/06/plsql-cop-for-trivadis-plsql-sql-coding-guidelines-version-3-2/#comment-3996</link>

		<dc:creator><![CDATA[Philipp Salvisberg]]></dc:creator>
		<pubDate>Thu, 20 Jul 2017 17:28:55 +0000</pubDate>
		<guid isPermaLink="false">https://www.salvis.com/blog/?p=7383#comment-3996</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://www.salvis.com/blog/2017/02/06/plsql-cop-for-trivadis-plsql-sql-coding-guidelines-version-3-2/#comment-3995&quot;&gt;Volker Bartuseck&lt;/a&gt;.

Hi Volker,

Regarding the G-7110 issue, there was already a question in the forum. See https://www.salvis.com/blog/forum/plsql-cop/initializing-nested-table-g-7110/

Regarding the G-1050 issue. 2 and &#039;close cur_testvg_scorewerte&#039; are both literals. According to to the guideline you should consider using constants instead of literals. However, I really understand that it is too much to 100% avoid literals. So either user the NOSONAR marker to disable the check within the code ore disable this guideline check completely.

HTH
Philipp]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://www.salvis.com/blog/2017/02/06/plsql-cop-for-trivadis-plsql-sql-coding-guidelines-version-3-2/#comment-3995">Volker Bartuseck</a>.</p>
<p>Hi Volker,</p>
<p>Regarding the G-7110 issue, there was already a question in the forum. See <a href="https://www.salvis.com/blog/forum/plsql-cop/initializing-nested-table-g-7110/" rel="ugc">https://www.salvis.com/blog/forum/plsql-cop/initializing-nested-table-g-7110/</a></p>
<p>Regarding the G-1050 issue. 2 and &#8216;close cur_testvg_scorewerte&#8217; are both literals. According to to the guideline you should consider using constants instead of literals. However, I really understand that it is too much to 100% avoid literals. So either user the NOSONAR marker to disable the check within the code ore disable this guideline check completely.</p>
<p>HTH<br />
Philipp</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Volker Bartuseck		</title>
		<link>https://www.salvis.com/blog/2017/02/06/plsql-cop-for-trivadis-plsql-sql-coding-guidelines-version-3-2/#comment-3995</link>

		<dc:creator><![CDATA[Volker Bartuseck]]></dc:creator>
		<pubDate>Thu, 20 Jul 2017 16:22:31 +0000</pubDate>
		<guid isPermaLink="false">https://www.salvis.com/blog/?p=7383#comment-3995</guid>

					<description><![CDATA[Hi Philipp

I&#039;m new to PL/SQL Cop and tried it on a short package for testing purpose.

There are two repeating incidents in the list and one seems to be a mistake:

On &quot;SET tsw_tag1 = l_testvb_scorewerte(i).tsw_tag1&quot; inside an update statement I get the error &quot;G-7110: Try to use named notation when calling program units.&quot; which is definitely wrong, because it is an index access to a collection.

The second error reported &quot;G-1050: Avoid using literals in your code.&quot; happens on two different occasions:

 	WHEN 2 THEN
 	tsp_exception.melde_debug(p_text =&#062; &#039;close cur_testvb_scorewerte&#039;);

The error is ok in principle, but within the context it should be ignored. Is there an easy way not to ignore the whole error, but only within a certain context?

&#160;

Regards

Volker]]></description>
			<content:encoded><![CDATA[<p>Hi Philipp</p>
<p>I&#8217;m new to PL/SQL Cop and tried it on a short package for testing purpose.</p>
<p>There are two repeating incidents in the list and one seems to be a mistake:</p>
<p>On &#8220;SET tsw_tag1 = l_testvb_scorewerte(i).tsw_tag1&#8221; inside an update statement I get the error &#8220;G-7110: Try to use named notation when calling program units.&#8221; which is definitely wrong, because it is an index access to a collection.</p>
<p>The second error reported &#8220;G-1050: Avoid using literals in your code.&#8221; happens on two different occasions:</p>
<p> 	WHEN 2 THEN<br />
 	tsp_exception.melde_debug(p_text =&gt; &#8216;close cur_testvb_scorewerte&#8217;);</p>
<p>The error is ok in principle, but within the context it should be ignored. Is there an easy way not to ignore the whole error, but only within a certain context?</p>
<p>&nbsp;</p>
<p>Regards</p>
<p>Volker</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Philipp Salvisberg		</title>
		<link>https://www.salvis.com/blog/2017/02/06/plsql-cop-for-trivadis-plsql-sql-coding-guidelines-version-3-2/#comment-3939</link>

		<dc:creator><![CDATA[Philipp Salvisberg]]></dc:creator>
		<pubDate>Tue, 28 Feb 2017 22:56:00 +0000</pubDate>
		<guid isPermaLink="false">https://www.salvis.com/blog/?p=7383#comment-3939</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://www.salvis.com/blog/2017/02/06/plsql-cop-for-trivadis-plsql-sql-coding-guidelines-version-3-2/#comment-3937&quot;&gt;Friedhold Matz&lt;/a&gt;.

Hello Friedhold,

Your welcome. First of all the table on page 8 shows a &quot;possible set of naming conventions.&quot;. Think of it as a starting position for your own naming conventions if you do not have them already. However, since we recommend to avoid declaring global variables public (see guideline 7230) it would be inconsistent to distinguish between public and &#039;modul&#039; scope of global variables.

The current version of PL/SQL Cop comes with two example validators for naming conventions. One implementing the 15 guidelines on page 8 and another one with just 3 simple guidelines:
&lt;ul&gt;
 	&lt;li&gt;&#039;g_&#039; for global variables&lt;/li&gt;
 	&lt;li&gt;&#039;l_&#039; for local variables&lt;/li&gt;
 	&lt;li&gt;&#039;p_&#039; for all kind of parameters&lt;/li&gt;
&lt;/ul&gt;
I also see &quot;in&quot;, &quot;out&quot; and &quot;io&quot; used as parameter suffix. So, please continue to use your set of naming conventions as long as it fits your needs.

Thanks,
Philipp]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://www.salvis.com/blog/2017/02/06/plsql-cop-for-trivadis-plsql-sql-coding-guidelines-version-3-2/#comment-3937">Friedhold Matz</a>.</p>
<p>Hello Friedhold,</p>
<p>Your welcome. First of all the table on page 8 shows a &#8220;possible set of naming conventions.&#8221;. Think of it as a starting position for your own naming conventions if you do not have them already. However, since we recommend to avoid declaring global variables public (see guideline 7230) it would be inconsistent to distinguish between public and &#8216;modul&#8217; scope of global variables.</p>
<p>The current version of PL/SQL Cop comes with two example validators for naming conventions. One implementing the 15 guidelines on page 8 and another one with just 3 simple guidelines:</p>
<ul>
<li>&#8216;g_&#8217; for global variables</li>
<li>&#8216;l_&#8217; for local variables</li>
<li>&#8216;p_&#8217; for all kind of parameters</li>
</ul>
<p>I also see &#8220;in&#8221;, &#8220;out&#8221; and &#8220;io&#8221; used as parameter suffix. So, please continue to use your set of naming conventions as long as it fits your needs.</p>
<p>Thanks,<br />
Philipp</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
