converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 4:||Line 4:|
|== -- DanBron [[DateTime(2005-10-24T18:29:51Z)]] ==||== -- DanBron <<DateTime(2005-10-24T18:29:51Z)>> ==|
Religious wars on code formatting go here. The arguments should be mitigated by the fact that J has a canonical form for code. Use @ SIG @ to mark your section. Don't put any spaces between the @s and the word SIG.
-- DanBron <<DateTime(2005-10-24T18:29:51Z)>>
I try, as much as possible, to line up all copulae within a script, and have code start 2 spaces after the copula. I find this makes it easier to see what names are defined (i.e. the side effects of the code).
Constants vs Executed values:
I almost always use the executed form, except for:
- Scientific notation
- Defining constants from a shared library, where that library's documentation specifies the numbers in some other base (eg MSDN often specifies constants in hexadecimal).
Pi. My work doesn't involve much use of pi, but if it did I think I would prefer 1p1 to o. 1. Conversely, I prefer ^1 to 1x1 because the 'x' doesn't have a mnemonic link to Euler's number to me, and it's overloaded (it's also used for extended precision numbers and as a digit in based numbers).
Extended precision, because this leads to more consistency: 123x -: x: 123 , but -. 1234567891233456789x -: x: 1234567891233456789 .
Left and Right
I like to avoid [ and ] as much as possible, even to the point of using commuted hooks (g~ f)~ . Somehow I feel that arguments to tacit code should just fall in place, and that the identity functions defeat that purpose.
All my multi line explicit code is indented. This makes it easier to see the closing ) in column 0.
I'm not consistent with this, but I try to have static (not derived from external data) global constants be named with UPPERCASE.