Regarding my own J code. Code smells are
1. superfluous rank assignments on verbs. Shows that I don't know the verb
ranks well enough.
2. Over reliance on ,/ and , to get out of a "oh no my result has the wrong
shape" problem. Better to figure out why it has the wrong shape.
3. Overuse of parentheses in tacit expressions. Often I do this because I am
too lazy, and I find asking J to show the expression will remove unnecessary
parentheses for me.
4. Using a complicated expression because I haven't realized one (or more) of
the J primitives would do the same job for me. This happens often. e.g.
appending a 1 to the shape of an array and reshaping it, instead of using ,: (I
wrote a lot of J before I noticed the existence of ,:)
On Friday, August 21, 2020, 02:06:49 PM GMT+9, Raul Miller
<[email protected]> wrote:
The code smell which bothers me worst, in J, is the "not getting started"
smell.
When I am afraid of writing a rough draft because it would be ugly, I
don't get anywhere. And, once I have a working draft, I can use that
to test variations which would be more concise, more understandable,
which get past machine bottlenecks, which have clearer interfaces
and/or more straightforward documentation.
Anyways, not putting my heart into it is a smell.
Thanks,
--
Raul
On Thu, Aug 20, 2020 at 6:24 AM ethiejiesa via Programming
<[email protected]> wrote:
>
> What are some classes of code smell in J?
>
> For clarity, "code smell" means any characteristic of source code that
> indicates a potentially deeper problem. These are anti-patterns that occur at
> the source code level.
>
> The canonical example is probably duplicated code, which indicates a potential
> for abstraction or merging of the repeated code. In C-like languages, deeply
> nested if statements are typically considered smelly, suggesting a potential
> need for better data structures, separation of mixed concerns, etc. In haskell
> "boolean blindness" is another.
>
> When writing tacit verbs, I find that trying to avoid ("), ([) or (]), and
> parentheses as much as possible often helps me find better solutions. That's
> what prompted this question.
>
> Anyway, what are similar code anti-patterns in J (or APL) that have helped you
> write better J by recognizing and avoiding them?
>
>
> Cheers!
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
