Proposed Code Guidelines

From Museon Softcode Package

This is a page for some proposed guidelines/rules to use while coding; this is about actual code, and not conventions like attribute names and such.

• The rule should be to always use itext() instead of ##. There are many circumstances where iter() is going over known-safe data and so poses no security risk, but I think a "best practice" should be to require that ## never be used. --Ixokai 18:20, 26 October 2007 (EDT)
  • Provided itext() and inum() work on Penn, MUX (they do), Rhost and MUSH, then itext() and inum() should be used. Grey 21:55, 27 October 2007 (EDT)
    • itext() is documented on all four as working; inum too (although I don't see the need to mandate that one, since it never substitutes in user-supplied data pre-evaluation) --Ixokai 01:44, 28 October 2007 (EDT)
      • inum() should be preferred to match the use of itext(), and also because inum() works correctly with nested iters when you want to access the list position of something outside of the current iter. Grey 20:53, 28 October 2007 (EDT)

• Proposal: sortby() should never be used! O(n^2) is simply not acceptable for lists of unknown size. Use sort() or munge(). --Sketch-the-Fox 16:35, 11 November 2007 (EST)
  • Buh? That's not at all a reasonable rule. "sortby() should never be used" .... "for lists of unknown size." don't match up. What about lists of sizes that you can predict? Further, O(n^2) performance -is- perfectly fine in many cases. Even up to lists of hundreds or more records, and it is predictable how big a list will likely get. "Use sort()" isn't a valid response-- you wouldn't be using sortby if a simple numeric/alphanumeric sort would satisfy your situation. The time savings you may get on the sort, may be entirely eaten up by converting the list into something sort()able before passing it to munge.
  • I'd question the claim that sortby is O(n^2) too-- that seems to be the absolute worst case scenario, and O(n log n) be the usual case.
  • Basically-- I don't like this as a rule. My worry is not for the miliseconds that at most would be saved; my worry is for responsiveness to the user only. Even with the reality of shared servers and resource limitations, using the most inefficient sortby() we can would not ever be a noticeable delay to the user -- nor much of a noticeable peak on the CPU -- unless we have truly massive lists :) --Ixokai 14:24, 26 November 2007 (EST)
    • All sorts have sortable keys (or aren't sorts), so a combination of munge() and iter() will always be better than sortby(). Although you do seem right about O(n^2) being worst case. Anyway, I wasn't thinking of speed when I suggested this, I was thinking of function invocation limits. sortby()'s function invocations are variable, so code might randomly (literally, randomly) break if it rides the edge of the limit for any MUSH--we don't know where this code will end up! --Sketch-the-Fox 10:47, 28 November 2007 (EST)
    • Upon having found code that required sortby(), I see what you mean. All I ask, then, is that it -isn't- used for things that sort() or munge() could do. :) --Sketch-the-Fox 16:24, 8 December 2007 (EST)