Clean platform coding style - Revision history

Thomas at 09:30, 15 July 2008

2008-07-15T09:30:40Z

← Older revision		Revision as of 09:30, 15 July 2008
Line 1:		Line 1:
	While a certain degree of freedom in writing style is a good thing, the readability of programs improves a lot when a consistent coding style is used. We therefore define the following guidelines which strongly encourage everyone to use when developing libraries for [[Clean]] and are even mandatory for libraries which are part of the [[Clean platform]].		While a certain degree of freedom in writing style is a good thing, the readability of programs improves a lot when a consistent coding style is used. We therefore define the following guidelines which strongly encourage everyone to use when developing libraries for [[Clean]] and are even mandatory for libraries which are part of the [[Clean platform]].
			__NOTOC__

	== Type names ==		== Type names ==
	The names of types should be clear and informative, and should always start with a capital. If the name of a type consists of multiple words, each new word should start with a capital. The constructors of a type should also start with a capital.		The names of types should be clear and informative, and should always start with a capital. If the name of a type consists of multiple words, each new word should start with a capital. The constructors of a type should also start with a capital.

	== Function names ==		== Function names ==
	Function names should not start with a capital, but when a function consists of multiple words, each new word, except the first one should start with a capital. By starting types and constructors with a capital and, functions without one, the difference between a constructor and a function is immediately clear for the reader of a program.		Function names should '''not''' start with a capital, but when a function consists of multiple words, each new word, except the first one should start with a capital. By starting types and constructors with a capital and, functions without one, the difference between a constructor and a function is immediately clear for the reader of a program.

	== Module names ==		== Module names ==

Bas Lijnse at 12:41, 14 July 2008

2008-07-14T12:41:05Z

← Older revision		Revision as of 12:41, 14 July 2008
Line 1:		Line 1:
	While a certain degree of freedom in writing style is a good thing, the readability of programs improves a lot when a consistent coding style is used. We therefore define the following guidelines which strongly encourage everyone to use when developing libraries for [[Clean]] and are even mandatory for libraries which are part of the [[~~Clean platform project\|~~Clean platform]].		While a certain degree of freedom in writing style is a good thing, the readability of programs improves a lot when a consistent coding style is used. We therefore define the following guidelines which strongly encourage everyone to use when developing libraries for [[Clean]] and are even mandatory for libraries which are part of the [[Clean platform]].

Bas Lijnse at 12:40, 14 July 2008

2008-07-14T12:40:30Z

← Older revision		Revision as of 12:40, 14 July 2008
Line 16:		Line 16:
	* Arguments which are used as "options" in some way should be at the beginning of the arguments. This makes it easy to pass in options by currying.		* Arguments which are used as "options" in some way should be at the beginning of the arguments. This makes it easy to pass in options by currying.

	== ~~Formatting~~ and ~~whitespace~~ ==		== Comments ==
	~~TODO:)~~		A concise description of the purpose of a function and the meaning of its input and output
			parameters should be present in the .dcl file for all exported functions.

			== Whitespace ==
			Whitespace may be used to format functions. When tabs are used for alignment, they are considered
			to be four spaces wide.

Bas Lijnse at 13:16, 24 May 2008

2008-05-24T13:16:34Z

← Older revision		Revision as of 13:16, 24 May 2008
Line 2:		Line 2:


	== ~~Naming types~~ ==		== Type names ==
	The names of types should be clear and informative, and should always start with a capital. If the name of a type consists of multiple words, each new word should start with a capital. The constructors of a type should also start with a capital.		The names of types should be clear and informative, and should always start with a capital. If the name of a type consists of multiple words, each new word should start with a capital. The constructors of a type should also start with a capital.

	== ~~Naming functions~~ ==		== Function names ==
	Function names should not start with a capital, but when a function consists of multiple words, each new word, except the first one should start with a capital. By starting types and constructors with a capital and, functions without one, the difference between a constructor and a function is immediately clear for the reader of a program.		Function names should not start with a capital, but when a function consists of multiple words, each new word, except the first one should start with a capital. By starting types and constructors with a capital and, functions without one, the difference between a constructor and a function is immediately clear for the reader of a program.

	== ~~Naming modules~~ ==		== Module names ==
	For modules, the same guidelines apply as for naming types. Names should be informative and preferably short. When a library module is not meant for direct imports by end users, but should only used by experts in modules that for example provide a more friendly interface, you should prefix the name of that module with an underscore character.		For modules, the same guidelines apply as for naming types. Names should be informative and preferably short. When a library module is not meant for direct imports by end users, but should only used by experts in modules that for example provide a more friendly interface, you should prefix the name of that module with an underscore character.

Line 15:		Line 15:
	* State representing arguments such as the common *World type argument, should be at the end of the argument list.		* State representing arguments such as the common *World type argument, should be at the end of the argument list.
	* Arguments which are used as "options" in some way should be at the beginning of the arguments. This makes it easy to pass in options by currying.		* Arguments which are used as "options" in some way should be at the beginning of the arguments. This makes it easy to pass in options by currying.

			== Formatting and whitespace ==
			TODO:)

Bas Lijnse at 08:24, 24 May 2008

2008-05-24T08:24:27Z

← Older revision		Revision as of 08:24, 24 May 2008
Line 9:		Line 9:

	== Naming modules ==		== Naming modules ==
	For modules, the same guidelines apply as for naming types. Names should be informative and preferably short.		For modules, the same guidelines apply as for naming types. Names should be informative and preferably short. When a library module is not meant for direct imports by end users, but should only used by experts in modules that for example provide a more friendly interface, you should prefix the name of that module with an underscore character.

			== Argument order ==
			While there are no hard demands on the order in which you specify the arguments of functions, there are two rules which make your functions easier to use and somewhat more clear:
			* State representing arguments such as the common *World type argument, should be at the end of the argument list.
			* Arguments which are used as "options" in some way should be at the beginning of the arguments. This makes it easy to pass in options by currying.

Bas Lijnse: New page: While a certain degree of freedom in writing style is a good thing, the readability of programs improves a lot when a consistent coding style is used. We therefore define the following gui...

2008-05-22T14:21:24Z

New page: While a certain degree of freedom in writing style is a good thing, the readability of programs improves a lot when a consistent coding style is used. We therefore define the following gui...

New page

While a certain degree of freedom in writing style is a good thing, the readability of programs improves a lot when a consistent coding style is used. We therefore define the following guidelines which strongly encourage everyone to use when developing libraries for [[Clean]] and are even mandatory for libraries which are part of the [[Clean platform project|Clean platform]].

== Naming types ==
The names of types should be clear and informative, and should always start with a capital. If the name of a type consists of multiple words, each new word should start with a capital. The constructors of a type should also start with a capital.

== Naming functions ==
Function names should *not* start with a capital, but when a function consists of multiple words, each new word, except the first one should start with a capital. By starting types and constructors with a capital and, functions without one, the difference between a constructor and a function is immediately clear for the reader of a program.

== Naming modules ==
For modules, the same guidelines apply as for naming types. Names should be informative and preferably short.