Integrics Wiki - User contributions [en-gb]

http://wiki.integrics.com/api.php?action=feedcontributions&feedformat=atom&user=Acunningham Integrics Wiki - User contributions [en-gb] 2026-05-06T21:46:31Z User contributions MediaWiki 1.31.7 http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=236 Coding Guidelines 2019-11-21T14:24:20Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** For normal text that will be read by humans, use sentence case without capital letters in the middle of sentences unless specifically required: This is a sample.<br /> ** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Use the Unix standard of the newline character ("\n") to terminate lines.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use $snake_case for variable names.<br /> ** Use snake_case for function names.<br /> ** Use CamelCase for package names.<br /> ** Use short variable names for hash references, particularly those created from database lookups.<br /> ** Use tabs for indentation.<br /> ** Leave a space after open brackets: if ( $variable ) {<br /> ** Leave a space before close brackets: if ( $variable ) {<br /> ** Leave a space after commas: function( $a, $b, $c );<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Do not leave a blank line after if, else, while, foreach, etc.<br /> ** Do not leave a blank line before solitary closing curly brackets.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** Use " => " between hash array keys and values, and ", " between values and keys.<br /> ** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Use brackets on built-in Perl functions which can optionally have brackets: scalar( @variable )<br /> ** Use @EXPORT for library functions that are intended to be public.<br /> ** Use @EXPORT_OK for library variables that are intended to be public.<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Use the "<condition> ? <if true> : <if false>" construct if thought appropriate.<br /> <br /> * Databases<br /> ** Use snake_case for column names.<br /> <br /> * Configuration files<br /> ** Use .ini format.<br /> ** Use single word lower-case section and key names were possible, or snake_case if multiple words are required.<br /> ** Use "true" and "false" for boolean values.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=235 Coding Guidelines 2019-11-21T14:23:21Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required: This is a sample.<br /> ** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Use the Unix standard of the newline character ("\n") to terminate lines.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use $snake_case for variable names.<br /> ** Use snake_case for function names.<br /> ** Use CamelCase for package names.<br /> ** Use short variable names for hash references, particularly those created from database lookups.<br /> ** Use tabs for indentation.<br /> ** Leave a space after open brackets: if ( $variable ) {<br /> ** Leave a space before close brackets: if ( $variable ) {<br /> ** Leave a space after commas: function( $a, $b, $c );<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Do not leave a blank line after if, else, while, foreach, etc.<br /> ** Do not leave a blank line before solitary closing curly brackets.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** Use " => " between hash array keys and values, and ", " between values and keys.<br /> ** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Use brackets on built-in Perl functions which can optionally have brackets: scalar( @variable )<br /> ** Use @EXPORT for library functions that are intended to be public.<br /> ** Use @EXPORT_OK for library variables that are intended to be public.<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Use the "<condition> ? <if true> : <if false>" construct if thought appropriate.<br /> <br /> * Databases<br /> ** Use snake_case for column names.<br /> <br /> * Configuration files<br /> ** Use .ini format.<br /> ** Use single word lower-case section and key names were possible, or snake_case if multiple words are required.<br /> ** Use "true" and "false" for boolean values.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=234 Coding Guidelines 2019-11-21T14:21:00Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required: This is a sample.<br /> ** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Use the Unix standard of the newline character ("\n") to terminate lines.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use $snake_case for variable names.<br /> ** Use snake_case for function names.<br /> ** Use CamelCase for package names.<br /> ** Use short variable names for hash references, particularly those created from database lookups.<br /> ** Use tabs for indentation.<br /> ** Leave a space after open brackets: if ( $variable ) {<br /> ** Leave a space before close brackets: if ( $variable ) {<br /> ** Leave a space after commas: function( $a, $b, $c );<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Do not leave a blank line after if, else, while, foreach, etc.<br /> ** Do not leave a blank line before solitary closing curly brackets.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** Use " => " between hash array keys and values, and ", " between values and keys.<br /> ** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Use brackets on built-in Perl functions which can optionally have brackets: scalar( @variable )<br /> ** Use @EXPORT for library functions that are intended to be public.<br /> ** Use @EXPORT_OK for library variables that are intended to be public.<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Use the "<condition> ? <if true> : <if false>" construct if thought appropriate.<br /> <br /> * Databases<br /> ** Use snake_case for column names.<br /> <br /> * Configuration files<br /> ** Use .ini format.<br /> ** Put files in /etc/enswitch if they're expected to be edited by system administrators, /opt/enswitch/current/etc if they're purely static.<br /> ** Use single word lower-case section and key names were possible, or snake_case if multiple words are required.<br /> ** Use "true" and "false" for boolean values.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=233 Coding Guidelines 2019-11-21T14:19:50Z

