Talk:Attribute Naming Conventions

From Museon Softcode Package

Okay, my thoughts:

• ufunctions
  • I personally *really* dislike calling ufun's "u". It just looks totally bizarre/wacky when I see it-- 'u(u.do_this)' I'd -really- like them to be 'fn.do_this'
• functions mapped via @function
  • I've found it very good in libraries to encode if a function is supposed to @function/preserve, @function/privilege, or both, into the attribute name. I can then just iterate over the object and do it in an automated fashion. E.g, call these: "gf.L.this-function", with L meaning it sets registers so needs to be localized via @function/preserve, or "gf.W.this-function" with W meaning it'll be a privileged function, or "gf.LW.this-function" or whatnot. Just how its annotated doesn't matter to me.
• Data attributes containing a list:
  • I don't like using 'l' by itself, as its too hard to distinguish visually in lower case from i or even |. Can it be 'lst' or 'list'?

-- Ixokai 16:24, 22 October 2007 (EDT)

• I like the idea of denoting the /preserve, /priv and both stuff, but I don't know if L and W are that clear. I'd like to try and find something a little more obvious. I was thinking of first changing gf. to fnc. or something to denote @function usage more in line with the changes of u. to fn. and ul. to fnl. Then doing fnc.priv., fnc.pres. and fnc.both. Thoughts? Grey 19:00, 22 October 2007 (EDT)
  • Hrm, I do like the fnc.priv, fnc.pres, and fnc.both appoach. It lets one see, at aq quick glance, what they do. Yes, I know, we're going to have these things codified, but...it should help people to remember them, as they follow alogical progression (the u. and ul. would have me scratching my head, you see, until I looked back at the cheat sheet). Clotho 22:17, 22 October 2007 (EDT)
  • I'd do 'priv', 'local' and 'both' personally, as pres = preserve = localized. But 'pres' is fine too :) --Ixokai 02:16, 29 October 2007 (EDT)
    • I opted to suggest pres and priv so they would match the switches on @function, at least on MUX. To me it made sense to name the attribute according to the @function switch you're using. Grey 12:55, 29 October 2007 (EDT)

I think most of these should be elongated slightly, to make them more intuitive: C. to CMD. or use FN (or FUN) for functions. That type of thing. Remember, you may know what they mean, but for someone new to code just glancing at them, it looks like chicken scratch. --Clotho 16:48, 22 October 2007 (EDT)

• I am not opposed to the C. to CMD. and U. to FN. change. That said, the idea of someone 'new to coding' not getting them is a little flawed. Part of the goal is strong documentation that users can rely on. Most people have to figure out what the hell the attribute naming convention is on Myrddin's BBS or Anomaly Jobs because there is no reference at all. Museon will have that written down for people to read. Grey 16:51, 22 October 2007 (EDT)

• I agree that I'd like some of them elongated, perhaps to three letters (C. to CMD, FUN for functions, etc.) I think this would make the code more intuitive for all, not just people new to coding. ihavenomouth

• I think I'm with them on elongating them; but I'm opposed to trying to fix something to a set number of letters, e.g. 3. It should be long enough to be clear, short enough to be concise. I would go with FN, TRG, LIST, CMD, personally. Overly strict rules don't help readability and understandability. Ixokai 18:37, 22 October 2007 (EDT)