CodingStyleForOurPerlChanges - Revision history

FunPika: added Category:Development using HotCat

2014-03-15T15:33:12Z

← Older revision		Revision as of 15:33, 15 March 2014
Line 89:		Line 89:

	-audioguy		-audioguy

			[[Category:Development]]

50.45.173.166 at 21:00, 8 March 2014

2014-03-08T21:00:50Z

← Older revision		Revision as of 21:00, 8 March 2014
Line 1:		Line 1:
	[[Development]] - parent		[[Development]] - parent

			* This specifically applies to perl code, not Css, templates, or other non code areas.
			* This is meant to deal with the immediate situation, eventually can back off on this as docs improve.
			* paulej72 approval Sat Mar 8 2014

	I am about to make a change that will affect maybe two dozen perl pages. I think it might be a good idea to consider the manner in which we do this now.		I am about to make a change that will affect maybe two dozen perl pages. I think it might be a good idea to consider the manner in which we do this now.

50.45.173.166 at 20:41, 8 March 2014

2014-03-08T20:41:46Z

← Older revision		Revision as of 20:41, 8 March 2014
Line 1:		Line 1:
	[[Development]]		[[Development]] - parent

	I am about to make a change that will affect maybe two dozen perl pages. I think it might be a good idea to consider the manner in which we do this now.		I am about to make a change that will affect maybe two dozen perl pages. I think it might be a good idea to consider the manner in which we do this now.

50.45.173.166 at 20:41, 8 March 2014

2014-03-08T20:41:22Z

← Older revision		Revision as of 20:41, 8 March 2014
Line 1:		Line 1:
			[[Development]]

	I am about to make a change that will affect maybe two dozen perl pages. I think it might be a good idea to consider the manner in which we do this now.		I am about to make a change that will affect maybe two dozen perl pages. I think it might be a good idea to consider the manner in which we do this now.

50.45.173.166 at 20:25, 8 March 2014

2014-03-08T20:25:47Z

← Older revision		Revision as of 20:25, 8 March 2014
Line 40:		Line 40:
	</pre>		</pre>

	Which clearly sets off our code ~~chages~~ off from previous ones. The hashes are hard left.		Which clearly sets off our code changes off from previous ones. The hashes are hard left.
	This makes it easy to do a grep '^#' to find them, and if all our comments follow this pattern, easy to remove using automatic means like grep -v '^#'.		This makes it easy to do a grep '^#' to find them, and if all our comments follow this pattern, easy to remove using automatic means like grep -v '^#'.

50.45.173.166 at 20:23, 8 March 2014

2014-03-08T20:23:42Z

← Older revision		Revision as of 20:23, 8 March 2014
Line 1:		Line 1:
	I am about to make a change that will affect maybe two dozen perl pages. I think it might be a good idea to consider the manner in which we do this now.		I am about to make a change that will affect maybe two dozen perl pages. I think it might be a good idea to consider the manner in which we do this now.

	The initial days of this project were ~~pure terror~~, and it is understandable that changes were made quickly and without much in the way of comment or attribution. However, the threat level is now down a bit closer to '~~Pure~~ Panic'. So I think it wise to at least begin to consider this.		The initial days of this project were 'Pure Terror', and it is understandable that changes were made quickly and without much in the way of comment or attribution. However, the threat level is now down a bit closer to 'Solid Panic'. So I think it wise to at least begin to consider this.

	The existing code style is, well, lets just call it 'inconsistent' and the commenting style might charitably be described as 'spartan'.		The existing code style is, well, lets just call it 'inconsistent' and the commenting style might charitably be described as 'spartan'.

50.45.173.166 at 20:21, 8 March 2014

2014-03-08T20:21:14Z

← Older revision		Revision as of 20:21, 8 March 2014
Line 1:		Line 1:
	I am about to make a change that will affect maybe two dozen perl pages. I think it might be a good idea to consider manner in which we do this now.		I am about to make a change that will affect maybe two dozen perl pages. I think it might be a good idea to consider the manner in which we do this now.

	The initial days of this project were pure terror, and it is understandable that changes were made quickly and without much in the way of comment or attribution. However, the threat level is now down a bit closer to 'Pure Panic'. So I think it wise to at least begin to consider this.		The initial days of this project were pure terror, and it is understandable that changes were made quickly and without much in the way of comment or attribution. However, the threat level is now down a bit closer to 'Pure Panic'. So I think it wise to at least begin to consider this.
Line 32:		Line 32:

	The comment is bracketed by very visible hashes.		The comment is bracketed by very visible hashes.
			<pre>
	##########		##########
	#		#
Line 38:		Line 38:
	#		#
	##########		##########
			</pre>

	Which clearly sets off our code chages off from previous ones. The hashes are hard left.		Which clearly sets off our code chages off from previous ones. The hashes are hard left.