<p>Acunningham: Add section on configuration files</p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required: This is a sample.<br /> ** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Use the Unix standard of the newline character ("\n") to terminate lines.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use $snake_case for variable names.<br /> ** Use snake_case for function names.<br /> ** Use CamelCase for package names.<br /> ** Use short variable names for hash references, particularly those created from database lookups.<br /> ** Use tabs for indentation.<br /> ** Leave a space after open brackets: if ( $variable ) {<br /> ** Leave a space before close brackets: if ( $variable ) {<br /> ** Leave a space after commas: function( $a, $b, $c );<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Do not leave a blank line after if, else, while, foreach, etc.<br /> ** Do not leave a blank line before solitary closing curly brackets.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** Use " => " between hash array keys and values, and ", " between values and keys.<br /> ** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Use brackets on built-in Perl functions which can optionally have brackets: scalar( @variable )<br /> ** Use @EXPORT for library functions that are intended to be public.<br /> ** Use @EXPORT_OK for library variables that are intended to be public.<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Use the "<condition> ? <if true> : <if false>" construct if thought appropriate.<br /> <br /> * Databases<br /> ** Use snake_case for column names.<br /> <br /> * Configuration files<br /> ** Use .ini format.<br /> ** Stored in /etc/enswitch.<br /> ** Use single word lower-case section and key names were possible, or snake_case if multiple words are required.<br /> ** Use "true" and "false" for boolean values.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=230 Coding Guidelines 2019-08-04T23:01:26Z

<p>Acunningham: Add newline character as line terminator</p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required: This is a sample.<br /> ** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Use the Unix standard of the newline character ("\n") to terminate lines.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use $snake_case for variable names.<br /> ** Use snake_case for function names.<br /> ** Use CamelCase for package names.<br /> ** Use short variable names for hash references, particularly those created from database lookups.<br /> ** Use tabs for indentation.<br /> ** Leave a space after open brackets: if ( $variable ) {<br /> ** Leave a space before close brackets: if ( $variable ) {<br /> ** Leave a space after commas: function( $a, $b, $c );<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Do not leave a blank line after if, else, while, foreach, etc.<br /> ** Do not leave a blank line before solitary closing curly brackets.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** Use " => " between hash array keys and values, and ", " between values and keys.<br /> ** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Use brackets on built-in Perl functions which can optionally have brackets: scalar( @variable )<br /> ** Use @EXPORT for library functions that are intended to be public.<br /> ** Use @EXPORT_OK for library variables that are intended to be public.<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Use the "<condition> ? <if true> : <if false>" construct if thought appropriate.<br /> <br /> * Databases<br /> ** Use snake_case for column names.</div>

Acunningham http://wiki.integrics.com/index.php?title=Enswitch&diff=229 Enswitch 2019-08-04T22:59:39Z

<p>Acunningham: </p> <hr /> <div>[https://enswitch.com/ Enswitch] is [[Integrics]] Ltd's primary product.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=213 Coding Guidelines 2019-05-31T08:46:19Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required: This is a sample.<br /> ** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use $snake_case for variable names.<br /> ** Use snake_case for function names.<br /> ** Use CamelCase for package names.<br /> ** Use short variable names for hash references, particularly those created from database lookups.<br /> ** Use tabs for indentation.<br /> ** Leave a space after open brackets: if ( $variable ) {<br /> ** Leave a space before close brackets: if ( $variable ) {<br /> ** Leave a space after commas: function( $a, $b, $c );<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Do not leave a blank line after if, else, while, foreach, etc.<br /> ** Do not leave a blank line before solitary closing curly brackets.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** Use " => " between hash array keys and values, and ", " between values and keys.<br /> ** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Use brackets on built-in Perl functions which can optionally have brackets: scalar( @variable )<br /> ** Use @EXPORT for library functions that are intended to be public.<br /> ** Use @EXPORT_OK for library variables that are intended to be public.<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Use the "<condition> ? <if true> : <if false>" construct if thought appropriate.<br /> <br /> * Databases<br /> ** Use snake_case for column names.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=212 Coding Guidelines 2019-05-31T08:45:46Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required: This is a sample.<br /> ** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use $snake_case for variable names.<br /> ** Use snake_case for function names.<br /> ** Use CamelCase for package names.<br /> ** Use short variable names for hash references, particularly those created from database lookups.<br /> ** Use tabs for indentation.<br /> ** Leave a space after open brackets: if ( $variable ) {<br /> ** Leave a space before close brackets: if ( $variable ) {<br /> ** Leave a space after commas: function( $a, $b, $c );<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Do not leave a blank line after if, else, while, foreach, etc.<br /> ** Do not leave a blank line before solitary closing curly brackets.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** Use " => " between hash array keys and values, and ", " between values and keys.<br /> ** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Use brackets on built-in Perl functions which can optionally have brackets: scalar( @variable ).<br /> ** Use @EXPORT for library functions that are intended to be public.<br /> ** Use @EXPORT_OK for library variables that are intended to be public.<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Use the "<condition> ? <if true> : <if false>" construct if thought appropriate.<br /> <br /> * Databases<br /> ** Use snake_case for column names.</div>

Acunningham http://wiki.integrics.com/index.php?title=Security_Considerations&diff=206 Security Considerations 2018-12-15T00:35:28Z

<p>Acunningham: </p> <hr /> <div>Technical:<br /> * Disallow routes to countries that customers don't need, especially high fraud countries.<br /> * Set a daily spending limit and maximum concurrent calls limit for all customers.<br /> * Set the "Telephone line failed registrations lock" and "Person failed logins lock" system configurations to be non-zero.<br /> * Require long password lengths for phones and people.<br /> * Change the SSH port from 22 to something non standard.<br /> * Use iptables to lock out countries where you do not have customers.<br /> * Set Asterisk servers to use non default ports for SIP like 5065 instead of 5060.<br /> * Make sure all handsets have a username and password which are not the devices default.<br /> * Monitor servers with a tool like Zabbix, Nagios, or Cacti to alert if there are more calls than expected.<br /> <br /> Some systems have tools like SIPSentry to automatically block brute-force SIP attacks.<br /> <br /> Secure provisioning with a solution such as:<br /> * Use the source IP setting in Enswitch telephones.<br /> * Restrict access by user-agent.<br /> * Restrict access to a private domain.<br /> * Use HTTP basic authentication.<br /> * Use TFTP username and password authentications.<br /> <br /> Non-technical:<br /> * Educate customers on choosing good passwords.<br /> * Have contracts to make sure the right person pays if they are hacked and run up a huge bill.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=182 Coding Guidelines 2017-10-06T12:01:34Z

<p>Acunningham: Add databases section.</p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required: This is a sample.<br /> ** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use $snake_case for variable names.<br /> ** Use snake_case for function names.<br /> ** Use CamelCase for package names.<br /> ** Use short variable names for hash references, particularly those created from database lookups.<br /> ** Use tabs for indentation.<br /> ** Leave a space after open brackets: if ( $variable ) {<br /> ** Leave a space before close brackets: if ( $variable ) {<br /> ** Leave a space after commas: function( $a, $b, $c );<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Do not leave a blank line after if, else, while, foreach, etc.<br /> ** Do not leave a blank line before solitary closing curly brackets.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** Use " => " between hash array keys and values, and ", " between values and keys.<br /> ** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Use brackets on built-in Perl functions which can optionally have brackets: scalar( @variable )<br /> ** Use @EXPORT_OK rather than @EXPORT.<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Use the "<condition> ? <if true> : <if false>" construct if thought appropriate.<br /> <br /> * Databases<br /> ** Use snake_case for column names.</div>

Acunningham http://wiki.integrics.com/index.php?title=Adding_Area_Codes_To_Outbound_Calls&diff=181 Adding Area Codes To Outbound Calls 2017-09-29T09:36:51Z

<p>Acunningham: </p> <hr /> <div>To allow a Telephone line to make calls within its area code without having to dial the whole number:<br /> <br /> # Set the "Long distance match" configuration setting to something like "(^1|^011|^411$|^911$|^.{10,99}$)". These are numbers to NOT add the area code for.<br /> # Set the "Long distance match uses location callerid" configuration setting to No.<br /> # Under each inbound group set the area code (e.g. "716"). We recommend one inbound group per area code for this reason.<br /> # Note that the numbers in the inbound group must match the area code. So for an area code of "716" all numbers in that inbound group must begin with "716".<br /> # Make sure the telephone's external callerid is set to a number in an inbound group with area code configured.<br /> # Then when you dial a number from the telephone which doesn't match a system route, the area code of the inbound group of the external callerid is prefixed to the dialled number, and that is checked for a system route.<br /> <br /> You can also set "Long distance match uses location callerid" set to Yes if you wish to use the location caller ID instead of the external caller ID.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=177 Coding Guidelines 2017-08-09T09:03:11Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required: This is a sample.<br /> ** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use $snake_case for variable names.<br /> ** Use snake_case for function names.<br /> ** Use CamelCase for package names.<br /> ** Use short variable names for hash references, particularly those created from database lookups.<br /> ** Use tabs for indentation.<br /> ** Leave a space after open brackets: if ( $variable ) {<br /> ** Leave a space before close brackets: if ( $variable ) {<br /> ** Leave a space after commas: function( $a, $b, $c );<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Do not leave a blank line after if, else, while, foreach, etc.<br /> ** Do not leave a blank line before solitary closing curly brackets.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** Use " => " between hash array keys and values, and ", " between values and keys.<br /> ** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Use brackets on built-in Perl functions which can optionally have brackets: scalar( @variable )<br /> ** Use @EXPORT_OK rather than @EXPORT.<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Use the "<condition> ? <if true> : <if false>" construct if thought appropriate.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=176 Coding Guidelines 2017-08-07T14:12:19Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required: This is a sample.<br /> ** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use $snake_case for variable names.<br /> ** Use CamelCase for package names.<br /> ** Use short variable names for hash references, particularly those created from database lookups.<br /> ** Use tabs for indentation.<br /> ** Leave a space after open brackets: if ( $variable ) {<br /> ** Leave a space before close brackets: if ( $variable ) {<br /> ** Leave a space after commas: function( $a, $b, $c );<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Do not leave a blank line after if, else, while, foreach, etc.<br /> ** Do not leave a blank line before solitary closing curly brackets.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** Use " => " between hash array keys and values, and ", " between values and keys.<br /> ** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Use brackets on built-in Perl functions which can optionally have brackets: scalar( @variable )<br /> ** Use @EXPORT_OK rather than @EXPORT.<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Use the "<condition> ? <if true> : <if false>" construct if thought appropriate.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=175 Coding Guidelines 2017-08-07T14:11:39Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required: This is a sample.<br /> ** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use $snake_case for variable names.<br /> ** Use CamelCase for package names.<br /> ** Use short variable names for hash references, particularly those created from database lookups.<br /> ** Use tabs for indentation.<br /> ** Leave a space after open brackets: if ( $variable ) {<br /> ** Leave a space before close brackets: if ( $variable ) {<br /> ** Leave a space after commas: function( $a, $b, $c );<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Do not leave a blank line after if, else, while, foreach, etc.<br /> ** Do not leave a blank line before solitary closing curly brackets.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** Use " => " between hash array keys and values, and ", " between values and keys.<br /> ** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Use brackets on built-in Perl functions which can optionally have brackets, such as scalar(): scalar( @variable )<br /> ** Use @EXPORT_OK rather than @EXPORT.<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Use the "<condition> ? <if true> : <if false>" construct if thought appropriate.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=174 Coding Guidelines 2017-08-07T14:10:42Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required: This is a sample.<br /> ** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use $snake_case for variable names.<br /> ** Use CamelCase for package names.<br /> ** Use tabs for indentation.<br /> ** Leave a space after open brackets: if ( $variable ) {<br /> ** Leave a space before close brackets: if ( $variable ) {<br /> ** Leave a space after commas: function( $a, $b, $c );<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Do not leave a blank line after if, else, while, foreach, etc.<br /> ** Do not leave a blank line before solitary closing curly brackets.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Use brackets on built-in Perl functions which can optionally have brackets, such as scalar(): scalar( @variable )<br /> ** Use @EXPORT_OK rather than @EXPORT.<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Use " => " between hash array keys and values, and ", " between values and keys.<br /> ** Use short variable names for hash references, particularly those created from database lookups.<br /> ** Use the "<condition> ? <if true> : <if false>" construct if thought appropriate.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=173 Coding Guidelines 2017-08-07T14:09:39Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required: This is a sample.<br /> ** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use $snake_case for variable names.<br /> ** Use CamelCase for package names.<br /> ** Use tabs for indentation.<br /> ** Leave a space after open brackets: if ( $variable ) {<br /> ** Leave a space before close brackets: if ( $variable ) {<br /> ** Leave a space after commas: function( $a, $b, $c );<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Do not leave a blank line after if, else, while, foreach, etc.<br /> ** Do not leave a blank line before solitary closing curly brackets.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Use brackets on built-in Perl functions which can optionally have brackets, such as scalar(): scalar( @variable )<br /> ** Use @EXPORT_OK rather than @EXPORT.<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Use " => " between hash array keys and values, and ", " between values and keys.<br /> ** Use short variable names for hash references, particularly those created from database lookups.<br /> ** Use the Perl "<condition> ? <if true> : <if false>" construct if thought appropriate.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=172 Coding Guidelines 2017-08-07T14:09:22Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required: This is a sample.<br /> ** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use $snake_case for variables.<br /> ** Use CamelCase for package names.<br /> ** Use tabs for indentation.<br /> ** Leave a space after open brackets: if ( $variable ) {<br /> ** Leave a space before close brackets: if ( $variable ) {<br /> ** Leave a space after commas: function( $a, $b, $c );<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Do not leave a blank line after if, else, while, foreach, etc.<br /> ** Do not leave a blank line before solitary closing curly brackets.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Use brackets on built-in Perl functions which can optionally have brackets, such as scalar(): scalar( @variable )<br /> ** Use @EXPORT_OK rather than @EXPORT.<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Use " => " between hash array keys and values, and ", " between values and keys.<br /> ** Use short variable names for hash references, particularly those created from database lookups.<br /> ** Use the Perl "<condition> ? <if true> : <if false>" construct if thought appropriate.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=171 Coding Guidelines 2017-08-05T19:07:57Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required: This is a sample.<br /> ** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use tabs instead of spaces for indentation.<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Leave a space after open brackets: if ( $variable ) {<br /> ** Leave a space before close brackets: if ( $variable ) {<br /> ** Leave a space after commas: function( $a, $b, $c );<br /> ** Do not leave a blank line after if, while, foreach, else, etc.<br /> ** Do not leave a blank line before solitary closing curly brackets.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Use brackets on built-in Perl functions which can optionally have brackets, such as scalar(): scalar( @variable )<br /> ** Use @EXPORT_OK rather than @EXPORT.<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Use " => " between hash array keys and values, and ", " between values and keys.<br /> ** Use short variable names for hash references, particularly those created from database lookups.<br /> ** Use the Perl "<condition> ? <if true> : <if false>" construct if thought appropriate.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=170 Coding Guidelines 2017-08-05T08:26:25Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required: This is a sample.<br /> ** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use tabs instead of spaces for indentation.<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Leave a space after open brackets: if ( $variable ) {<br /> ** Leave a space before close brackets: if ( $variable ) {<br /> ** Leave a space after commas: function( $a, $b, $c );<br /> ** Leave a blank line before if and else.<br /> ** Do not leave a blank line after if, while, foreach, else, etc.<br /> ** Do not leave a blank line before closing curly brackets of blocks.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Use brackets on built-in Perl functions which can optionally have brackets, such as scalar(): scalar( @variable )<br /> ** Use @EXPORT_OK rather than @EXPORT.<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Use " => " between hash array keys and values, and ", " between values and keys.<br /> ** Use short variable names for hash references, particularly those created from database lookups.<br /> ** Use the Perl "<condition> ? <if true> : <if false>" construct if thought appropriate.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=169 Coding Guidelines 2017-08-05T08:22:22Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required: This is a sample.<br /> ** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use tabs instead of spaces for indentation.<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Leave a space after open brackets: if ( $variable ) {<br /> ** Leave a space before close brackets: if ( $variable ) {<br /> ** Leave a space after commas: function( $a, $b, $c );<br /> ** Leave a blank line before if and else.<br /> ** Do not leave a blank line after if, while, foreach, else, etc.<br /> ** Do not leave a blank line before closing curly brackets of blocks.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Built-in Perl functions which can optionally have brackets, such as scalar(), should normally have brackets: scalar( @variable )<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Hash references, especially those created from database lookups, are typically given one or two character names.<br /> ** Enumerated hash arrays should use " => " between keys and values, and ", " between values and keys.<br /> ** Use of the Perl "<condition> ? <if true> : <if false>" construct is encouraged where thought appropriate.<br /> ** Libraries should normally use @EXPORT_OK rather than @EXPORT.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=168 Coding Guidelines 2017-08-05T08:20:42Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required: This is a sample.<br /> ** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use tabs instead of spaces for indentation.<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Leave a space after open bracket: if ( $variable ) {<br /> ** Leave a space before close bracket: if ( $variable ) {<br /> ** Leave a blank line before if and else.<br /> ** Do not leave a blank line after if, while, foreach, else, etc.<br /> ** Do not leave a blank line before closing curly brackets of blocks.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Built-in Perl functions which can optionally have brackets, such as scalar(), should normally have brackets: scalar( @variable )<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Hash references, especially those created from database lookups, are typically given one or two character names.<br /> ** Enumerated hash arrays should use " => " between keys and values, and ", " between values and keys.<br /> ** Use of the Perl "<condition> ? <if true> : <if false>" construct is encouraged where thought appropriate.<br /> ** Libraries should normally use @EXPORT_OK rather than @EXPORT.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=167 Coding Guidelines 2017-08-05T08:14:26Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required.<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use tabs instead of spaces for indentation.<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Leave a space after open bracket: if ( $variable ) {<br /> ** Leave a space before close bracket: if ( $variable ) {<br /> ** Leave a blank line before if and else.<br /> ** Do not leave a blank line after if, while, foreach, else, etc.<br /> ** Do not leave a blank line before closing curly brackets of blocks.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Built-in Perl functions which can optionally have brackets, such as scalar(), should normally have brackets: scalar( @variable )<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Hash references, especially those created from database lookups, are typically given one or two character names.<br /> ** Enumerated hash arrays should use " => " between keys and values, and ", " between values and keys.<br /> ** Use of the Perl "<condition> ? <if true> : <if false>" construct is encouraged where thought appropriate.<br /> ** Perl libraries should normally use @EXPORT_OK rather than @EXPORT.<br /> ** Libraries should where possible name their functions starting with <library>_.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=166 Coding Guidelines 2017-08-05T08:13:08Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required.<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use tabs instead of spaces for indentation.<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Leave a space after open bracket: if ( $variable ) {<br /> ** Leave a space before close bracket: if ( $variable ) {<br /> ** Leave a blank line before if and else.<br /> ** Do not leave a blank line after if, while, foreach, else, etc.<br /> ** Do not leave a blank line before closing curly brackets of blocks.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** If a list is very long, it should be spread across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Built-in Perl functions which can optionally have brackets, such as scalar(), should normally have brackets: scalar( @variable )<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Hash references, especially those created from database lookups, are typically given one or two character names.<br /> ** Enumerated hash arrays should use " => " between keys and values, and ", " between values and keys.<br /> ** Use of the Perl "<condition> ? <if true> : <if false>" construct is encouraged where thought appropriate.<br /> ** Perl libraries should normally use @EXPORT_OK rather than @EXPORT.<br /> ** Libraries should where possible name their functions starting with <library>_.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=162 Coding Guidelines 2017-08-04T17:06:16Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required.<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use tabs instead of spaces for indentation.<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Leave a space after open bracket: if ( $variable ) {<br /> ** Leave a space before close bracket: if ( $variable ) {<br /> ** Do not leave a blank line after if, while, foreach, else, etc.<br /> ** Do not leave a blank line before closing curly brackets of blocks.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** If a list is very long, it should be spread across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Built-in Perl functions which can optionally have brackets, such as scalar(), should normally have brackets: scalar( @variable )<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Hash references are normally given very short names, typically one letter, or two if necessary to be unambiguous.<br /> ** Enumerated hash arrays should use " => " between keys and values, and ", " between values and keys.<br /> ** Use of the Perl "<condition> ? <if true> : <if false>" construct is encouraged where thought appropriate.<br /> ** Perl libraries should normally use @EXPORT_OK rather than @EXPORT.<br /> ** Libraries should where possible name their functions starting with <library>_.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=161 Coding Guidelines 2017-08-04T17:05:44Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use tabs instead of spaces for indentation.<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Leave a space after open bracket: if ( $variable ) {<br /> ** Leave a space before close bracket: if ( $variable ) {<br /> ** Do not leave a blank line after if, while, foreach, else, etc.<br /> ** Do not leave a blank line before closing curly brackets of blocks.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** If a list is very long, it should be spread across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Built-in Perl functions which can optionally have brackets, such as scalar(), should normally have brackets: scalar( @variable )<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Hash references are normally given very short names, typically one letter, or two if necessary to be unambiguous.<br /> ** Enumerated hash arrays should use " => " between keys and values, and ", " between values and keys.<br /> ** Use of the Perl "<condition> ? <if true> : <if false>" construct is encouraged where thought appropriate.<br /> ** Perl libraries should normally use @EXPORT_OK rather than @EXPORT.<br /> ** Libraries should where possible name their functions starting with <library>_.<br /> ** Libraries should, where reasonable, keep their functions sorted alphabetically.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=160 Coding Guidelines 2017-08-04T17:00:32Z

<p>Acunningham: </p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Run "go fmt" before checking into the repository.<br /> ** Strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use tabs instead of spaces for indentation.<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Leave a space after open bracket: if ( $variable ) {<br /> ** Leave a space before close bracket: if ( $variable ) {<br /> ** Do not leave a blank line after if, while, foreach, else, etc.<br /> ** Do not leave a blank line before closing curly brackets of blocks.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** If a list is very long, it should be spread across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Built-in Perl functions which can optionally have brackets, such as scalar(), should normally have brackets: scalar( @variable )<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Hash references are normally given very short names, typically one letter, or two if necessary to be unambiguous.<br /> ** Enumerated hash arrays should use " => " between keys and values, and ", " between values and keys.<br /> ** Use of the Perl "<condition> ? <if true> : <if false>" construct is encouraged where thought appropriate.<br /> ** Perl libraries should normally use @EXPORT_OK rather than @EXPORT.<br /> ** Libraries should where possible name their functions starting with <library>_.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=159 Coding Guidelines 2017-08-04T17:00:07Z

<p>Acunningham: Update Go</p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Always use "go fmt" before checking into the repository.<br /> ** Always strip executables before distribution unless symbols are specifically required for debugging.<br /> <br /> * Perl specific<br /> ** Use tabs instead of spaces for indentation.<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Leave a space after open bracket: if ( $variable ) {<br /> ** Leave a space before close bracket: if ( $variable ) {<br /> ** Do not leave a blank line after if, while, foreach, else, etc.<br /> ** Do not leave a blank line before closing curly brackets of blocks.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** If a list is very long, it should be spread across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Built-in Perl functions which can optionally have brackets, such as scalar(), should normally have brackets: scalar( @variable )<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Hash references are normally given very short names, typically one letter, or two if necessary to be unambiguous.<br /> ** Enumerated hash arrays should use " => " between keys and values, and ", " between values and keys.<br /> ** Use of the Perl "<condition> ? <if true> : <if false>" construct is encouraged where thought appropriate.<br /> ** Perl libraries should normally use @EXPORT_OK rather than @EXPORT.<br /> ** Libraries should where possible name their functions starting with <library>_.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=158 Coding Guidelines 2017-08-04T16:56:48Z

<p>Acunningham: Add disclaimer to top.</p> <hr /> <div>When working on Integrics code, developers are encouraged to bear these guidelines in mind. They are guidelines rather than rules, and developers should use their own judgement as to when to break them.<br /> <br /> * All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Always use "go fmt".<br /> ** Always strip executables before distribution.<br /> <br /> * Perl specific<br /> ** Use tabs instead of spaces for indentation.<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Leave a space after open bracket: if ( $variable ) {<br /> ** Leave a space before close bracket: if ( $variable ) {<br /> ** Do not leave a blank line after if, while, foreach, else, etc.<br /> ** Do not leave a blank line before closing curly brackets of blocks.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** If a list is very long, it should be spread across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Built-in Perl functions which can optionally have brackets, such as scalar(), should normally have brackets: scalar( @variable )<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Hash references are normally given very short names, typically one letter, or two if necessary to be unambiguous.<br /> ** Enumerated hash arrays should use " => " between keys and values, and ", " between values and keys.<br /> ** Use of the Perl "<condition> ? <if true> : <if false>" construct is encouraged where thought appropriate.<br /> ** Perl libraries should normally use @EXPORT_OK rather than @EXPORT.<br /> ** Libraries should where possible name their functions starting with <library>_.</div>

Acunningham http://wiki.integrics.com/index.php?title=Coding_Guidelines&diff=157 Coding Guidelines 2017-08-04T16:53:32Z

<p>Acunningham: Initial version</p> <hr /> <div>* All development<br /> ** Use sentence case, without capital letters in the middle of sentences unless specifically required.<br /> ** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.<br /> *** A brief description at the top of files.<br /> *** A copyright notice at the top of files.<br /> *** A brief description of each 'paragraph' in long functions.<br /> *** An explanation any section of code that may be counter-intuitive to someone reading the source.<br /> <br /> * Go specific<br /> ** Always use "go fmt".<br /> ** Always strip executables before distribution.<br /> <br /> * Perl specific<br /> ** Use tabs instead of spaces for indentation.<br /> ** Leave a space after negation: if ( ! $variable ) {<br /> ** Leave a space after open bracket: if ( $variable ) {<br /> ** Leave a space before close bracket: if ( $variable ) {<br /> ** Do not leave a blank line after if, while, foreach, else, etc.<br /> ** Do not leave a blank line before closing curly brackets of blocks.<br /> ** Do not leave multiple consecutive blank lines.<br /> ** If a list is very long, it should be spread across multiple lines. The last line before the closing round bracket should have a trailing comma.<br /> ** Built-in Perl functions which can optionally have brackets, such as scalar(), should normally have brackets: scalar( @variable )<br /> ** 'use' statements should be listed at the top of each file, in case-insensitive alphabetical order, unless otherwise necessary.<br /> ** 'require' statements may be embedded within functions.<br /> ** Hash references are normally given very short names, typically one letter, or two if necessary to be unambiguous.<br /> ** Enumerated hash arrays should use " => " between keys and values, and ", " between values and keys.<br /> ** Use of the Perl "<condition> ? <if true> : <if false>" construct is encouraged where thought appropriate.<br /> ** Perl libraries should normally use @EXPORT_OK rather than @EXPORT.<br /> ** Libraries should where possible name their functions starting with <library>_.</div>

Acunningham http://wiki.integrics.com/index.php?title=MediaWiki:Disclaimers&diff=10 MediaWiki:Disclaimers 2015-02-20T06:53:20Z

<p>Acunningham: Disabled disclaimers</p> <hr /> <div>-</div>

Acunningham http://wiki.integrics.com/index.php?title=Main_Page&diff=8 Main Page 2015-02-20T03:03:59Z

<p>Acunningham: </p> <hr /> <div>'''Integrics Wiki'''<br /> <br /> [[Integrics|About Integrics]]<br /> <br /> <br /> == Products ==<br /> * [[Enswitch]]<br /> <br /> <br /> <br /> ----<br /> <br /> Please note that this Wiki may contain content provided by third parties. Integrics makes no promises as to the correctness of information in this wiki, and provides no warranty or support for it.</div>

Acunningham http://wiki.integrics.com/index.php?title=Main_Page&diff=7 Main Page 2015-02-20T03:03:47Z

<p>Acunningham: </p> <hr /> <div>'''Integrics Wiki'''<br /> <br /> [[Integrics|About Integrics]]<br /> <br /> <br /> == Products ==<br /> * [[Enswitch]]<br /> <br /> ----<br /> <br /> Please note that this Wiki may contain content provided by third parties. Integrics makes no promises as to the correctness of information in this wiki, and provides no warranty or support for it.</div>

Acunningham http://wiki.integrics.com/index.php?title=Main_Page&diff=6 Main Page 2015-02-20T03:03:17Z

<p>Acunningham: Add link to Integrics</p> <hr /> <div>'''Integrics Wiki'''<br /> <br /> <br /> == Products ==<br /> * [[Enswitch]]<br /> <br /> Please note that this Wiki may contain content provided by third parties. Integrics makes no promises as to the correctness of information in this wiki, and provides no warranty or support for it.<br /> <br /> == Other information ==<br /> * [[Integrics|About Integrics]]</div>

Acunningham http://wiki.integrics.com/index.php?title=Integrics&diff=5 Integrics 2015-02-20T03:01:35Z

<p>Acunningham: Start of Integrics page</p> <hr /> <div>[http://integrics.com/ Integrics Ltd] is a software development based in the Isle of Man. It was founded in December 2004. Its primary product is [[Enswitch]].</div>

Acunningham http://wiki.integrics.com/index.php?title=Enswitch&diff=4 Enswitch 2015-02-20T03:00:35Z

<p>Acunningham: Start of Enswitch page</p> <hr /> <div>[http://integrics.com/enswitch Enswitch] is [[Integrics]] Ltd's primary product.</div>

Acunningham http://wiki.integrics.com/index.php?title=Main_Page&diff=3 Main Page 2015-02-20T02:57:48Z

<p>Acunningham: /* Products */</p> <hr /> <div>'''Integrics Wiki main index'''<br /> <br /> <br /> == Products ==<br /> * [[Enswitch]]<br /> <br /> Please note that this Wiki may contain content provided by third parties. Integrics makes no promises as to the correctness of information in this wiki, and provides no warranty or support for it.</div>

Acunningham http://wiki.integrics.com/index.php?title=Main_Page&diff=2 Main Page 2015-02-20T02:53:32Z

<p>Acunningham: basic main page</p> <hr /> <div>'''Integrics Wiki main index'''<br /> <br /> <br /> == Products ==<br /> * [Enswitch]<br /> <br /> Please note that this Wiki may contain content provided by third parties. Integrics makes no promises as to the correctness of information in this wiki, and provides no warranty or support for it.</div>

Acunningham