Coding Guidelines - Revision history

Vlasis at 19:49, 3 September 2026

2026-09-03T19:49:15Z

← Older revision		Revision as of 19:49, 3 September 2026
Line 42:		Line 42:
	** Use the "<condition> ? <if true> : <if false>" construct if thought appropriate.		** Use the "<condition> ? <if true> : <if false>" construct if thought appropriate.
	** For Enswitch versions 4.2 and newer prefer the array style syntax for SQL queries even for data with a single parameter, e.g. data => [ $a->{ 'uniqueid' } ].		** For Enswitch versions 4.2 and newer prefer the array style syntax for SQL queries even for data with a single parameter, e.g. data => [ $a->{ 'uniqueid' } ].
			** Use POSIX::_exit() instead of exit() in Enswitch versions up to 4.3.
			** Use smart_exit() from lib/Utilities.pm instead of exit() in Enswitch versions 4.4+.

	* Databases		* Databases

Vlasis at 19:28, 20 October 2025

2025-10-20T19:28:36Z

← Older revision		Revision as of 19:28, 20 October 2025
Line 11:		Line 11:
	*** A brief description of each 'paragraph' in long functions.		*** A brief description of each 'paragraph' in long functions.
	*** An explanation any section of code that may be counter-intuitive to someone reading the source.		*** An explanation any section of code that may be counter-intuitive to someone reading the source.
	** In Enswitch, from version 4.4 onward the person's proper parameters such as id, login_id, effective_id, customer, login_customer, effective_customer etc should be observed according to the intended use in the code:		** In Enswitch, from version 4.4 onward the person's proper parameters such as id, login_id, effective_id, role, login_role, effective_role, customer, login_customer, effective_customer etc should be observed according to the intended use in the code:
	*** effective_id, effective_customer, etc (ie the effective_* parameters) should be used when the code relates to the switched-into user.		*** effective_id, effective_customer, etc (ie the effective_* parameters) should be used when the code relates to the switched-into user.
	*** login_id, login_customer, etc (ie the login_* parameters) should be used when the code relates to the user as originally logged in.		*** login_id, login_customer, etc (ie the login_* parameters) should be used when the code relates to the user as originally logged in.

Vlasis at 21:20, 28 August 2025

2025-08-28T21:20:39Z

← Older revision		Revision as of 21:20, 28 August 2025
Line 11:		Line 11:
	*** A brief description of each 'paragraph' in long functions.		*** A brief description of each 'paragraph' in long functions.
	*** An explanation any section of code that may be counter-intuitive to someone reading the source.		*** An explanation any section of code that may be counter-intuitive to someone reading the source.
			** In Enswitch, from version 4.4 onward the person's proper parameters such as id, login_id, effective_id, customer, login_customer, effective_customer etc should be observed according to the intended use in the code:
			*** effective_id, effective_customer, etc (ie the effective_* parameters) should be used when the code relates to the switched-into user.
			*** login_id, login_customer, etc (ie the login_* parameters) should be used when the code relates to the user as originally logged in.
			*** id, customer, etc (ie the plain parameters) should be used in relation to a user in the people table for eg. as a result of a query to that table.

	* Go specific		* Go specific

Vlasis at 11:21, 31 January 2022

2022-01-31T11:21:21Z

← Older revision		Revision as of 11:21, 31 January 2022
Line 37:		Line 37:
	** 'require' statements may be embedded within functions.		** 'require' statements may be embedded within functions.
	** Use the "<condition> ? <if true> : <if false>" construct if thought appropriate.		** Use the "<condition> ? <if true> : <if false>" construct if thought appropriate.
			** For Enswitch versions 4.2 and newer prefer the array style syntax for SQL queries even for data with a single parameter, e.g. data => [ $a->{ 'uniqueid' } ].

	* Databases		* Databases

Acunningham at 14:24, 21 November 2019

2019-11-21T14:24:20Z

← Older revision		Revision as of 14:24, 21 November 2019
Line 2:		Line 2:

	* All development		* All development
	** ~~Use~~ sentence case, without capital letters in the middle of sentences unless specifically required: This is a sample.		** 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.
	** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()		** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()
	** Libraries should, where reasonable, keep their functions sorted alphabetically.		** Libraries should, where reasonable, keep their functions sorted alphabetically.

Acunningham at 14:23, 21 November 2019

2019-11-21T14:23:21Z

← Older revision		Revision as of 14:23, 21 November 2019
Line 43:		Line 43:
	* Configuration files		* Configuration files
	** Use .ini format.		** Use .ini format.
	** Put files in /etc/enswitch if they're expected to be edited by system administrators, /opt/enswitch/current/etc if they're purely static.
	** Use single word lower-case section and key names were possible, or snake_case if multiple words are required.		** Use single word lower-case section and key names were possible, or snake_case if multiple words are required.
	** Use "true" and "false" for boolean values.		** Use "true" and "false" for boolean values.

Acunningham at 14:21, 21 November 2019

2019-11-21T14:21:00Z

← Older revision		Revision as of 14:21, 21 November 2019
Line 43:		Line 43:
	* Configuration files		* Configuration files
	** Use .ini format.		** Use .ini format.
			** Put files in /etc/enswitch if they're expected to be edited by system administrators, /opt/enswitch/current/etc if they're purely static.
	** Stored in /etc/enswitch.
	** Use single word lower-case section and key names were possible, or snake_case if multiple words are required.		** Use single word lower-case section and key names were possible, or snake_case if multiple words are required.
	** Use "true" and "false" for boolean values.		** Use "true" and "false" for boolean values.

Acunningham: Add section on configuration files

2019-11-21T14:19:50Z

Add section on configuration files

← Older revision		Revision as of 14:19, 21 November 2019
Line 40:		Line 40:
	* Databases		* Databases
	** Use snake_case for column names.		** Use snake_case for column names.

			* Configuration files
			** Use .ini format.
			** Stored in /etc/enswitch.
			** Use single word lower-case section and key names were possible, or snake_case if multiple words are required.
			** Use "true" and "false" for boolean values.

Acunningham: Add newline character as line terminator

2019-08-04T23:01:26Z

Add newline character as line terminator

← Older revision		Revision as of 23:01, 4 August 2019
Line 5:		Line 5:
	** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()		** A naming convention of <noun>_<verb> is preferred for exported library functions: email_send()
	** Libraries should, where reasonable, keep their functions sorted alphabetically.		** Libraries should, where reasonable, keep their functions sorted alphabetically.
			** Use the Unix standard of the newline character ("\n") to terminate lines.
	** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.		** Comments should be limited to the following, unless there's a specific reason otherwise. Overuse of comments is discouraged.
	*** A brief description at the top of files.		*** A brief description at the top of files.

Acunningham at 08:46, 31 May 2019

2019-05-31T08:46:19Z

← Older revision		Revision as of 08:46, 31 May 2019
Line 30:		Line 30:
	** Use " => " between hash array keys and values, and ", " between values and keys.		** Use " => " between hash array keys and values, and ", " between values and keys.
	** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.		** If a list is very long, spread it across multiple lines. The last line before the closing round bracket should have a trailing comma.
	** Use brackets on built-in Perl functions which can optionally have brackets: scalar( @variable ).		** Use brackets on built-in Perl functions which can optionally have brackets: scalar( @variable )
	** Use @EXPORT for library functions that are intended to be public.		** Use @EXPORT for library functions that are intended to be public.
	** Use @EXPORT_OK for library variables that are intended to be public.		** Use @EXPORT_OK for library variables that are intended to be public.