Line 43:		Line 44:

	The code itself is indented to match the proper indentation level for the existing code, so the visual flow of the code is not broken.		The code itself is indented to match the proper indentation level for the existing code, so the visual flow of the code is not broken.
			<pre>
	# Code added Fri Mar 7 23:22:47 PST 2014 - Mike Demmers		# Code added Fri Mar 7 23:22:47 PST 2014 - Mike Demmers
			</pre>
	The date of the change is clearly indicated, and who to blame. The date is just from 'date' and includes the time. The time, seemingly useless, is actually useful if seen as a unique identifier. I my case, I will be dding the same code to a number of files, so I will keep this header time the same for all of them. This means I can do a grep '23:22:47' *.pl and easiliy get a list of every file this change was made to at any time in the future.		The date of the change is clearly indicated, and who to blame. The date is just from 'date' and includes the time. The time, seemingly useless, is actually useful if seen as a unique identifier. I my case, I will be dding the same code to a number of files, so I will keep this header time the same for all of them. This means I can do a grep '23:22:47' *.pl and easiliy get a list of every file this change was made to at any time in the future.
			<pre>
	# to add a private slash option.		# to add a private slash option.
			</pre>
	Indicate what the general purpose of the code is.		Indicate what the general purpose of the code is.
			<pre>
	# If database table 'vars' variable 'private_site' != 0 then site is private		# If database table 'vars' variable 'private_site' != 0 then site is private
	# and all non-logged in users will be redirected to a login page.		# and all non-logged in users will be redirected to a login page.
			</pre>
	and exactly what it does to accomplish that.		and exactly what it does to accomplish that.
			<pre>
	# This code requires my $constants = getCurrentStatic(); declared earlier to		# This code requires my $constants = getCurrentStatic(); declared earlier to
	# insure the constant 'private_site' (set in admin interface, variables)		# insure the constant 'private_site' (set in admin interface, variables)
	# is available locally. ( also $user = getCurrentUser(); )		# is available locally. ( also $user = getCurrentUser(); )
			</pre>
	Indicate any requirements to make this code work. In this case, it MUST be added to certain pages or the whole scheme will fail, so this gives someone makimng a new page an idea of what must be done.		Indicate any requirements to make this code work. In this case, it MUST be added to certain pages or the whole scheme will fail, so this gives someone makimng a new page an idea of what must be done.
			<pre>
	# This routine must be added to all publicly available .pl scripts		# This routine must be added to all publicly available .pl scripts
	# (pages, not inclusions), just prior to the first header() call.		# (pages, not inclusions), just prior to the first header() call.
			</pre>
	If there important interactions with other code, let the reader know. Don't make the next coder have to go backtracing through routine after routine just to see where a variable came from, etc. Just tell them.		If there important interactions with other code, let the reader know. Don't make the next coder have to go backtracing through routine after routine just to see where a variable came from, etc. Just tell them.

50.45.173.166 at 20:19, 8 March 2014

2014-03-08T20:19:19Z

@@ Line 1: / Line 1: @@
-I am about to make a change that will affect maybe two dozen perl pages. I thinkit might be a good idea to consider style in how we do this now.
+I am about to make a change that will affect maybe two dozen perl pages. I think it might be a good idea to consider manner in which we do this now.
 The initial days of this project were pure terror, and it is understandable that changes were made quickly and without much in the way of comment or attribution. However, the threat level is now down a bit closer to 'Pure Panic'. So I think it wise to at least begin to consider this.
@@ Line 7: / Line 7: @@
 We have a mass of code which no one here had anything to do with the writing of, and which we do not yet fully understand.
-Given this, I suggest out commenting style should be a bit closer to 'voluminous' than 'spartan'. This will allow us to actually help each other as we try to make sense of this code.
+Given this, I suggest our commenting style should be a bit closer to 'voluminous' than 'spartan'. This will allow us to actually help each other as we try to make sense of this code.
-Here is a simple code change Iam about to make to many pages, with its comments, and I believe it may have some useful characteristics we might follow in the future:
+Here is a simple code change I am about to make to many pages, with its comments, and I believe it may have some useful characteristics we might follow in the future:
 <pre>
-</pre>
+# Code added Fri Mar  7 23:22:47 PST 2014 - Mike Demmers

50.45.173.166: Created page with "I am about to make a change that will affect maybe two dozen perl pages. I thinkit might be a good idea to consider style in how we do this now. The initial days of this proj..."

2014-03-08T19:52:12Z

Created page with "I am about to make a change that will affect maybe two dozen perl pages. I thinkit might be a good idea to consider style in how we do this now. The initial days of this proj..."

New page

I am about to make a change that will affect maybe two dozen perl pages. I thinkit might be a good idea to consider style in how we do this now.

The initial days of this project were pure terror, and it is understandable that changes were made quickly and without much in the way of comment or attribution. However, the threat level is now down a bit closer to 'Pure Panic'. So I think it wise to at least begin to consider this.

The existing code style is, well, lets just call it 'inconsistent' and the commenting style might charitably be described as 'spartan'.

We have a mass of code which no one here had anything to do with the writing of, and which we do not yet fully understand.

Given this, I suggest out commenting style should be a bit closer to 'voluminous' than 'spartan'. This will allow us to actually help each other as we try to make sense of this code.

Here is a simple code change Iam about to make to many pages, with its comments, and I believe it may have some useful characteristics we might follow in the future:

<pre>

</pre>