Return to Answer

Mathematica is a very "rich" language and there are litteraly hunderts of ways to achieve the same thing. It might make sense to require certain standard solutions or preferences of certain constructs to help team members to easier understand other members code, e.g.:

Mathematica is a very "rich" language and there are literally hundreds of ways to achieve the same thing. It might make sense to require certain standard solutions or preferences of certain constructs to help team members to easier understand other members code, e.g.:

• looping constructs: e.g. favour Do vs. For, favour non-indexing constructs like Map and Scan vs. their indexing counterparts Table / Do
• preferences of "paradigms" e.g. pattern matching vs. functional vs. procedural styles. e.g.: Replace[result,$Failed:>(Message[...];Throw[...]) vs. showMessageIfFailed[result]; vs. If[result===$Failed,Message[...]]
• use of pure functions (many of them nested are hard to read/understand)
• f=Function[x,x^2] vs. f=#^2& vs. f[x]:=x^2
• restrict use of symbols to those available to certain Mathematica versions.

• looping constructs: e.g. favour Do vs. For, favour non-indexing constructs like Map and Scan vs. their indexing counterparts Table / Do
• preferences of "paradigms" e.g. pattern matching vs. functional vs. procedural styles. e.g.: Replace[result,$Failed:>(Message[...];Throw[...]) vs. showMessageIfFailed[result]; vs. If[result===$Failed,Message[...]]
• use of pure functions (many of them nested are hard to read/understand)
• f=Function[x,x^2] vs. f=#^2& vs. f[x]:=x^2
• restrict use of symbols to those available to certain Mathematica versions.
• object/data representation: Association, Dataset, list of rules (and again: symbol or string keys?), matrix/list with positional meaning, custom head denoting an object, ManagedLibraryExpression

• upper vs. lower CamelCase, allow/suggest just lower case
• allow non-ascii characters in symbol names or not? if yes, restrict to subset like e.g. greek letters?
• make naming depend on symbol purpose and content? If yes:
• use verbs for symbols used as functions, nouns for symbols used as variables
• use of singular vs. plural for lists (number[[idx]] vs. numbers[[idx]]), or other conventions as numberArray[[x]]
• conventions for e.g. variables used as loop counters, flags, ...
• use of mathematica like xxxQ functions vs. isXxx as used in many other languages
• use a leading $ to indicate use of a global variable.
• all upper case names for constant (wide use in other languages, but does that use anyone in Mathematica?)
• allow single letter symbol names or not

• looping constructs: e.g. favour Do vs. For, favour non-indexing constructs like Map and Scan vs. their indexing counterparts Table / Do
• preferences of "paradigms" e.g. pattern matching vs. functional vs. procedural styles. e.g.: Replace[result,$Failed:>(Message[...];Throw[...]) vs. showMessageIfFailed[result]; vs. If[result===$Failed,Message[...]]
• use of pure functions (many of them nested are hard to read/understand)
• f=Function[x,x^2] vs. f[x]:=x^2
• restrict use of symbols to those available to certain Mathematica versions.

• upper vs. lower CamelCase, allow/suggest just lower case
• allow non-ascii characters in symbol names or not? if yes, restrict to subset like e.g. greek letters?
• make naming depend on symbol purpose and content? If yes:
• use verbs for symbols used as functions, nouns for symbols used as variables
• use of singular vs. plural for lists (number[[idx]] vs. numbers[[idx]]), or other conventions as numberArray[[x]]
• conventions for e.g. variables used as loop counters, flags, ...
• use of mathematica like xxxQ functions vs. isXxx as used in many other languages
• use a leading $ to indicate use of a global variable.
• all uppercase names for constant (wide use in other languages, but does anyone use that in Mathematica?)
• allow single letter symbol names or not

• looping constructs: e.g. favour Do vs. For, favour non-indexing constructs like Map and Scan vs. their indexing counterparts Table / Do
• preferences of "paradigms" e.g. pattern matching vs. functional vs. procedural styles. e.g.: Replace[result,$Failed:>(Message[...];Throw[...]) vs. showMessageIfFailed[result]; vs. If[result===$Failed,Message[...]]
• use of pure functions (many of them nested are hard to read/understand)
• f=Function[x,x^2] vs. f=#^2& vs. f[x]:=x^2
• restrict use of symbols to those available to certain Mathematica versions.