This is my "system" (some french words : sorry) : -- PRÉFIXES (types des objets) : -- ---- ku = constante (unitaire) ---- kt = constante (tableau) > utiliser plutôt une custom property -- ---- vg = variable globale [stack] ---- vt = variable globale (tableau) [stack] ---- vl = variable locale [script] ---- vx = variable temporaire [handler] ---- vp = paramètre [fonctions] ---- vd = variable provisoire servant au debugage -- ---- cp = custom property -- ---- hm = handler main stack (handler situé dans le stack principal) ---- hs = handler stack (handler situé dans le script du stack) ---- hc = handler card (handler situé dans le script de la carte) ---- hg = handler group (handler situé dans le script du groupe) ---- ho = handler objet (handler situé dans le script de l'objet) -- ---- fm = function main stack (fonction située dans le stack principal) ---- fs = function stack (fonction située dans le script du stack) ---- fc = function card (fonction située dans le script de la carte) ---- fg = function group (fonction située dans le script du groupe) ---- fo = function objet (fonction située dans le script de l'objet) ---- db = fonction ou commande servant au debugage -- ---- btn = bouton ---- fld = field ---- grp = groupe ---- sld = slider ---- lbl = label ---- img = image ---- grc = graphic
Le 20 avr. 2011 à 21:04, Pete a écrit : > Yep, I'm doing just about all those things. What I didn't do is use a > naming convention that indicates where in the message path the called > handler is. So if I call dbDoit from a control, where does dbDoit reside? > In the control script, on the card/stack that the control is in, on the > mainstack for the app, in some library totally outside the main stack that's > been inserted as a front/back script, stuff like that. > > Pete > Molly's Revenge <http://www.mollysrevenge.com> > > > > > On Wed, Apr 20, 2011 at 11:05 AM, Bob Sneidar <b...@twft.com> wrote: > >> Oh heck yeah, especially if you use a scripting utility that allows you to >> sort handlers. For instance, all my commands and functions for opening, >> closing, and idling databases start with db. All my functions that take >> parameters and return a value start with get. The big thing is to use names >> that are descriptive. They may be harder to type, but readability in a large >> app becomes paramount, especially if you have a memory like mine that >> flushes all unused information over a month old. >> >> Bob >> >> >> On Apr 20, 2011, at 9:15 AM, Pete wrote: >> >>> I agree, learned how to avoid several gotchas! >>> >>> The book has a section on naming conventions for variables and that's >> been >>> discussed several time on the list, but does anyone use naming >> conventions >>> for their commands/functions? >> >> >> _______________________________________________ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> >> > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
