Coding conventions - Revision history

Brad Berg at 17:17, 19 April 2010

2010-04-19T17:17:56Z

← Older revision		Revision as of 17:17, 19 April 2010
Line 5:		Line 5:
	* Future users of your code can't read your mind, so it must be organized and well-documented.		* Future users of your code can't read your mind, so it must be organized and well-documented.


	~~== Quick Start Instructions ==~~

	~~If you are comfortable in setting up your own programming environment you can follow these quick start instructions.~~

	~~[[Quick Start for Linux in CIT]]~~

	== File Permissions ==		== File Permissions ==

Trevor O'Brien at 15:23, 19 April 2010

2010-04-19T15:23:09Z

@@ Line 71: / Line 71: @@
 * <tt>chmod</tt> --- change the permissions for a file or directory
 * <tt>chown</tt> --- change the owner of a file or directory (only allowed if you are the owner)
 == Development Best Practices ==

Trevor O'Brien: Coding conventions and best practices moved to Coding conventions: Long page names are lousy.

2010-04-19T15:18:15Z

Coding conventions and best practices moved to Coding conventions: Long page names are lousy.

← Older revision	Revision as of 15:18, 19 April 2010
(No difference)

Trevor O'Brien: Get started on software development moved to Coding conventions and best practices: Reorganization of the software development section of the vrl home page.

2010-04-19T15:17:40Z

Get started on software development moved to Coding conventions and best practices: Reorganization of the software development section of the vrl home page.

← Older revision		Revision as of 15:17, 19 April 2010
(No difference)

Brad Berg at 15:01, 19 April 2010

2010-04-19T15:01:25Z

← Older revision		Revision as of 15:01, 19 April 2010
Line 79:		Line 79:

	Source control works by allowing an individual user to make structured copies of the master versions of files (this process is called "checking out" the files). The user then modifies his or her personal copies of the files, and then "checks in" the changes once they're certain that the code compiles and runs properly. The location where a user modifies a personal copy of shared code is called a "sandbox", because it is in some sense walled off from the master copy: destructive changes to the code in the sandbox do not affect the master copy, provided the user doesn't check them in.		Source control works by allowing an individual user to make structured copies of the master versions of files (this process is called "checking out" the files). The user then modifies his or her personal copies of the files, and then "checks in" the changes once they're certain that the code compiles and runs properly. The location where a user modifies a personal copy of shared code is called a "sandbox", because it is in some sense walled off from the master copy: destructive changes to the code in the sandbox do not affect the master copy, provided the user doesn't check them in.


	=== Access to CVS ===		=== Access to CVS ===

			Environment variables are used to configure the development environment. General instructions for setting up environment variables and using them.

			[[Setting Environment Variables]]


	Linux: <code>CVSROOT is /map/gfx0/cvsroot/</code>		Linux: <code>CVSROOT is /map/gfx0/cvsroot/</code>

Brad Berg: /* Quick Start Instructions */

2010-04-19T13:42:47Z

Quick Start Instructions

← Older revision		Revision as of 13:42, 19 April 2010
Line 10:		Line 10:
	If you are comfortable in setting up your own programming environment you can follow these quick start instructions.		If you are comfortable in setting up your own programming environment you can follow these quick start instructions.

	[[Quick Start for Linux ~~at Brown~~]]		[[Quick Start for Linux in CIT]]


	== File Permissions ==		== File Permissions ==

Brad Berg at 13:42, 19 April 2010

2010-04-19T13:42:08Z

← Older revision		Revision as of 13:42, 19 April 2010
Line 4:		Line 4:
	* Future users of your code need read and write permission; and		* Future users of your code need read and write permission; and
	* Future users of your code can't read your mind, so it must be organized and well-documented.		* Future users of your code can't read your mind, so it must be organized and well-documented.


			== Quick Start Instructions ==

			If you are comfortable in setting up your own programming environment you can follow these quick start instructions.

			[[Quick Start for Linux at Brown]]

Brad Berg: /* Access to CVS */

2010-04-19T13:34:35Z

Access to CVS

← Older revision		Revision as of 13:34, 19 April 2010
Line 75:		Line 75:

	=== Access to CVS ===		=== Access to CVS ===
	On Linux ~~set~~: <code>~~setenvvar~~ CVSROOT /map/gfx0/cvsroot/</code>
			Linux: <code>CVSROOT is /map/gfx0/cvsroot/</code>

	On Windows set CVSROOT to: <code>Y:\map\gfx0\cvsroot\</code>		On Windows set CVSROOT to: <code>Y:\map\gfx0\cvsroot\</code>


	=== Setting up <tt>$G</tt> ===		=== Setting up <tt>$G</tt> ===

Brad Berg: /* Development Environment */

2010-04-19T13:31:19Z

Development Environment

← Older revision		Revision as of 13:31, 19 April 2010
Line 70:		Line 70:
	The graphics group has developed a system over many years that allows easy development of a large, shared base of software. We give the whole thing the nickname <tt>[[$G]]</tt> ("dollar gee"), named after the environment variable that represents the root of the source tree.		The graphics group has developed a system over many years that allows easy development of a large, shared base of software. We give the whole thing the nickname <tt>[[$G]]</tt> ("dollar gee"), named after the environment variable that represents the root of the source tree.

	There ~~is a single "master" copy in <tt>$G</tt> of all the shared~~ source code our group has created~~, and it~~ is modified and backed up through a source control system called CVS (Concurrent Versioning System). You must have CVS set up properly in order to develop with our shared codebase.		There source code our group has created is modified and backed up through a source control system called CVS (Concurrent Versioning System). You must have CVS set up properly in order to develop with our shared codebase.

	Source control works by allowing an individual user to make structured copies of the master versions of files (this process is called "checking out" the files). The user then modifies his or her personal copies of the files, and then "checks in" the changes once they're certain that the code compiles and runs properly. The location where a user modifies a personal copy of shared code is called a "sandbox", because it is in some sense walled off from the master copy: destructive changes to the code in the sandbox do not affect the master copy, provided the user doesn't check them in.		Source control works by allowing an individual user to make structured copies of the master versions of files (this process is called "checking out" the files). The user then modifies his or her personal copies of the files, and then "checks in" the changes once they're certain that the code compiles and runs properly. The location where a user modifies a personal copy of shared code is called a "sandbox", because it is in some sense walled off from the master copy: destructive changes to the code in the sandbox do not affect the master copy, provided the user doesn't check them in.

Brad Berg: /* Setting Environment Variables */

2010-04-16T20:08:25Z

Setting Environment Variables

@@ Line 110: / Line 110: @@
 === Setting Environment Variables ===
-A detailed description of the environment variables is in:
+ GARCH = WIN32           # Use this setting on Windows.
 == Development Best Practices ==